And with Elixir's gradual type system [1] coming soon, this is looking to be quite an eventful year for José and Team. Bravo!
Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
51–60 of 68 posts
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#52People have to realise these are mostly for hobby. It is really hard to get these working with other libraries. Take explorer, it’s a mess trying to implement dplyr verbs in elixir. Anyone trying to use it is going to hit its limitations sooner or later. I tried migrating to it from polars but it is too frustrating.. gave up after some time. Why will people use half baked libraries instead of python ? I will stick to…
> People have to realise these are mostly for hobby. It is really hard to get these working with other libraries.
I have been dealing with this type of feedback for almost 20 years at this point: "This library doesn't work for my needs, so the conclusion is that it is hobby/not useful/etc for everyone". In your experience, we are not there yet (and we may never be), but the generalization does not hold.
Take Explorer, it was the first library of the bunch to be used in production because it was created by Chris Grainger to write data pipelines at his company. And the blog post does include the link to a talk on production usage.
Other projects, like Nx, started as an experiment, but nowadays it is used in production quite a bit and we spend a lot of the time refining it based on feedback we receive.
No one is claiming those libraries are complete. It is still pre-1.0. But we claim to be evolving and improving based on feedback. So if anyone wants to try something different than Python, and you can afford to engage, give feedback to maintainers, and even contribute, then you will hopefully have a good time and be closer to running it in production too.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#53Earlier quoted context omitted.
At this point is isnt trying to convert a happy python user like you. Rather to give tools to teams whose app is already in Elixir and the devs knows Elixir. Instead of bringing in Python to the mix you can use Elixir
Elixir dev you are describing and we use Python for ML stuff because it’s easier to work with the more documented frameworks. These libraries just aren’t “there” yet, and I think it’s important to be honest about that. I’ve tried extending/converting to them, and it just wasn’t worth it yet.
> These libraries just aren’t “there” yet, and I think it’s important to be honest about that.
Exactly. These projects are still during early adoption stage.
While it is production-ready and many are doing so, getting there requires improving documentation, discussing roadmaps with maintainers about a feature you may need (perhaps even contributing it), giving presentations (at your company or at events), and so forth. This can be exciting to some, but a distraction for others. There is certainly plenty of work ahead.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#54Earlier quoted context omitted.
At this point is isnt trying to convert a happy python user like you. Rather to give tools to teams whose app is already in Elixir and the devs knows Elixir. Instead of bringing in Python to the mix you can use Elixir
Elixir dev you are describing and we use Python for ML stuff because it’s easier to work with the more documented frameworks. These libraries just aren’t “there” yet, and I think it’s important to be honest about that. I’ve tried extending/converting to them, and it just wasn’t worth it yet.
[deleted]
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#55To the author, I noticed a typo: a misspelling of "meachine" instead of "machine" """ These features bring Numerical Elixir and its ability to setup distributed model serving, over CPUs and GPUs, to traditional meachine learning algorithms, allowing developers and data practitioners to tackle a wider number of problems within the Elixir ecosystem. """
Thank you.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#56Earlier quoted context omitted.
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…
> 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.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#57Earlier quoted context omitted.
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…
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 dyn…
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.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#58People have to realise these are mostly for hobby. It is really hard to get these working with other libraries. Take explorer, it’s a mess trying to implement dplyr verbs in elixir. Anyone trying to use it is going to hit its limitations sooner or later. I tried migrating to it from polars but it is too frustrating.. gave up after some time. Why will people use half baked libraries instead of python ? I will stick to…
To be fair to the creators of “half baked” libraries, you’re comparing our work to frameworks with several years head start with the backing of trillion dollar organizations (excluding polars). To have convinced ANYBODY to successfully make the switch is, to me, both somewhat of a miracle and an indication that there is a legitimate market for this work. I think it also dispels the hobby claim As for your issues with…
Sean Moriarity, please use your elixir knowledge to write a user defined function or a plugin in explorer. It's easy to attack other people and assume they are ignorant.
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#59IMO the big win for Elixir/Nx/Bumblebee/etc is that you can do batched distributed inference out of the box without deploying anything separate to your app or hitting an API. Massive complexity reduction and you can more easily scale up or down. https://hexdocs.pm/nx/Nx.Serving.html#content And there's also a scale to 0 story for when you're not using that GPU at all: https://github.com/phoenixframework/flame 1 langu…
[deleted]
Re: Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
#60People have to realise these are mostly for hobby. It is really hard to get these working with other libraries. Take explorer, it’s a mess trying to implement dplyr verbs in elixir. Anyone trying to use it is going to hit its limitations sooner or later. I tried migrating to it from polars but it is too frustrating.. gave up after some time. Why will people use half baked libraries instead of python ? I will stick to…
> People have to realise these are mostly for hobby. It is really hard to get these working with other libraries. I have been dealing with this type of feedback for almost 20 years at this point: "This library doesn't work for my needs, so the conclusion is that it is hobby/not useful/etc for everyone". In your experience, we are not there yet (and we may never be), but the generalization does not hold. Take Explorer…
Thank you Jose, for your 2 decades of relentless work. I have not disparaged any maintainers or their work. I get it from your comments that these projects are in early days of adoption and development.
From my perspective, just because Chris Grainger does data pipelines in production does not prove the project is for everyone. It means it worked out for him.
May be seeing more updates, papers, interviews, podcasts about their usage in production will change things.
For now, my assessment is everything is wonderful till one hits a limitation of these libraries. If it works out, its wonderful, if not its like neither here nor there.