Live data from Hacker News

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

dashbit.co

41–50 of 68 posts

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

#41

People 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 Explorer, perhaps it is not the library, but your knowledge of Elixir that was a little too half baked? ;)

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

#42
post #32

Earlier quoted context omitted.

I've been really curious about BEAM languages but never made the leap. How well does it manage heterogeneous compute? I'm used to other languages making me define what happens on CPU vs GPU and defining cross-machine talk around those kinds of considerations. What parts of that does elixir (and company) allow me to not write? Is there a good balance between abstractions when it comes to still maybe wanting control ov…

The BEAM is pretty high level, and it's REALLY good at managing distributed compute at the thread or device level. If you have a parallelizeable workflow, it's very easy to make it (properly!) parallel locally, where by "properly" I mean having supervision trees, sane restart behavior, etc. And once you have that you can extend that parallelism to different nodes in a network (with the same sanity around supervision…

If you have a multistage workflow with concurrent and possibly heterogenous requests that hit all the time you can very easily batch and distribute the workflow among compute resources in "the most natural way possible" easily, without having to resort to grace periods, etc. which introduce latency. I think that would be much harder to accomplish with java.

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

#43
post #39

People 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…

I think most of the replies to your post suggest that you are correct, even though the downvotes are unfortunate.

That’s ok, truth is bitter. People may fall for hype sometimes. Maintainers of the project can refute what I am saying but they won’t as this the truth.

- In current explorer one cannot write user defined functions, plugins. - They don’t even have it in roadmap. - Also the exposed functionality is always lagging when compared to polars.

- elixir, nx, explorer,distributed, etc nice keywords - reality is it is still early for them. Better to stay away for production apps in case of ai/ml unless people are connecting to OpenAI and writing chat apps for which they won’t need any of the above except elixir.

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

#44
post #32

Earlier quoted context omitted.

I've been really curious about BEAM languages but never made the leap. How well does it manage heterogeneous compute? I'm used to other languages making me define what happens on CPU vs GPU and defining cross-machine talk around those kinds of considerations. What parts of that does elixir (and company) allow me to not write? Is there a good balance between abstractions when it comes to still maybe wanting control ov…

The BEAM is pretty high level, and it's REALLY good at managing distributed compute at the thread or device level. If you have a parallelizeable workflow, it's very easy to make it (properly!) parallel locally, where by "properly" I mean having supervision trees, sane restart behavior, etc. And once you have that you can extend that parallelism to different nodes in a network (with the same sanity around supervision…

I think Numerical Elixir (NX) allows for GPU programming. It uses XLA for scheduling computation?

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

#45
post #23

Earlier quoted context omitted.

ASDF is easy to use once you've learned a few of the basic commands, and that way you'll have an easy time when new versions come out and want to check out new features. Like the built-in JSON parser, the gradual typing when it drops, things like that. If you built something useful you might not want to upgrade it just to look at the new stuff, and if you built nothing and just drop into iex a couple of times per yea…

I think the Python dev style I adopted can't be easily ported to Elixir. In Python, I rely heavily on an LSP because I want to fiddle with a lot of functions/classes located deeply in libraries. In VSCode, I simply press CMD and click on any function (or in Neovim, I `gf` or `gd` it). I thought it'd make even more sense in Elixir because apparently everything is a module. Am I missing something? How do you use iex ef…

You're not missing anything. It should be a better experience, it just isn't yet. Sorry. I hope development on the possibilities accelerates!

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

#46
post #39

People 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…

I think most of the replies to your post suggest that you are correct, even though the downvotes are unfortunate.

The downvotes are for the attitude. If you expected all alternative software options to be strictly better than their replacements we would never get anywhere in terms of DX. Someone has to be brave and be an early adopted and put in the sweat to get shit to work and this guy is just taking potshots instead of making pull requests.

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

#47

People 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…

Telling someone they’re ignorant probably doesn’t get them to use your tech. Not the person you’re replying to; I use elixir everyday at work.

The biggest barrier to adoption of these libraries I can see is that there is not a wealth of resources to solve the actual problem the person is experiencing.

Googling “dyplr verbs in python” there’s a towards data science post that’s the 6th result. It has step by step code examples to get you started with what I guess the person is looking for.

Googling “dyplr verbs in elixir”, you get the explorer library’s GitHub page and docs as results. I see there’s an example on the first page, but docs present as a high barrier to entry. For better or worse, hand-holding helps get people using the thing, and there’s a SEO-fueled ton of python hand-holding resources out there.

I’m sure you’re aware of these things as the author of the book mentioned, but buying a book is a step for someone who’s already sold on learning the language/framework. Having google-able content is much more useful to get people in the door and in the day-to-day work looking something up.

Until something “cool” and well-known is made with Nx/Axon and friends, they’re gonna be seen as second-class to most people who aren’t elixir diehards. Somehow everyone in elixir-land recs these, but never has anything they actually use them for.

There’s also the switching cost. Most Python ML compute is actually done in C/off-loaded to gpu, so its speed is ok and not greatly constrained by the language choice. Python does have multiprocessing stuff which, while annoying in my experience, makes parallelizing stuff possible. Again, thinking from an outsider’s perspective, there doesn’t seem to be a “must have” reason to use elixir when they’ve already been working in python.

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

#48

People 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…

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.

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

#49
post #22

Earlier quoted context omitted.

It's very serious. The BEAM had a problem in that it lacked solid number-crunching libraries, so some folks solved that, and when they did distributed ML-capabilities kind of just fell out as a neat bonus so some folks did that too. So now it's integrated into the basic Livebook, just boot it and go to that example and you have a transcriber or whatever as boilerplate to play around with. Want something else from Hug…

> except if the tokenizer or whatever doesn't follow a particular format but in that case you just upload it to some free web service and make a PR with the result and reference that version hash specifically and it'll work. May I ask to which service you are referring?

This one: https://jonatanklosko-bumblebee-tools.hf.space/apps/tokenize...

It's linked in the Bumblebee README. Seems broken at the moment, maybe the PR it made is more informative: https://huggingface.co/Neprox/STT-Swedish-Whisper/discussion...

Post reply on HN