• untoreh-light

My programming languages

My programming languages of choice

To keep the list short I try to stick to one language per ecosystem


Ok this is not an ecosystem but since it is my top language of choice it has to come first. The reason it is my favourite is that it is the only dynamic language that is truly ergonomic, I like how easy it easy to benchmark things, I like Makie, the way types compose and how the dispatch system seamlessly integrates with parametric types.

Julia trades off some memory and compilation time for speed and ease of use, and it is rare to see processes smaller than ~500M of ram. So if you hate electron or java you might have a problem with julia too, although there are solutions that give you small julia binaries they are all experimental, and anyway, julia is a dynamic first language, so I think the primary target use case will always be to run stuff from the repl and compiled binaries will always be second citizens, but time will tell.

Recently a language called mojo came out, and some people started questioning if it was a "threat" to julia. If you have used julia for quite some time, and then glossed over the mojo docs (like I did) you might have realized that mojo is a static language bolted on top of the dynamic python so it is hard to call it a language "unified" with python, therefore you are comparing apples and oranges...

If you want to compare julia with something else there are a couple of others "JAOT"s based languages:


We can call it the "C" ecosystem, and my second fav language is nim, but I rarely use it because its tooling is crap. So please someone dump a few millions in nim tooling development, thanks! It is my favourite because as I mentioned before julia is very hard to ship and you definitely don't want to ship gigabyte sized binaries. Nim instead can compile very small binaries and make tham static too.

The only pain point (from a language perspective ofc) is the interaction between threads and async. Passing stuff between async couritines and threads can be full of gotchas, so it lacks some kind of system that makes it easier to juggle between threads and the async runtime. Also using an async runtime can make binaries grow quite large because of the async closures rewrites or something like that, bottom line is that binaries have a boatload of codegen-ed functions, and debugging them is also hard because of the function naming scheme.

Apart from being overall easy to ship, it has great ffi support, dot call syntax, a macro/template system that is even better than lisps (if you ignore lack of sexprs), macros in julia are ok but nim can "dispatch" macros and templates over types, allow you to choose between "dirt and hygiene" and the language server was able to provide lots of intelligence betweeen functions, macros and templates that even rust couldn't achieve (if only it wouldn't crash every 2 second and be slow as hell...sigh).

Nim also has nimscript, my wish is that a full fledged interactive repl could be built around that, if hot code reloading ever gets picked up again, that is...


Rust is what I use since nim tooling is crap, if nim tooling wasn't crap I would use nim. I don't personally find rust memory safety such an advantage over nim. Nim doesn't not have "fearless concurrency", that is compared to rust it is easy in nim to segfaul when dealing with threads. However rust uses lifetimes to achieve thread safety, while nim doesn't have any such thing at the language level. Lifetimes are likeley the most confusing and hard to read rust language feature so there might be a reason in there...

In general you can say that after a certain point business bugs become more common than memory bugs, and you don't want to overcomplicate the language to achieve diminishing returns in memory safety while clobbering the readability and increase complexity of the language itself. Because quantifying how much a language makes business bugs more common is pretty much impossible to quantify, this point is always going to be moot.

The rest

These are only language on top of my list of "alternative" languages that I might pick once per ecosystem

What follows is what I would use any these ecosystems, but haven't really tried them:

Apart from these "ecosystem" language picks there are a couple other worth an honorable mention.

There are many other popular languages, like some more functional ones like ocaml, haskell or other simpler ones like zig or vlang which I have not mentioned because I think they are too dead set over their paradigm (immutability/simplicity), and in general I guess I prefer more "rounded" languages.

This list ended up not being that short, sorry I guess.

Post Tags: