Modern computer processors implement sophisticated branch prediction algorithms to improve the effectiveness of speculative execution. But old-school static branch prediction would never have predicted BranchTaken LLC (ba dum tsh). Strained silicon puns aside, the BranchTaken name is an intentional nod to the concept of branch misprediction, in particular the founders’ unlikely pursuit of Hemlock, an ambitious programming language research and development project.
Hemlock is intended as an excellent programming language choice for the middle 75% of development projects. Don’t hold us to that 75% number, but it makes for great hyperbole here. Let’s say that 5% of projects need precise control in a low-level bare-metal sort of way; think operating system kernels, hard real-time systems, and large-scale numerical linear algebra. Recent languages like Rust and Zig are targeting use cases like these, but Hemlock isn’t. At the other extreme say that 20% of projects are one-off, small, and/or weakly specified. Pick your poison; we at BranchTaken tend to reach for Python or Bourne shell derivatives, but good options abound (Perl, Ruby, PHP, AWK, etc.). Yes, we at BranchTaken may foolishly use Hemlock for scripting purposes as the language matures, but we won’t earnestly encourage anyone else to do likewise. However, we fervently hope that Hemlock will become an excellent choice for the middle 75% of projects. More tantalizingly, we envision that Hemlock will enable effortless massively parallel computation for many programs, and that the performance gains will be so compelling that Hemlock will be the obvious choice.
Hemlock will require a lot of intricate interoperating parts in order to function fully. We are actively designing and building those parts now, and we plan to write here about some of the insights which excite us along the way. We already have several topics queued up, but right now it’s time for the killer features list, because describing just one killer feature doesn’t do Hemlock justice.
Some killer features in Hemlock
- The type system incorporates mutability and effects support, such that APIs authoritatively denote what side effects can occur. This is a boon both for program reliability and optimization.
- Application parallelism is based on asynchronous message passing of immutable values shared via a global heap. And huge, intricate shared state is a practical approach because computational overhead for the global heap is directly proportional to allocation volume!
- Work stealing automatically parallelizes computationally intensive pure computations to take
advantage of arbitrarily many underutilized cores. This requires no effort from the programmer
beyond writing pure code. Common APIs like
reducework great with this feature.
Look to future posts for more about fun engineering details which make these features possible.