Plurrrr

While working on a completely different project, I started to ask myself how the who command was working under the hood. In the end, I thought it was a good topic for a blog post.

Go is famous for making concurrency easy, through good language support for goroutines. Except what Go makes easy is only one level of concurrency, the nuts and bolts level of making your code do things concurrently and communicating back and forth through channels. Making it do the right things concurrently is still up to you, and unfortunately Go doesn't currently provide a lot of standard library support for correctly implemented standard concurrency patterns.

For example, one common need is for a limited amount of concurrency; you want to do several things at once, but only so many of them. At the moment this is up to you to implement on top of goroutines, channels, and things like the sync package. This is not as easy as it looks, and quite competent people can make mistakes here. As it happens, I have an example ready to hand today.

Recently, while idly browsing through the source code of Python, I came upon an interesting comment in the bytecode VM implementation (Python/ceval.c) about using the computed gotos extension of GCC [1]. Driven by curiosity, I decided to code a simple example to evaluate the difference between using a computed goto and a traditional switch statement for a simple VM. This post is a summary of my findings.

In these dark times, we are all in sore need of good news. Thankfully, I can report some: Emacs has defeated vi in the Editor Wars!

Some people, laughably, believe that vi is more popular than Emacs. Fortunately, these fools are completely wrong, and it is easily proven.

I feel like dynamically loading modules with webpack’s code splitting was discussed everywhere and everyone is doing it at this point. Thought I’d reiterate on how we do it in Blocksy and on the tiny layer of abstraction we built on top of the import() function.