Read Part 1 first.


Compared to Jai, Clojure is a straitjacket. It is much more unusable, for sure. Why?

Jonathan Blow’s personal style of programming seems to be similar to compression-oriented programming. As such, Jai is designed for it. I like that, so Yao will do the same thing.

An example: one cool feature of Jai is the way it is designed to handle the life cycle of code, from straight-line execution, to a separate scope, to a local closure, to a local procedure, to a global procedure. The syntax has been formed in such a way that the programmer has to adjust as few characters as possible.

That is minimizing effort to make a change in a way that matters.

However, what else can I do to minimize friction?

Standard Library

I can make a great standard library.

A language with a standard library that is big enough (and well-designed enough) to make the first dive into the language easy, especially to write some sort of non-trivial and useful program, will pick up users.

Basically, the standard library will reduce the friction of starting with, and working in, the language, among other things.


One big source of friction for developers is code style and the arguments that come with it. Go got this right, by deciding on a “one, true” code style for Go from the beginning and having a formatter to enforce it. Yao will do the same.

Other Tools

Having other tools available, like good IDE’s (by either plugins for existing IDE’s or a new one), a custom debugger, testing and coverage tools, and profilers, make using a PL much easier.

Breaking the Language

The other big thing to reduce friction that Jai still does that most new-ish mainstream languages don’t is giving the programmers the option to do what I call “breaking the language.” This means that the programmer can break out of the limitations that the language imposes. C and C++ do this, as does Rust (in a more limited way).

I think that this is important for several reasons.

First, this is the only way to make a language capable of writing operating systems, device drivers, etc.

Second, there are just some occasions (beyond the above) when a programmer has to do something that is unsafe, but necessary. In those cases, it is an insurmountable amount of friction that stops programmers from getting done what they need to.

So while it does give sharp tools, those sharp tools are necessary, but more importantly, their use can be discouraged, as Rust does.

Here is where I think Jai gets this wrong. Jai has very few restrictions on top of C or C++, and it does not discourage their use at all.

Rust also gets this wrong for different reasons. It hasĀ unsafe, but there are still restrictions on it, and I also don’t believe that its use is discouraged enough.

Rest assured, Yao will provide a way to completely break the language, but it will discourage its use.

Manual Memory Management

Another way of reducing friction is allowing manual memory management. Jai does this, Rust does not (except in unsafe). Yao will have a way of doing manual memory management.


So, if you have come this far, you have some idea of how Yao takes inspiration from Jai to reduce friction. The next post will be about the inspiration it takes from Clojure to reduce bugs.