14 ms·

José Valim Reveals “Project Nx” (Numerical Elixir) [audio]

juhatl 6y ago
I'm really excited about this project. Seeing Elixir inch this much closer to being a viable option for machine learning and related fields is great. In case someone here wants to read rather than listen to all the details, I wrote down some notes over at: https://elixirforum.com/t/anyone-who-wants-to-speculate-about-this-tweet-from-jose/35772/69?u=juhalehtonen https://elixirforum.com/t/anyone-who-wants-to-speculate-abou...
- flyingfences 6y ago
  Thanks, that actually explains it pretty well: > Nx = Project for a collection of libraries. Nx is the core library, the other libraries depend on this core library > If you come from Python, it can be though of as kind of like Numpy. Long way to go but working on that. > “Slowness in Elixir” due to immutability and copying etc. Performance comes from module that is part of Nx called Numerical Definitions > In the definition you write with a subset of Elixir. Elixir kernel is replaced with Numerical kernel. > Based on Google XLA (accelerated linear algebra) > You can give it a computation graph and exla compiles it to run efficiently on CPU or GPU
  - BadInformatics 6y ago
    Pretty disappointing to see it using XLA. Anything Tensorflow is notoriously difficult to build on a local machine and generally considered a dependency nightmare. I would've thought libtorch bindings would be much easier.
    - josevalim 6y ago
      Our compiler backends are pluggable. We went with XLA because that seemed the most accessible to us 3 months ago but you should be able to bring in libtorch or any other tensor compiler. That's actually one of the things I am really looking forward to: see what other compilers people will integrate with. I am aware some of the neural network libs have pluggable compilers but it will be interesting to see it done at the tensor level. :)
      - BadInformatics 6y ago
        That's great to hear. I'd love to see the Bazel monstrosity that is Tensorflow XLA get easier to build because of Nx. Not holding my breath though!
        josevalim 6y ago
        Yeah, I would love if we could depend only on XLA. I think other communities like Julia could benefit from it too.
  - dynamite-ready 6y ago
    So, two questions. Is this a standard library module, and does this run on the GPU?
ibraheemdev 6y ago
What José Valim has done in building an entire community around elixir single-handedly is absolutely incredible. Numerical Elixir looks amazing as well.
- dragosmocrii 6y ago
  Good for him, and good for us. I really like elixir
- dudul 6y ago
  "single handedly"? Really? Jose did a humongous work, but this is so dismissive of all the other people who put time and effort into building the ecosystem and the community.
  - lostcolony 6y ago
    While there are certainly other evangelists, and Erlang aficionados tend to engage too, I don't think I've seen any discussion of Elixir in a public forum where Jose hasn't been involved, giving well thought out, humble commentary. As the founder of the language, the lead evangelist, and the main mouthpiece, yes, 'single handedly' may be hyperbolic, but only slightly. It's not to dismiss others' inputs, but it is to highlight how -insanely- engaged he is. I can think of no other language founder who has put in nearly the same legwork.
    - macintux 6y ago
      > I can think of no other language founder who has put in nearly the same legwork. I don't pay particularly close attention these days, but I'd think Rich Hickey's involvement in Clojure over time, at least to the point Elixir is today, would be comparable.
      - lostcolony 6y ago
        In which case I'd say "singlehandedly" applies equally there, too. Still hyperbolic, but still representative of the degree of effort involved.
jeremy_k 6y ago
Exciting to see that heavy numerical computation might be available to a language running on BEAM. It has always seemed to me like an area that people would point to where Elixir couldn't stand up to Python. I've always dreamt that someday you might be able to reach for Elixir and get everything you needed for an entire stack of a company and it seems to be getting closer and closer. The building blocks for a web app have been around with Phoenix and Ecto for quite some time. LiveView was introduced to make more user friendly frontends. GenStage, Flow, and Broadway introduced ways to run data processing pipelines. And now we're seeing the initial steps to potentially have ML capabilities.
- dimitrios1 6y ago
  I am almost convinced to go all in with the elixir ecosystem. Having been a victim of a similar type of thinking, however, I am not sure this is the best thing to do so I am skeptical. Remember, Java and the JVM essentially have this today: front end frameworks, back end frameworks, data pipelines, big data processing, entire databases, etc. In your opinion, what will make the Elixir flavor of this situation different?
  - mgreenleaf 6y ago
    I think Elixir has the potential of being like the JVM but for functional distributed programming. The JVM is fantastic and I do most of my work on it, but having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition. Especially with the easy interop of languages & functional aspects. I don't think it will surpass the JVM, but I think it has a lot of potential in its own sphere of influence. Especially if the library support & technical contributions keep coming.
  - dragosmocrii 6y ago
    Code elegance and development joy, maybe? I know Java has a mature ecosystem, but I wouldn't touch it with a stick
    - deleted 6y ago
      [deleted]
