Skip to content

Comment on Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.parent

Comments

One factor may be that a few years back the language creator (José Valim, also the author of this article) announced that the language is basically "completed", and that they would shift focus to other things like developer tooling and other projects outside of the language itself.

José is quite prolific, so I think it's natural that he moves on to things like this. It's hard to know what reception will be like until you build it.

From a strictly "marketing" point of view, if you want to grow the language and ecosystem, it seems the successful move is to stake out a place where you're likely to win.

I think often this happens more or less by accident rather than conscious design - but think of something like PHP which made it really easy to whip up quick web pages, or Rails which drive Ruby adoption for a better, more structured, but still dynamic and quick web programming experience.

And I suppose part of those happy accidents are people just hacking on something they think is cool, so I wouldn't stress too much about the "marketing aspect". I'm just curious what drove it.

I have always considered helping the community grow into a diverse ecosystem to be my main responsibility (the Python community being a great example here).

This particular effort started because some people got together and realized that we could do it! Do it in a way that felt part of Elixir and not just a bunch of bindings to C libraries.

We honestly never had the expectation that we had to beat Python (otherwise we would simply not have started). Early on, we were not even sure if we could be better at one single thing. However, 3 years later, we do have features that would be quite hard or impossible to implement in Python. For example:

* Nx Serving - https://hexdocs.pm/nx/Nx.Serving.html - allows you to serve machine learning models, across nodes and GPUs, with concurrency, batching, and partitioning, and it has zero dependencies

* Livebook - https://livebook.dev - brings truly reproducible workflows (hard to achieve in Python due to mutability), smart cells, and other fresh ideas

* A more cohesive ecosystem - Nx, Scholar, Explorer, etc all play together, zero-copy and all, because they are the only players in town

Of course, there are also things that Python can do, that we cannot. The most obvious ones being:

* In Python, integration with C code is easier, and that matters a lot in this space. Python also allows C to call Python, and that's just not possible in the Erlang VM

* Huge ecosystem, everything happens in Python first

At the end of the day, what drives me is that the Erlang VM offers a unique set of features, and combining them with different problems have historically lead to interesting and elegant solutions. Which drives more people to join, experiment, run in production, and create new things.

Thanks for the great answer! And thanks for your work with Elixir. As a long-time Erlang user, I was impressed at how it wasn't just a slightly nicer syntax, but included genuine innovations and improvements.

My guess is that Jose and the core team are both personally interested in the big wave of ML stuff we've been experiencing recently and also want to demonstrate that Elixir is a viable platform for doing this work to teams which have adopted Elixir and are interested in ML but don't want to add a bunch of Python into their codebase.

I would also guess that Elixir led to some crazy things they didn’t even imagine possible with web, like phoenixs live view [1]. Even if they don’t have explicit ideas of how it will impact ML, it’ll be really interesting to try.

[1]: https://phoenixframework.org/blog/phoenix-liveview-1.0-relea...

a few years back the language creator announced that the language is basically "completed"

And then began adding an entire static type system to the language

Correct. When I did the presentation, I did mention we attempted to type Elixir and failed. Therefore, the idea of saying the language was "complete" was precisely to signal the community that most of the work would happen in the ecosystem and not by directly changing the language. Especially because:

* The language was designed to extensible - see how Numerical Elixir can compile Elixir to the GPU and it didn't require changes to the language (we improved the language based on some needs but it was never a blocker)

* A lot of the hard work that makes Elixir better every year is actually happening on the Erlang VM, which we mostly get to leverage by doing nothing (for example, Elixir "got" a JIT since I said we were complete and we had to change nothing)

I'd say the definition of "completed" still holds, because we haven't announced changes to the language yet, but if the work on the type system succeeds, then we will introduce a new typing annotation, which is definitely big enough to void the label after 7-8 years.

Strictly optional and without changing the language API, fwiw. So about as smooth/painless an experience as possible.

Its addition into the next minor verision (1.17) will bring warnings that address some of the most common footguns in the language, like comparing structs.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.