What I mean when I say that machine learning in Elixir is production-ready

Let’s say we do that. How many threads can we create?

On BEAM, running 10,000 lightweight processes is normal. Phoenix is designed so that every incoming http request is its own lightweight process.

How does one manage that number of lightweight processes? The runtime’s scheduler keeps track of every single process so nothing is orphaned. It is preemptive, so no lightweight process can starve out another (though there are some exceptions).

They can also suspend cheaply, as such, works well with async io.

The closest thing to this are the new virtual thread feature of recent Java. I don’t think Java has the same kind of properties that will allow it to manage it as well as BEAM. There is a lot more to Elixir than being able to use all the cores.

Nodejs will also move on if io is blocked.

However, since Nodejs queues bits of execution, rather than messages, errors can get lost. So then you have unhandled promise rejections… and then relying on a linter to look for those times you did not write something to catch the error. I was told this is a good feature of the linter.

Contrast that with the BEAM languages. An unhandled error crashes the lightweight process. Any linked process (such as a supervisor) can decide what to do about the crash (restart, or crash as well). We don’t even need liveliness probe (like in Kubernetes) because the supervisor is immediately informed (push, not pull).

You don’t need a linter to make sure it has a sensible default, because this is handled by design.

Nodejs, on the other hand, is error prone, _by design_, even though it does not block on IO either.

No amount of typespecing is going to fix that.

Have any of you used elixir-desktop [1]? It is a wxWidgets + LiveView bundle, pretty much like a Electron app.

In [2], Wojtek Mach explains how the team behind Elixir build Livebook Desktop. He explains how the project started, some subtle bugs found when building the app for MacOS, some limitations of wxWidgets in Windows, and many other implementation details.

It would be awesome if the Elixir team release something like elixir-desktop based on Livebook. That is, forking the Livebook repo and release an official template project for generating desktop applications based on LiveView.

[1] https://github.com/elixir-desktop/desktop-example-app

[2] https://www.youtube.com/watch?v=Kiw6eWKcQbg

It's funny how this works, I will never work with Next.js ever again (after doing it for years at multiple companies), I find it to be a total mess. Compared to how José Valim and Chris McCord (and others) lead Elixir and Phoenix and Vercel / Meta handles Next.js and React is night and day and I have close to zero trust in the latter. But then again, Next.js a tool to sell Vercel hosting and React has its own roadmap to cater to Meta, both of these are obvious perfectly valid and it's not a secret so people can make their own choices.

I don't know how many times I've done a minor update of Next just to have some undocumented internal change break everything, and reading their release logs are a joke, who thought it would be a good idea to just dump badly written git-commits and call it a day?

As an anecdotal warning, unless your team consists of TypeScript masters with extremely strict ethics you will end up with type safety issues too, they will just be harder to find (and if things go bad crash your runtime or client execution) :) Being easy to hire for has actually been a massive downside personally, it's very hard work finding people who actually know how to build a good React app, not to mention a Next.js ditto, but you'll get an near infinite number of applicants with skills "matching".

Better to say that whatever your resulting platform is (probably Go based on what you’ve said), it suits your constraints.

We've found that our constraints are better met for our most important project by Elixir. We are building something else in Go (mostly because it will be easier to find cheaper contractors to build these boring things once we have the first version done) and we still deliver a number of things in Ruby, and there's Typescript for some things. Use what works at the time you need it.

I personally find Go to be a tedious language and think it could use a fair number of DX improvements, ranging from adopting some form of Rust's terminal `?` sugar to just better recommendations on project structure and layout. It took far too long for Go to get generics, and the platform-specific build files being based on filename (e.g., `foo_aix.go`) is clever with all of the hatred I can put into that.

I have shipped software in ~40 different programming languages and distinct dialects over my career. Go does a number of things well, but some of the choices made are frankly bizarre. There are restrictions on how you can name things because of the platform bit and `internal/`, but then there's no recommendation on how to lay out a project otherwise. I’ll still use it any time over most other lower-level languages, but the language itself does not spark joy. The compiler is good and fast, but I have less confidence that I have built the right thing from it than when I use Rust.