tomphoolery 6y ago
When does the actual news start? Clicking around this podcast is annoying.
- graydsl 6y ago
  It starts like 8 minutes in. The whole podcast is about Nx basically.
deleted 6y ago
[deleted]
pantulis 6y ago
For this to gain traction needs to be adopted by the data-science community. It does not feel like that.
- sfusato 6y ago
  How did you measured that already? The "baby" is yet to be born. We found it's "name" just a few hours ago.
  - pantulis 6y ago
    Fair point, let me try and ellaborate. Of course, time will tell. But the data science community fixation is on algorithms, not on languages. So you would need to build Tensorflow or Pytorch upon Nx, and you would need to migrate people from the easy Python/Anaconda/Jupyter to the BEAM world. For that to happen the upside should be obviously evident, I guess in terms of performance. Take, for example, the web world. I believe Phoenix is technically the best framework out there, or at least on par with Rails. And it has not taken the web world by storm (yet). Why would Nx be a success without the support of Google or someone that big?
    - detaro 6y ago
      Why must "take the X world by storm" be the goal?
- dnautics 6y ago
  I'll tell you why I'm cautiously bullish on Nx. 1) python really does not have broad cultural discipline around testing. Especially not in the ml field. 2) deploying python is not the best. 3) unlike TF, torch is actually not hard to understand and the code should be easily movable and portable out of it. Small time ML users will care about 1&2. 3 makes it relatively painless.
- bcardarella 6y ago
  The project isn't even public yet, has been under development for only a few months, hasn't had the opportunity to get wider academic eyeballs on it yet, and you're already calling it DOA. Nice.
andrewflnr 6y ago
What a grand find for a logo/mascot: https://twitter.com/josevalim/status/1356880707474370560 https://twitter.com/josevalim/status/1356880707474370560. An cute animal whose name sounds like "number" for a numerical computation project... and no other similar project has taken it already? I should be jealous but it just makes me happy.
JamesSwift 6y ago
Sigh... nx is already a (well known) thing in the dev space. https://nx.dev/ https://nx.dev/
- deleted 6y ago
  [deleted]
- ashton314 6y ago
  I think just slapping “elixir” at the beginning of the search query will help with the discoverability. Maybe if it gets consistently marketed as “Elixir Nx”, this won’t be a problem. Elixir’s documentation is so good, however, I would expect most questions will be answered by the documentation directly.
  - JamesSwift 6y ago
    I agree, adding elixir is the likely solution, but my point is "why?". There's no reason to start off on that foot on day 1. And right now is still day 0 so there is still time to rethink it.
    - ljm 6y ago
      What if they did think about it and decided they still wanted to stick with their preferred name? It's like with trademarks: you can have more than one thing with the same name and not have a problem. If it was another build tool that helped you deal with your git repos that would be a real issue, but it's not... it's aimed at a totally different audience for a totally different reason. This town is absolutely big enough for the both of them. Or do you think other people have problems because when they search for, say, Kafka, or Jekyll, they keep finding references to literature instead of the tech they're using?
- bcardarella 6y ago
  Sigh... another Sigh... complaint on HN about naming... sigh... <head desk> Thank you for sigh... pointing out sigh... the obvious sigh...
auraham 6y ago
Numerical Elixir? Exciting news! I wish it would be something like Numpy. It would be awesome.
- heeton 6y ago
  That’s what it is :)
andy_ppp 6y ago
Just from my point of view the actor model seems ideal for simulating three dimensional systems at various levels of fidelity. An actor could exist that does maths for one region (say air in a climate change simulation) and that cube could send messages about its state to various surrounding regions/actors (cubes at the top, bottom, left, right, front and back) and affect them. The more cubes in the system the higher quality the simulation. Obviously this being on the beam you’d get the ability to run these actors across different computers fairly easily, hopefully scaling quite well. You could also build FDTD systems like this and even acoustics simulations. I wonder if this is something the authors here are thinking about?
- ramchip 6y ago
  Modelling a problem like this with tons of Erlang processes tends not to go very well: - It's slow, really slow, and memory heavy. All communication between processes involves copying and context switch. - It's easy to introduce deadlocks (A calls B calls C calls A - now system is stuck) or unbounded message queue growth (if you use casts rather than calls) - Everything is a single unit of fault tolerance (if one cell crashes, the entire simulation should be re-initialized from a known state) so all the processes need to be linked together in a massive web, which more or less defeats the point of process isolation. I think it might make sense in the abstract actor model, it just doesn't map cleanly to Erlang processes.
ashton314 6y ago
I’m excited that some neat problems were solved at the level of the programming language. Example: by working with the AST, Nx can automatically differentiate functions. It’s delightful to see how much care has gone into designing Elixir. It’s like José smuggled a Lisp in Ruby’s clothing onto the BEAM.
appleflaxen 6y ago
Jose Valim is so prolific; I love seeing what he comes up with.
- mercer 6y ago
  I like this comment on the forums: > “Hey, what did you do over Christmas?” > me: “I drank too much and tried to read a book” > Jose Valim: “I rewrote my language’s kernel to afford tensorflow-like operations for efficient ML operations”
nudpiedo 6y ago
honestly I think it would have been more profitable to modernize ErlPort to better interconnect with the python ecosystem and even other programming languages. I think it will be difficult to move some companies away of their current computation frameworks.
- josevalim 6y ago
  A couple notes: 1. Work on modernizing erlport can still happen and be orthogonal to this 2. Moving data in and out of the GPU is expensive, sending the data to another process so it can copy it to the GPU would make us pay the penalty twice (and then again on the way back) 3. And even if you want to go ahead with 2, I would do it over the wire so I don't couple my nodes running Erlang/Elixir to the nodes running the Python stuff (because they may require different specs/scale) 4. We don't need people to move away from their computation frameworks, I will be happy if people start considering building new things on top of this one in the future :)
halotrope 6y ago
Slightly tangential. I really would like to thank José for creating all of this! I have been using Elixir a lot and the language, the ecosystem and the community are amazingly cohesive, friendly and put a strong emphasis on good uncluttered design. If it was not there, something would be sorely missing. I was wondering if something like nx was coming. Together with Flow and Beam you can put the better part pf GCP in one binary with a few lines of pretty code.
josevalim 6y ago
Hi everyone, thanks for the enthusiasm so far! We are going to make the repository open source next week and, for those who haven't listened to the podcast, I want to align everyone's expectations and say it is very early material. Expect bugs, breaking changes, etc. On the other hand, it is also a great time for anyone who wants to jump in and help shape things, so feedback will be very welcome!
- dnautics 6y ago
  (I'm the guy who guessed correctly and got early access). Sorry I have been busy with my main job and haven't been able to contrib much in the past couple of months or so, but I just took a look at it and it looks really good so far. I think some of the architectural things are well-considered, and also, one thing that I forsee is "calling out to a remote gpu", where the nx library itself can be used by a node that doesn't have a gpu, instead of having the node with a gpu expose an rpc to the gpuless node. I guess a relevant analogy here would be the difference between graphQL and REST, but possibly also allowing the gpuless node to gracefully degrade to cpu, if the gpu resource isn't available. The Nx API will likely present an opportunity to also make data gravity abstractions cleaner. I think the elixir/erlang way of thinking about "concurrency as a special case of distribution" will apply to Nx, except "gpu as a special case of distribution" which means there won't be a leaky abstraction for remote gpu. I tried to get the Julia folks to adopt this sort of an attitude towards the juliagpu, but I'm a bit of a nobody so it didn't take. Very excited! And I'm whipping up a little bit of something interesting related to Nx myself that hopefully I can release around the time of your talk, but I don't want to make any promises yet.
  - rising-sky 6y ago
    > I guess a relevant analogy here would be the difference between graphQL and REST There is more than one difference between GraphQL and REST, could you clarify this analogy? Thanks
    - dnautics 6y ago
      Good point. The relevant analogy is that in GraphQL the client defines the query that gets run and in REST the server defines the query that gets run. So one way you could architect Nx is to have your elixir running on the gpu node expose a handful of prebaked functions and allow your client elixir node issue requests to those prebaked functions ("REST"). But I think a bit more exciting would be to have your gpu node running a relatively dumb Nx server, and have your gpu-less client running Nx, where its math instructions get serialized using a thin "network device" backend instead of a "gpu backend", over to the gpu node, then the gpu node does the math and comes back with the answer ("GraphQL"). For even longer-haul operations you would want to do things like figure out how to represent datasets with tokens that are cached remotely. I think this all is possible, and, relatively easy with the Nx architecture.
Grimm1 6y ago
This makes me happy, love the elixir scene have used Matrex to good effect and wrote a pipeline recently that processes over 10gb (disk IO on the third party service bottle necked us or it would have been a lot more) data a minute through Broadway. Elixir + BEAM are good technologies and looking forward to having more numerical computing capabilities directly available in the language. I had spent a little time trying to contribute to Tensorflex which was a google summer of code project for TF in elixir but life got too busy to proceed and then I didn't see any movement there so just figured the idea of ML was on pause and outside of Matrex numerics were also on pause. Happy to see it was still going on behind the scenes.
ddragon 6y ago
That seems the start of something pretty amazing, I work on a fintech using Elixir and we usually have to delegate all numerical analysis and ML stuff to python microservices, even models with considerably simple execution, and being able to move that logic to Elixir would certainly be very nice (we can always batch train them elsewhere, just running the model is a great deal). Of course, it's definitely going to be a long road before getting to be production ready and somewhat competitive with the ever improving big players (as it is with all languages without supports from major corporations with large interest in the area, languages like Nim, Julia, Clojure and even Swift considering it doesn't have full support on Google, and those languages still have an advantage with their stronger interop with python/java/C). But after listening to the talk, I went from thinking that Elixir was not a good fit to ML to actually excited with the future. Elixir's pipes are definitely a beautiful and concise way to define transformations, and we already have nice examples of them with Streams and Ecto.Multi that even make it surprisingly nice to debug the readable "tape", and being immutable itself allows it to nicely avoid the hardest parts in translating the language into an execution graph both for the creators of the library and for the user. Modifying the if macro to embed the conditional within the "tape" might be a little too much magic though.
lesotholand 6y ago
Will it use Apache Arrow data format?

I'm really excited about this project. Seeing Elixir inch this much closer to being a viable option for machine learning and related fields is great. In case someone here wants to read rather than listen to all the details, I wrote down some notes over at: https://elixirforum.com/t/anyone-who-wants-to-speculate-about-this-tweet-from-jose/35772/69?u=juhalehtonen https://elixirforum.com/t/anyone-who-wants-to-speculate-abou...

flyingfences 6y ago
Thanks, that actually explains it pretty well: > Nx = Project for a collection of libraries. Nx is the core library, the other libraries depend on this core library > If you come from Python, it can be though of as kind of like Numpy. Long way to go but working on that. > “Slowness in Elixir” due to immutability and copying etc. Performance comes from module that is part of Nx called Numerical Definitions > In the definition you write with a subset of Elixir. Elixir kernel is replaced with Numerical kernel. > Based on Google XLA (accelerated linear algebra) > You can give it a computation graph and exla compiles it to run efficiently on CPU or GPU
- BadInformatics 6y ago
  Pretty disappointing to see it using XLA. Anything Tensorflow is notoriously difficult to build on a local machine and generally considered a dependency nightmare. I would've thought libtorch bindings would be much easier.
  - josevalim 6y ago
    Our compiler backends are pluggable. We went with XLA because that seemed the most accessible to us 3 months ago but you should be able to bring in libtorch or any other tensor compiler. That's actually one of the things I am really looking forward to: see what other compilers people will integrate with. I am aware some of the neural network libs have pluggable compilers but it will be interesting to see it done at the tensor level. :)
    - BadInformatics 6y ago
      That's great to hear. I'd love to see the Bazel monstrosity that is Tensorflow XLA get easier to build because of Nx. Not holding my breath though!
      - josevalim 6y ago
        Yeah, I would love if we could depend only on XLA. I think other communities like Julia could benefit from it too.
- dynamite-ready 6y ago
  So, two questions. Is this a standard library module, and does this run on the GPU?

ibraheemdev 6y ago

What José Valim has done in building an entire community around elixir single-handedly is absolutely incredible. Numerical Elixir looks amazing as well.

dragosmocrii 6y ago
Good for him, and good for us. I really like elixir
dudul 6y ago
"single handedly"? Really? Jose did a humongous work, but this is so dismissive of all the other people who put time and effort into building the ecosystem and the community.
- lostcolony 6y ago
  While there are certainly other evangelists, and Erlang aficionados tend to engage too, I don't think I've seen any discussion of Elixir in a public forum where Jose hasn't been involved, giving well thought out, humble commentary. As the founder of the language, the lead evangelist, and the main mouthpiece, yes, 'single handedly' may be hyperbolic, but only slightly. It's not to dismiss others' inputs, but it is to highlight how -insanely- engaged he is. I can think of no other language founder who has put in nearly the same legwork.
  - macintux 6y ago
    > I can think of no other language founder who has put in nearly the same legwork. I don't pay particularly close attention these days, but I'd think Rich Hickey's involvement in Clojure over time, at least to the point Elixir is today, would be comparable.
    - lostcolony 6y ago
      In which case I'd say "singlehandedly" applies equally there, too. Still hyperbolic, but still representative of the degree of effort involved.

jeremy_k 6y ago

Exciting to see that heavy numerical computation might be available to a language running on BEAM. It has always seemed to me like an area that people would point to where Elixir couldn't stand up to Python. I've always dreamt that someday you might be able to reach for Elixir and get everything you needed for an entire stack of a company and it seems to be getting closer and closer. The building blocks for a web app have been around with Phoenix and Ecto for quite some time. LiveView was introduced to make more user friendly frontends. GenStage, Flow, and Broadway introduced ways to run data processing pipelines. And now we're seeing the initial steps to potentially have ML capabilities.

dimitrios1 6y ago
I am almost convinced to go all in with the elixir ecosystem. Having been a victim of a similar type of thinking, however, I am not sure this is the best thing to do so I am skeptical. Remember, Java and the JVM essentially have this today: front end frameworks, back end frameworks, data pipelines, big data processing, entire databases, etc. In your opinion, what will make the Elixir flavor of this situation different?
- mgreenleaf 6y ago
  I think Elixir has the potential of being like the JVM but for functional distributed programming. The JVM is fantastic and I do most of my work on it, but having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition. Especially with the easy interop of languages & functional aspects. I don't think it will surpass the JVM, but I think it has a lot of potential in its own sphere of influence. Especially if the library support & technical contributions keep coming.
- dragosmocrii 6y ago
  Code elegance and development joy, maybe? I know Java has a mature ecosystem, but I wouldn't touch it with a stick
  - deleted 6y ago
    [deleted]

tomphoolery 6y ago

When does the actual news start? Clicking around this podcast is annoying.

graydsl 6y ago
It starts like 8 minutes in. The whole podcast is about Nx basically.

deleted 6y ago

[deleted]

pantulis 6y ago

For this to gain traction needs to be adopted by the data-science community. It does not feel like that.

sfusato 6y ago
How did you measured that already? The "baby" is yet to be born. We found it's "name" just a few hours ago.
- pantulis 6y ago
  Fair point, let me try and ellaborate. Of course, time will tell. But the data science community fixation is on algorithms, not on languages. So you would need to build Tensorflow or Pytorch upon Nx, and you would need to migrate people from the easy Python/Anaconda/Jupyter to the BEAM world. For that to happen the upside should be obviously evident, I guess in terms of performance. Take, for example, the web world. I believe Phoenix is technically the best framework out there, or at least on par with Rails. And it has not taken the web world by storm (yet). Why would Nx be a success without the support of Google or someone that big?
  - detaro 6y ago
    Why must "take the X world by storm" be the goal?
dnautics 6y ago
I'll tell you why I'm cautiously bullish on Nx. 1) python really does not have broad cultural discipline around testing. Especially not in the ml field. 2) deploying python is not the best. 3) unlike TF, torch is actually not hard to understand and the code should be easily movable and portable out of it. Small time ML users will care about 1&2. 3 makes it relatively painless.
bcardarella 6y ago
The project isn't even public yet, has been under development for only a few months, hasn't had the opportunity to get wider academic eyeballs on it yet, and you're already calling it DOA. Nice.

andrewflnr 6y ago

What a grand find for a logo/mascot: https://twitter.com/josevalim/status/1356880707474370560 https://twitter.com/josevalim/status/1356880707474370560. An cute animal whose name sounds like "number" for a numerical computation project... and no other similar project has taken it already? I should be jealous but it just makes me happy.

JamesSwift 6y ago

Sigh... nx is already a (well known) thing in the dev space. https://nx.dev/ https://nx.dev/

deleted 6y ago
[deleted]
ashton314 6y ago
I think just slapping “elixir” at the beginning of the search query will help with the discoverability. Maybe if it gets consistently marketed as “Elixir Nx”, this won’t be a problem. Elixir’s documentation is so good, however, I would expect most questions will be answered by the documentation directly.
- JamesSwift 6y ago
  I agree, adding elixir is the likely solution, but my point is "why?". There's no reason to start off on that foot on day 1. And right now is still day 0 so there is still time to rethink it.
  - ljm 6y ago
    What if they did think about it and decided they still wanted to stick with their preferred name? It's like with trademarks: you can have more than one thing with the same name and not have a problem. If it was another build tool that helped you deal with your git repos that would be a real issue, but it's not... it's aimed at a totally different audience for a totally different reason. This town is absolutely big enough for the both of them. Or do you think other people have problems because when they search for, say, Kafka, or Jekyll, they keep finding references to literature instead of the tech they're using?
bcardarella 6y ago
Sigh... another Sigh... complaint on HN about naming... sigh... <head desk> Thank you for sigh... pointing out sigh... the obvious sigh...

auraham 6y ago

Numerical Elixir? Exciting news! I wish it would be something like Numpy. It would be awesome.

heeton 6y ago
That’s what it is :)

andy_ppp 6y ago

Just from my point of view the actor model seems ideal for simulating three dimensional systems at various levels of fidelity. An actor could exist that does maths for one region (say air in a climate change simulation) and that cube could send messages about its state to various surrounding regions/actors (cubes at the top, bottom, left, right, front and back) and affect them. The more cubes in the system the higher quality the simulation. Obviously this being on the beam you’d get the ability to run these actors across different computers fairly easily, hopefully scaling quite well. You could also build FDTD systems like this and even acoustics simulations. I wonder if this is something the authors here are thinking about?

ramchip 6y ago
Modelling a problem like this with tons of Erlang processes tends not to go very well: - It's slow, really slow, and memory heavy. All communication between processes involves copying and context switch. - It's easy to introduce deadlocks (A calls B calls C calls A - now system is stuck) or unbounded message queue growth (if you use casts rather than calls) - Everything is a single unit of fault tolerance (if one cell crashes, the entire simulation should be re-initialized from a known state) so all the processes need to be linked together in a massive web, which more or less defeats the point of process isolation. I think it might make sense in the abstract actor model, it just doesn't map cleanly to Erlang processes.

ashton314 6y ago

I’m excited that some neat problems were solved at the level of the programming language. Example: by working with the AST, Nx can automatically differentiate functions. It’s delightful to see how much care has gone into designing Elixir. It’s like José smuggled a Lisp in Ruby’s clothing onto the BEAM.

appleflaxen 6y ago

Jose Valim is so prolific; I love seeing what he comes up with.

mercer 6y ago
I like this comment on the forums: > “Hey, what did you do over Christmas?” > me: “I drank too much and tried to read a book” > Jose Valim: “I rewrote my language’s kernel to afford tensorflow-like operations for efficient ML operations”

nudpiedo 6y ago

honestly I think it would have been more profitable to modernize ErlPort to better interconnect with the python ecosystem and even other programming languages. I think it will be difficult to move some companies away of their current computation frameworks.

josevalim 6y ago
A couple notes: 1. Work on modernizing erlport can still happen and be orthogonal to this 2. Moving data in and out of the GPU is expensive, sending the data to another process so it can copy it to the GPU would make us pay the penalty twice (and then again on the way back) 3. And even if you want to go ahead with 2, I would do it over the wire so I don't couple my nodes running Erlang/Elixir to the nodes running the Python stuff (because they may require different specs/scale) 4. We don't need people to move away from their computation frameworks, I will be happy if people start considering building new things on top of this one in the future :)

halotrope 6y ago

