Gonna be interesting, if they spontaneously decide they wanted to open-source all along, like how LLAMA did back then…

I mean, I’m saying, I genuinely believe it’s just there to amuse the author, and whoever may share the same humor.

Lots of webpages were quirky like that, before it all got commercialized…

The guy writes a lot about UI design and I guess, bad/unexpected design amuses him. The hamburger menu uses an actual hamburger for the icon. In the winter, it will also snow on the webpage, with snowflakes covering up the content. And if you’re on desktop, you should try the dark mode.

Ah, interesting. I’m currently in the Rust rabbit hole, which takes a very different path towards race condition safety (it’s imperative and the compiler separately checks that you’re not using mutability in parallel contexts), but you actually get quite a similar feature, in that you can swap .iter().map() with .par_iter().map() (via a library).

Only Clojure supports parallelism.

It’s wild to me that this is said almost between the lines. In this particular benchmark, it obviously didn’t help, but for many workloads that’s going to make a massive difference or even leave Clojure as the only viable choice.

Scala <3

Ah yeah, I guess, my interpretation of that quote wasn’t quite right.

You can build a shared library in Rust, but it will need to be called via the C ABI or the WebAssembly ABI.
It is also possible to call a C ABI library in Rust (and virtually any other language), as well as a WebAssembly ABI library.
So, technically you can do shared libraries that way, but because the C ABI and WebAssembly ABI are significantly more limited compared to what you want to be passing around internally in Rust, you’ll only really want to use these in special cases.

Rust doesn’t particularly like dynamic libs. It compiles libraries you use on your dev machine, so it knows how you’ll use the libraries, which allows it to make various assumptions and optimizations.
For example, Rust can do generics via monomorphization (as opposed to vtables), which means it will generate the generic library code for each type that’s passed into the generic type argument. This is useful, because it can fully optimize that code, but also because it retains type information, despite the use of generics.

To my knowledge, they generally don’t. Shared libraries are a massive pain from a programming perspective, so it’s largely been avoided (even though there are some advantages for Linux distro maintainers and sysadmins).

Modern languages usually bring along their own package manager, which downloads the libraries you want to use from a central repository and then bundles them into your build artifact that you hand to users.
In ‘semi-modern’ languages, like the JVM languages and I think also Python, you get the dependencies in a folder as part of a larger archive.
With Go and Rust, they decided to include those libraries directly into the executable, so that many programs can just ship a single executable.

If by “shared library” you mean a dynamically linked one: IIRC Go does allow shared libraries to be used, but by default all Go code is linked statically (though libraries written in other languages may be dynamically linked by default, if you import a module that requires it).

This is the same for Rust.

What I always find fun is when open-source communities just continue developing games forever, defying this whole idea of old vs. new. NetHack is quite possibly the oldest example, which had its roots in Hack around 1982. And it’s still being actively developed, still getting new content. So, you get the retro gameplay and long history of the game, while also getting continuous updates like you’d get in an Early Access title. 🙃