11–20 of 89 posts
Instead of moving to Elixir I believe it makes more sense to wait/move to Mojo when it's ready: https://www.modular.com/mojo
Elixir (NX) is ready now, Mojo might be, at some time in the future.... also Mojo won't have the BEAM or ergonomics around Functional Programming.
Instead of moving to Elixir I believe it makes more sense to wait/move to Mojo when it's ready: https://www.modular.com/mojo
Earlier quoted context omitted.
Those are real issues though.
Is concurrency useful for ML?
The current workarounds to make this happen in python are quite ugly imho, e.g. Pytorch spawns multiple python processes and then pushes data between the processes through shared memory, which incurs quite some overhead. Tensorflow on the other hand requires you to stick to their Tensor-dsl so that it can run within their graph engine. If native concurrency were a thing, data loading would be much more straightforward to implement without such hacks.
Earlier quoted context omitted.
Is concurrency useful for ML?
You end up having to do a lot of things in a ML training run, some of which you can do in parallel because it’s not important now (eg saving metadata) or because you’d otherwise be resource limited (eg loading data and formatting batches for training)
If I really had the use case and needed threads, I'd much rather use C++ bindings in a Python package than rebuilding the whole thing. Guess it depends on the scale we are talking about.
[0] https://pythonspeed.com/articles/faster-multiprocessing-pick...
Earlier quoted context omitted.
Elixir (NX) is ready now, Mojo might be, at some time in the future.... also Mojo won't have the BEAM or ergonomics around Functional Programming.
ML is not an island, it is part of a much broader "data science" universe that is currently served fairly well (still imperfectly) by the Python/C++ stack and is not easy to replicate. Throwing BEAM or FP acronyms around won't really strike a chord with people working with data and models. Mojo will (as per promise) tap into the wider ecosystem. Other platforms are more than welcome to try but this ultimately require…
Other languages have certain features that make extension and integration feel like first-class concerns which lowers the barrier to contributions from a wider range of people and also helps keep e.g. dependencies and build processes relatively simple.
https://pragprog.com/titles/smelixir/machine-learning-in-eli...
You can always make Elixir app talk to Python ML backend and get the best of both worlds if you desire.
I wish there wouldn’t be such a song and dance about “moving away from Python”. There’s nothing wrong with creating ML tools in Elixir, but it’s always Python is slow, Python has no concurrency support, blah blah
The thing is Elixir is really good at an increasing number of things.
If you need to write a HTTP proxy in the middle of your application, since Elixir processes & incoming HTTP workers are cheap, you do not need to go evented: it just works.
If you need to have reactive web apps with automated changes pushed to the client, it's the same: there is no need to external tools (e.g. any cable) at certain scale.
If you need to do some scripting, there is `Mix.install/2` for single-file dependencies description & use.
If you start crawling too much web pages or process to many APIs, the concurrency support kicks in and there is less need to scale (or later), turning into fewer machines, fewer ops problems (or delayed) etc.
And now you start being able to use MachineLearning, deploy the same type of code on GPU, embed Machine Learning models right in the middle of your web app without much work, etc, which in turns makes it a nice platform for apps / SaaS.
Elixir really is becoming a Swiss-army knife which scales easily :-)
Earlier quoted context omitted.
Those are real issues though.
Is concurrency useful for ML?
1. Loading data
2. Running algorithms that benefit from shared memory
3. Serving the model (if it's not being output to some portable format)
There are also general benefits of using one language across a project. Because Python is weak on these things, we end up using multiple languages.