Slightly tangential. I really would like to thank José for creating all of this! I have been using Elixir a lot and the language, the ecosystem and the community are amazingly cohesive, friendly and put a strong emphasis on good uncluttered design. If it was not there, something would be sorely missing. I was wondering if something like nx was coming. Together with Flow and Beam you can put the better part pf GCP in one binary with a few lines of pretty code.

josevalim 6y ago

Hi everyone, thanks for the enthusiasm so far! We are going to make the repository open source next week and, for those who haven't listened to the podcast, I want to align everyone's expectations and say it is very early material. Expect bugs, breaking changes, etc. On the other hand, it is also a great time for anyone who wants to jump in and help shape things, so feedback will be very welcome!

dnautics 6y ago
(I'm the guy who guessed correctly and got early access). Sorry I have been busy with my main job and haven't been able to contrib much in the past couple of months or so, but I just took a look at it and it looks really good so far. I think some of the architectural things are well-considered, and also, one thing that I forsee is "calling out to a remote gpu", where the nx library itself can be used by a node that doesn't have a gpu, instead of having the node with a gpu expose an rpc to the gpuless node. I guess a relevant analogy here would be the difference between graphQL and REST, but possibly also allowing the gpuless node to gracefully degrade to cpu, if the gpu resource isn't available. The Nx API will likely present an opportunity to also make data gravity abstractions cleaner. I think the elixir/erlang way of thinking about "concurrency as a special case of distribution" will apply to Nx, except "gpu as a special case of distribution" which means there won't be a leaky abstraction for remote gpu. I tried to get the Julia folks to adopt this sort of an attitude towards the juliagpu, but I'm a bit of a nobody so it didn't take. Very excited! And I'm whipping up a little bit of something interesting related to Nx myself that hopefully I can release around the time of your talk, but I don't want to make any promises yet.
- rising-sky 6y ago
  > I guess a relevant analogy here would be the difference between graphQL and REST There is more than one difference between GraphQL and REST, could you clarify this analogy? Thanks
  - dnautics 6y ago
    Good point. The relevant analogy is that in GraphQL the client defines the query that gets run and in REST the server defines the query that gets run. So one way you could architect Nx is to have your elixir running on the gpu node expose a handful of prebaked functions and allow your client elixir node issue requests to those prebaked functions ("REST"). But I think a bit more exciting would be to have your gpu node running a relatively dumb Nx server, and have your gpu-less client running Nx, where its math instructions get serialized using a thin "network device" backend instead of a "gpu backend", over to the gpu node, then the gpu node does the math and comes back with the answer ("GraphQL"). For even longer-haul operations you would want to do things like figure out how to represent datasets with tokens that are cached remotely. I think this all is possible, and, relatively easy with the Nx architecture.

Grimm1 6y ago

This makes me happy, love the elixir scene have used Matrex to good effect and wrote a pipeline recently that processes over 10gb (disk IO on the third party service bottle necked us or it would have been a lot more) data a minute through Broadway. Elixir + BEAM are good technologies and looking forward to having more numerical computing capabilities directly available in the language. I had spent a little time trying to contribute to Tensorflex which was a google summer of code project for TF in elixir but life got too busy to proceed and then I didn't see any movement there so just figured the idea of ML was on pause and outside of Matrex numerics were also on pause. Happy to see it was still going on behind the scenes.

ddragon 6y ago

That seems the start of something pretty amazing, I work on a fintech using Elixir and we usually have to delegate all numerical analysis and ML stuff to python microservices, even models with considerably simple execution, and being able to move that logic to Elixir would certainly be very nice (we can always batch train them elsewhere, just running the model is a great deal). Of course, it's definitely going to be a long road before getting to be production ready and somewhat competitive with the ever improving big players (as it is with all languages without supports from major corporations with large interest in the area, languages like Nim, Julia, Clojure and even Swift considering it doesn't have full support on Google, and those languages still have an advantage with their stronger interop with python/java/C). But after listening to the talk, I went from thinking that Elixir was not a good fit to ML to actually excited with the future. Elixir's pipes are definitely a beautiful and concise way to define transformations, and we already have nice examples of them with Streams and Ecto.Multi that even make it surprisingly nice to debug the readable "tape", and being immutable itself allows it to nicely avoid the hardest parts in translating the language into an execution graph both for the creators of the library and for the user. Modifying the if macro to embed the conditional within the "tape" might be a little too much magic though.

lesotholand 6y ago

Will it use Apache Arrow data format?