Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save caspervonb/03d412a07dedb66d79815d2d195fdec8 to your computer and use it in GitHub Desktop.
Save caspervonb/03d412a07dedb66d79815d2d195fdec8 to your computer and use it in GitHub Desktop.
Deno, One Year and Two Hundred Patches Later

Deno, One Year and Two Hundred Patches Later

About a year ago, I made a new year resolution to finally publish a game. I’ve already passed 30 and have been developing games for fun since I was a little brat.

That, predictably turned out pretty much like you’d expect a new year resolution to go, it never came to pass.

But the reason wasn’t that I didn’t work on it, its just that when it comes to my own projects I am really a top tier expert yak shaver so I basically ended up shaving yaks until I became an active contributor to the Deno TypeScript and JavaScript runtime instead.

From Game Development To Shaving Ten Thousand Yaks

So how on earth does Deno, a JavaScript and Typescript runtime relate to game development? it doesn’t, at-least not to someone not familiar with the ancient art of yak shaving.

For those are unfamiliar with the term, here’s Hal from Malcom in the Middle demonstrating proper technique and workflow for fixing a light bulb.

Basically dipped my toe in because one of the things I was working on for the platform abstraction layer of my vaporware game was an implementation of the WebAssembly System Interface for Web Browsers.

One thing lead to another and I ended up implementing it for Deno, I actually uploaded a short video from one of the sessions.

While working on that I ran into a lot of issues, like read not working with stdin and WebAssembly error propogation being broken which were pretty much my first patches aside from some trivial renaming and such.

Found myself lacking more system call bindings for getting my WebAssembly System Interface (WASI) implementation done so I also ended up implementing a handful of system calls such as ftruncate, fstat, fsync and fdatasync which while were all fairly trivial to implement I did end up reading and familiarising myself with large chunks of the entire codebase.

Eventually I was approached about my then userland WASI implementation and we migrated that into the standard library which is a collection of modules that lives at https://deno.land/std.

Having already familiarised myself with the code base and gone from knowing nothing about Rust except that we should “Rewrite it in Rust” to being fairly comfortable with it I just went to town submitting patches after patches including but not limited to the read-eval-print-loop, code coverage and upcoming parallel test runner.

For the last couple of years, or… actually when I think about it it's been over a decade. Geez, time flies! Anyway, I’ve been in web development land professionally pretty much my entire career so I found it quite enjoyable to be working with a systems level language again. Finally my love for C and low level game development had a real world application (except for writing unfinished/unpublished games).

That’s pretty much how I got involved with Deno, it was a complete accident but a happy one as I really enjoy working on software that enables developers to kick ass and build awesome things.

Learning Rust and Dealing with Build Times

Before I dove into Deno I was consulting and contracting. Over the years I’ve done pretty much every random thing you can think of from writing Ruby on Rails applications, large scale booking systems in C# and there’s even that one time I auditing npm packages that I’ll never ever forget but my bread and butter for quite a few years was just writing a bunch of Node.js servers.

Writing servers is quite far from the low level C and C++ I grew up with as a young lad but I’ve always had a love for systems languages. I saw Rust come on the scene and thought it was interesting to have a borrow checker but thought of it as somewhat of a gimmick and quickly fell into the fallacy of “Well, I write correct C and C++ programs I would never need that” and pretty much just brushed of Rust as hype that would go away like it has with every other C replacement language.

However, after actually giving it a real chance by actually writing code and contributing to Deno. The borrow checker and type system became my favourite feature overnight. The reason was quite simple, I did not really know Rust so for the first month I was effectivly just writing C and making it compile.

Deno isn’t on the scale of say V8 or Chromium in terms of size but is still a fairly large and complex codebase so having the compiler yell at me for trying to send something that did not implement send was a godsend. The compiler messages are just great; if you’ve ever seen the horrors that unfold when you forget a token in a C++ template then you can probably relate.

But there’s also a pretty major downside, the build times… My old workstation and laptop both died sometime during 2019 and 2020 wasn’t a exactly a great year to be splurging on non-essential items.

That leaves me with my fairly dated Mac mini from around ~2015 which obviously is a bit underpowered for building complex systems. Building Deno on it takes somewhere around ~1.5–2 hours for a full debug build and incremental builds take anywhere from 10–30 minutes.

Productivity wise that’s fairly terrible but if there’s a will there is a way. Good thing I forced myself to learn Vi/Vim way back in my school days and have used it pretty much ever since which turned out to actually come in handy for once. Instead of building locally I rent a way to expensive virtual server and work remotely over a ssh connection.

It suits me well, it’s mostly stable with a ping low enough not to really notice and connections do drop sometimes but it brings incremental debug builds down to 2–5 minutes which is much more manageable.

Chasing after GitHub Sponsorships and Dealing with Burnout

Renting a server for development is however not free so I ended up applying for the GitHub sponsors program in an attempt to at-least break even with the server costs sometime around July last year.

I have never been so excited in my life to receive a single dollar, despite having to wait around 60 days to receive it. It’s really something else to have complete strangers supporting you in open source endeavours. Especially when it’s individuals, it’s incredibly humbling. I’m really truly really grateful and all of you guys are really freaking awesome!

That said, it is unfortunately not sustainable even after a year of grinding which leads to the inevitable doom and gloom every now and then as savings have been dwindling while I’ve been spending more time on open source than doing actual paid work over the past year. We had a mild freakout last month when it seemed like we were pregnant, not exactly great timing right now.

It’s a funny thing, on the one hand a new sponsor one month, even if its just a few bucks gets me to pull all-nighters. but at the same time I can see it’s very unlikely to that it is ever going to reach the levels I need it to be at to consider it a salary.

It probably doesn’t help that I really despise plugging it so I do it half-assed tongue in cheek. It would be one thing I I could hide behind a marketing account but this is just me. Every tweet I’ve ever sent out about has been followed by a cringe starting in my neck and crawling down my spine it’s such an uncomfortable thing to put out there. I'd prefer to just not having to deal with it and just write code but you can't win if you don't play I suppose.

What’s Next

Bit more personal for once than my usual cold served satire but hey can’t always wear a persona on the internet.

It’s been an interesting year, I’ve learned a ton. I’m not sure whats next for me, my current level of sponsorships is definitively more than 0 but it as likely as being struck by lightning that my GitHub sponsorships are gonna rocket up to the range we need to be at in order to keep the lights on and eat on a regular basis.

I still got promises and commitments to keep so won’t bail overnight, there’s a bunch of bug fixes and features to land for 1.10 (which is the next version of Deno).

Then some more in my backlog for 1.11 and 1.12 but further out than however time will tell.

I am however open for new new things and opportunities so do feel free to hit me up if you’re hiring and building something awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment