abeltensor's comments

The article significantly misses the mark by treating Ruby as nothing more than Rails — a perspective that currently detracts from the language. The author clearly hasn't explored the strong features of Ruby 3. Not to mention, it's a very nice language to learn as an entry point into programming.

Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and static site generation. It's a simple, dynamic language ideal for quickly prototyping solutions.

Elixir, however, is a separate conversation. Having used it in production for years, I can attest that the ecosystem is fantastic. Its lack of mainstream popularity doesn't matter; its true strength lies in the BEAM, an incredibly well-architected piece of software. Elixir is simply a great way to access that power. Beyond its Ruby-like syntax, it has become its own distinct entity. It used to exist mainly as a alternative to erlang but it's become its own thing in recent years.

I really hate language-based dogma, every virtually every programming language has place as a tool in in a programmer's tool belt. There is even value in learning and using deprecated languages because doing so gives you a perspective beyond whatever ecosystem that you're currently tied to. There is a reason that languages like fortran and lisp have persisted as meaningful choices in certain domains and I suspect that Ruby will stick around for a very long time.

Scoop is the main package manager I've been using for years on windows apart from chocolatey. Dunno many others aside from the official windows one: winget.

Very nice. Nodes are great if you want a long running system along side your elixir app.

Hmm, well Go itself has gone through a ton of revisions where the GC saw large improvements. And other languages coming up are experimenting with various types of GCs. Its really up to the use case though.

With discord, I imagine a big reason why Rust was considered as an alternative to Go is because they already have a substantial Elixir codebase. Rust and Elixir have a very easy time communicating with one another via Erlang NIFs (native function interfaces). You can embed languages like C/C++/Rust into elixir without much overhead. While I've never personally tried do to such a thing with go, I can't imagine its a smooth experience. You'd probably need to use Ports or CNodes for Go simply for this reason.

I love go myself, but one of the biggest turn offs for the language is its FFI support for C and other C connected languages. CGo is a relatively expensive investment when compared to many other comparable alternatives and it should be avoided if possible.

You are always going to have some kind of latency spike with a sweeping GC; even if that spike is tiny.

The main issue with Go in this regard is that it generally doesn't have multiple ways of doing the same thing at least idiomatically. I mean sure, there are architectural choices you could make in a rewrite but the actual structure of the code itself is going to be very similar.

I love Rust elixir Nifs. Gives you the best of both worlds to be honest. Highly fault tolerant code with fast computation. Only downside is that it can't really handle extreme crashes like a native process can.

You've got alternatives like Flutter and ReveryUI which are both pretty solid for building cross platform applications without using web technologies or webviews.

And you can always just use some of the other GUI toolkits that have been coming out recently.

WASN will always need some kind of javascript glue to interact with the DOM.

tauri does use webview but its moving away from it in favor of a rust native solution called WRY.

No revery is native. It doesn't use a webview at all; just uses the skia engine; basically a flutter competitor.

Flutter is one that is moving in that direction.

You are pretty much on the spot, its a library that directly interfaces with the existing browser engines on the user's computer.

Disk space and Memory.

Wish he had released the tooling. The REBL system looks a bit like the smalltalk virtual machine mixed with elements of Elm's time-traveling debugger. There has been a real need for serious error handling in clojure for a long time (since the stack traces and exceptions are borderline unintelligible). This thing makes it look much more user friendly.

They tried to fix the errors with Spec but honestly I don't think that solution worked that well. Spec is great for generative testing and other solutions but no one wants to write specs for every single small little potential error that could happen.