12 ms·

People will go through any number of hoops to not give, "I like the feel of the language more", as a reason for using it. Clearly, the main reason you would con

• giraffe_lady 3y ago
  I think BEAM languages are kind of one of the few exceptions to this argument. Its tradeoffs and runtime semantics really are just very different from other mainstream languages. Other languages & communities are adapting to modern trends towards high concurrency, distributed systems, horizontal scaling, tight fault detection & recovery with varying degrees of struggle and success. Meanwhile in erlang these have been priority concerns for decades and they have highly sophisticated refined solutions to them built directly into the system. Not that this article makes a good argument for the benefit of any of those things for ML. But at least generally while I am a pretty strong believer of "eh language doesn't really matter" erlang-based languages I do entertain a possible exception for.
  • rramadass 3y ago
    Agreed, You might find Handbook of Neuroevolution Through Erlang by Gene Sher interesting.
  • fzeindl 3y ago
    > I think BEAM languages are kind of one of the few exceptions to this argument. Its tradeoffs and runtime semantics really are just very different from other mainstream languages. Agree wholeheartedly. Elixir/BEAM/Erlang are a league of their own.
  • drowsspa 3y ago
    Never really played with the Erlang VM other than a little more than the Hello World in Elixir, but when I'm in the debugging hell of Apache Spark I really wish it wasn't based on the JVM.
    • kaycey2022 3y ago
      I think debugging in Elixir is easier precisely because of it functional immutable nature. To contrast it, take Ruby (Ruby on Rails) where objects will acquire functionality at runtime. That makes debugging particularly difficult especially if you have jumped into a new codebase with little context.
      • skrebbel 3y ago
        Java has breakpoints though.
      • chucke 3y ago
        Side effects free is a good thing? Sure. Easier to debug? Cmon, elixir MO is based on, if not copied from, ruby. If anything, elixir is as easy to debug as ruby, if you can claim such a thing (I don't have substantial XP)
        • sodapopcan 3y ago
          > elixir MO is based on, if not copied from, ruby That's flat out false. Only the syntax is taken from Ruby, that's it. Even the added metaprogramming isn't anything like Ruby's. It otherwise just like Erlang.
          • chucke 3y ago
            Elixir's most popular debugger tool is called pry.
        • kaycey2022 3y ago
          Not really. Elixir tries to use an approach to its "syntax design" that is similar to Ruby. But ruby goes all out in its approach to look like English. Elixir doesn't go that far. Other than that if you look at how the language works under the surface it is completely different from Ruby which uses Runtime Reflection to add methods to objects in memory.
• weatherlight 3y ago
  It's not the language specification that makes the languages special, its the VM they run on. (Elixir is a little more special with its hygienic macros, whi allow for for libs like NX to exist.) The BEAM/erlangVM is probably closer to a OS than a traditional-ish VM like the JVM.
• tikhonj 3y ago
  I unironically think this is an absolutely legitimate reason even in a purely results-oriented, commercial context... but saying that is not politically expedient :(
• throwawaymaths 3y ago
  The interesting thing about BEAM languages is that they naturally treat the gpu as an asynchronously communicating resource. No other language gets that abstraction correct.
  • qprofyeh 3y ago
    Just to inform the reader, the experimental WebGPU API does embrace async communications with rendering devices: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice
    • throwawaymaths 3y ago
      It's still not the same, because of the way js async works
      • qprofyeh 3y ago
        Curious why that is. How does V8 handle it differently?
        • throwawaymaths 3y ago
          V8 is asynchronous but single threaded, elixir gets m:n threaded. Job cancellation is trivial, safe, and automatically recovers the resource in elixir (the gpu devs have hooked cleanup in to the BEAM GC, because that is a thing). Moreover, if the caller of the agent asynchronously controlling the gpu is cancelled, it will also release the gpu automatically (in most cases, if you use the stdlib otp features instead of trying to build with primitives)
          • qprofyeh 3y ago
            AFAIK V8 does make use of threads internally via libuv in order to make truly concurrent system calls. GPU device comms should fit perfectly in that design.
• sodapopcan 3y ago
  What hoops? Your comment makes it sound like the author is hacking together some libraries that happen to exist just to do ML in Elixir. Numerical Elixir is a very real thing being actively worked on by the creator of the language. https://github.com/elixir-nx https://github.com/elixir-nx
• lawn 3y ago
  > but there is no way they are going to overcome the ecosystem deficiencies to make it worth while in any unbiased cost benefit calculation. Another way to say this is: "no other language will ever be better than X", which is clearly not true. Eventually something better will arrive. Maybe that's Elixir, maybe not, but is sure won't be Python forever.
  • wiseowise 3y ago
    > Maybe that's Elixir, maybe not, but is sure won't be Python forever. It will be Python for all of our lifetimes here.
  • zelphirkalt 3y ago
    I am just hoping, that when that better thing appears, it wont only be better because it makes use of what is available in Python via some FFI thingy, adding another layer of indirection and abstraction and overhead, but actually better from first principles, from the ground up, or at least not going via Python, to get a similarly big ecosystem.
• bmitc 3y ago
  > but there is no way they are going to overcome the ecosystem deficiencies to make it worth while in any unbiased cost benefit calculation Is there a concrete reason for that? A lot of the approach in Elixir is to not go the route of other languages and merely slap an adapter interface on Python libraries. The approach is to approach things from a very Elixir and BEAM specific point of view. This is how Livebook was developed and how the machine learning libraries are being developed. In fact, one could view it as Python being the one that's going to struggle to overcome the limitations set forth by its own language design. Elixir comes with very tightly integrated tooling (projects, testing, type analysis, static analysis, notebooks, scripting, etc.) that basically has 100% adoption rate without a plethora of third-party competitors and lack of integration with the language such as Python has. With immutability and concurrency built into the language, Elixir has a leg up, and there is active research into bringing static typing to Elixir and also binding Elixir to faster runtime environments, such as Rust. Python simply cannot make the jump to Elixir, Erlang, and BEAM's language and VM capabilities like they can to a machine learning ecosystem akin to Python's.
  • skrebbel 3y ago
    > type analysis, static analysis These two are so terribly, laughably bad in Elixir that you listing them as advantages makes me doubt the integrity of your entire post.
    • anonzzzies 3y ago
      Worse than Python? It's a question; I don't know. I do know that the two most terrible (for me; I like types and a working IDE that helps me, not fight me) languages (js/py) are also the most popular. I don't know what that means, but as I did build large systems with Erlang in the past (in banking) which are still running production with massive load (and don't fall down in 2 weeks because the ENTIRE ecosystem had a minor version update, invalidating all the ABI's), I cannot imagine it's worse than Python or JS. I hope you can tell me.
      • foldr 3y ago
• lawik 3y ago
  Oh, author here. I absolutely do simply prefer it but I also think it has distinct upside compared to Python in this context. I see a number of companies orchestrating their Python ML with Elixir. For them the advantage is even more obvious. But overall Elixir has certain strengths. It also has drawbacks and trade-offs. I would absokutely write the post "Why I prefer Elixir" and I think I have. But this was not intended to be that.
  • pg_1234 3y ago
    The reality is that neither Python nor Elixir is performant enough to do the actual work of ML, that is all going to be wrapped libraries in C, C++ ... Rust? And while Elixir may be as well suited as Python to being the interface/scripting language for ML tasks, Python has a pretty unassailable lead here with an overwhelmingly dominant ecosystem. Elixir could be used to build and manage pipelines (like a roll-your-own Jenkins) in this area, and in this regard (concurrency, reliability, async) it is probably a significantly better language than Python, but the actual tasks on the pipeline will need to be defined in Python, just because it's use is so entrenched. Also, the "reinvent something another language can already do" pitch is going to become a much harder sell in today's funding market as the silly money dries up.
    • sodapopcan 3y ago
      A lot of comments here seem to be framed around the idea that Elixir is aiming to some day dethrone Python. Knowing the Elixir ecosystem, I wouldn't even say it's the case that it's trying to gain equal market share. The Explorer library even calls out: "The aim here isn't to have the fastest dataframe library around". There seems to be a significant interest within the Elixir community around this and, as a non-data scientist who needs to do some analytics sometimes, I certainly appreciate having powerful tools like this without having to step outside Elixir. I've never had to learn about Python tooling and I'm happy to keep it that way!
• AlchemistCamp 3y ago
  The only reason I discovered Elixir was through an unbiased cost benefit calculation while working on my last startup. This was in early 2017, and my search essentially went from a variety of JS frameworks to RoR to Scala + Play and then eventually to Elixir + Phoenix. The ecosystem was much smaller then but of the options that were viable, it was by far the most productive.