Live data from Hacker News

What I mean when I say that machine learning in Elixir is production-ready

cigrainger.com

61–70 of 108 posts

Re: What I mean when I say that machine learning in Elixir is production-ready

#62

Earlier quoted context omitted.

Same reason you don't see taken over the world. The demands of the world are different to the demand of small passionate communities.

The demands of modern web platforms actually run really close to BEAM's strengths. It's still an interesting question but "enthusiasts are naive and wrong" isn't the answer.

I didn't say what you quoted

Re: What I mean when I say that machine learning in Elixir is production-ready

#63
post #42

I see so much breathless adoration for Erlang and Elixir, how come it hasn't taken over the world in all this time?

As someone who was Elixir hire #1 at a company that eventually ended up with ~25 Elixir developers with a novel product that people actually used, I see people in this thread and elsewhere mentioning the unorthodox nature of the language or the supposedly poor performance, and I can tell you that none of that actually matters one way or another. The stuff that really hampers Elixir/Erlang adoption, in my own personal…

Great write-up! I've been using Elixir for a handful of years now, primarily working on solo/consulting projects and in micro teams. I'd like to think I have a pretty good grasp on the language and OTP fundamentals, but I'll admit that some the things you mentioned in your last paragraph about lacking knowledge of operational concepts resonated with me.

Over the years I've tried to learn more about releases, deployments, distributed applications, fault tolerance in environments with multiple nodes, and hot code upgrades; but none of the projects I've worked on have reached sufficient scale or complexity for those things to really matter. My impression is that it's difficult to learn about these topics without real hands-on experience (something that seems hard to replicate in small/solo projects).

Would you mind expanding on that last point? I'd be curious to learn more about these knowledge gaps that you observed, as well as any recommendations for "leveling up" past them, whether it be projects that one could build to learn more, books to read, etc.

Re: What I mean when I say that machine learning in Elixir is production-ready

#64
post #2

I'm a big fan of Erlang, Elixir, OTP and the BEAM vm. However, I only have very lightweight server needs for my SaaS, so it just doesn't make sense to switch to it, especially as my code is mostly client-based/typescript. If my core value prop would be around real-time messaging or streaming data, BEAM/OTP would be my first choice. Slightly OT: I'm still in dubio about Cloudflare pages, but I'm sure that the platform…

I am really intrigued by the distributed systems capabilities that BEAM brings. I built a chat app using it and am also using Mnesia DB to store recent messages. However, my experience coding it has been terrible. I am using IntelliJ with an Elixir plugin and there is essence is no auto-complete. I used to write a ton of Ruby, but there RubyMine was really good at guessing what's available. Not so much here. On top o…

I've had success with the ElixirLS language server. It should work with most editors I assume, but I use it with Neovim. Autocomplete, diagnostics, goto definition work as expected.

Re: What I mean when I say that machine learning in Elixir is production-ready

#65

I see so much breathless adoration for Erlang and Elixir, how come it hasn't taken over the world in all this time?

TBH part of the BEAM runtime is actually pretty slow. is the problem. * Want something flexible and easy and don't care about performance? Use Python * Care about performance? Use Rust, etc. Just because it is distributed cloud native doesn't mean for single requests or functions it is fast. Almost all SaaS applications are request based and do not need P2P or real time communication. BEAM is worse here. If a company…

Out of the box, Phoenix applications respond to simple http requests in times measured in microseconds. What appreciable improvements from that do you get with Python? And considering how much of your total request time is not processing by the language (db calls, network latency, etc.), why would you decide on a language purely on the minor speed improvement of a small part of the overall picture? I’ll gladly trade what might amount to a few ms of request time for the concurrency model, scalability, and latency characteristics of Elixir and the BEAM.

To each their own, I suppose.

Re: What I mean when I say that machine learning in Elixir is production-ready

#66

Earlier quoted context omitted.

Enforcing use of mypy is good enough for all real world use cases https://mypy.readthedocs.io/en/stable/index.html

How is this different to typespecs and Dialyzer?

This is in the works right now: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...

Re: What I mean when I say that machine learning in Elixir is production-ready

#67

Earlier quoted context omitted.

Elixir is a combinatorics mess (circa 2020: two different string types, three different types of exception, return AND throw versions for almost every func, slow compiler without much in the way of compile-time checking, constant breakages over trivial renamings "just because", having to burrow into erlang errs half the time since many elixir funcs are just wrappers). Half the libraries we used were abandoned. I take…

> Half the libraries we used were abandoned People really need to unwarp their brains from how they judge libraries in Elixir compared to other ecosystems. Erlang is 30 years old. Elixir sits on top of that stability. Elixir will very likely never reach 2.0 because it doesn't need to. And if a 2.0 does come it will be simply to remove deprecated functionality. Not having 12 major version releases per year means what…

If the libraries worked, we wouldn't have had to play code archaeologist and find out that half our dependencies had been abandoned since 2017. Even something as simple as a JSON encoder--which is rock-solid in every other language I've used--had a number of bugs (this was four years ago, so memory is hazy, but it had something to do with ambiguity between arrays, lists, or tuples) Erlang is stable, but Elixir sure as hell isn't. Back in 2019, it seemed as though every point release brought a slew of breakages--and usually over the most trivial and pointless things, like adding an underscore to a built-in for "consistency". I've been developing for over 20 years, have used all of the mainstream languages, and Elixir was the absolute worst.

Re: What I mean when I say that machine learning in Elixir is production-ready

#68
post #25

Earlier quoted context omitted.

I think we need to give it time. Python had a slow and steady growth from 1991 until today and it has eaten so much of the data analysis and ML world (backed by C++, C and more recently Rust). But python doesn't vertically scale very well. A language like Elixir can grow to fit the size of the box it is on, making use of all the cores, and then without too much additional ceremony scale horizontally aswell with distr…

> Python doesn't vertically scale very well Strong disagree, this is a skill issue. I have written C++ modules for Python with pybind11 to speed up some code significantly but ended up reverting to pure Python once I learned how to move memory efficiently in Python. Numpy is very good at what it does and if you really have some custom code that needs to go faster you can run it externally through something like pybin…

I said python doesn't scale well and you say "it does if you use an escape hatch to a faster language"

Sure. Writing C++ that utilises your resources effectively then writing bindings so you can use that in python is great. But with elixir, if I've got 8 cores and 8 processes, those 8 processes run in parallel.

If I want raw cpu speed I can write something in rust, c, cpp or zig and then call it still using elixir semantics.

Not to mention that with Nx you can write elixir code that compiles to run on the GPU. Without writing any bindings.

Re: What I mean when I say that machine learning in Elixir is production-ready

#69
post #9

I see so much breathless adoration for Erlang and Elixir, how come it hasn't taken over the world in all this time?

Because embarrassing little in coding is controlled by these imagineers. There’s no much real difference in programming languages anymore, honestly I’ve never met a good programmer that cared about these, it makes your code fringe and inportable.

I do not write Elixir/Erlang programmers. But I do think that the actor model and BEAM solve a few issues that I face when writing complex backends, which I do.

For example I have not found a language whose error handling I like - Go and Rust are super meticulous, for example and you get error handling code everywhere, which is good for stability but not great for developer experience. TS/JS/Node suffers from the opposite - error handling is an afterthought and you never know what exception will come at you and from where and bomb you whole server, so you end up relying on cloud solutions running large redundant arrays of processes. Isolation of errors within a process and message passing is a great abstraction.

Another thing is that I get to spend a lot of time on is setting up Redis/Cloud stuff to do basic queue, caching and cron. That stuff takes up time, increases complexity, creates new sources of error and grows institutional knowledge. Using a system which has those built into the language is a major improvement. Vercel/Deno/Bun/etc are solving some of the above by including them in their cloud offerings with relatively good DX, but it still increases complexity, takes you out of code and locks you in with the vendors.

Re: What I mean when I say that machine learning in Elixir is production-ready

#70

Earlier quoted context omitted.

Elixir is a combinatorics mess (circa 2020: two different string types, three different types of exception, return AND throw versions for almost every func, slow compiler without much in the way of compile-time checking, constant breakages over trivial renamings "just because", having to burrow into erlang errs half the time since many elixir funcs are just wrappers). Half the libraries we used were abandoned. I take…

How are there three different types of exception? As for "two string types" maybe I'm not working on hard enough problems, but in ~4 years of Elixir I've never once needed to use a charlist. My understanding is that it's a backwards-compatibility thing from Erlang and I'm not even sure when I'd ever need to use it over a string.

raises, throws, & exits. rescue vs catch. as for binary vs charlist, some dependencies wanted binary, others wanted charlist. faced with the choice of re-write the dependency to use binaries, or wrap it with pre/post converters, we chose the latter. after the third or fourth global search-and-replace thanks to elixir's renaming of built-ins just for the hell of it, we re-wrote it in go, and never looked back.
Post reply on HN