Live data from Hacker News

Would you still pick Elixir in 2019?

github.com

101–110 of 246 posts

Re: Would you still pick Elixir in 2019?

#101

Earlier quoted context omitted.

> Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. I still don't understand this. I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure. The amount of fault tolerance would be a per-app design goal rather than something…

You are not wrong. The OP is also not wrong. I think that the examples might not have been ideal. The fault tolerance that I love about Erlang/Elixir is the actor model. Everything is (or can be) an actor, which is like a living and breathing instance of a class. So they can live and do their own stuff, and then if they fail at that and need to be recreated, they get recreated by something that supervises them. Contr…

That's not necessarily the case, especially with asynchronous actions (speaking for Python, at least). One execution can crash and burn unexpectedly, but the entire runtime doesn't go down.

Re: Would you still pick Elixir in 2019?

#102

I’ve been programming in elixir for about 2 years now. I have to say it’s hard to go back to something like Ruby or JavaScript. In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code…

> If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-le…

Until I used Elixir, I thought workers/queues were enough. But after the last nearly-three-years, I've actually fallen into a place where workers/queues are almost always strictly inferior.

Workers/queues in languages like Ruby have problems like,

* Require very specific ergonomics(for example, don't hand the model over, hand over the ID so you can pull over the freshest version and not overwrite)

* They require a separate storage system, like your DB, Redis, etc. This doesn't sound big, but when doing complex things it can turn into hell.

* They have to be run in a separate process, which makes deployment more difficult.

* They're slow. Almost all of them work on polling the receiving tables for work, which means you've got a lag time of 1-5 seconds per job. Furthermore, the worse your system load, the slower they go.

* You can't reliably "resume" from going multi-process. Lets say you're fine with the user waiting 2-3 seconds to have a request finish. With workers/queues, you either have to poll to figure out when something finished(which is not only very slow, but error prone), or you have to just go slow and not multi-process, making it into a 8-10 second request even though you've got the processing power to go faster.

So, you've got all that. Or in Elixir, for a simple case, you replace `Enum`(your generic collection functions) with `Flow` and suddenly the whole thing is parallel. I mean that pretty literally too- when I need free performance on collections, that's usually what I do. Works 95% of the time, and that other 5% is where you need really specific functionality anyway, and for those, Elixir still has the best solution to it I've ever seen.

Re: Would you still pick Elixir in 2019?

#103

I've been working with Elixir in a single-developer production system for over a year now. I'm running it in Docker containers on Kubernetes, in the cloud. It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir. Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediat…

Elixir is a great tool for some applications, but one should always think carefully about what is the right tool for the job at hand. Elixir is not the only language that helps enormously with concurrent programming. Specifically, Clojure is very comparable in this regard, although it gives the programmer much more freedom. And then it has Clojurescript, which makes writing hybrid server/client apps much easier.

I've written large applications in Clojure/Clojurescript and I've seen/reviewed reasonably large code bases in Elixir, and while I would agree that Elixir is a very good solution for many problems, it is not a tool for everything.

Re: Would you still pick Elixir in 2019?

#104
Yes! And most likely in 2020 as well.

I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively.

In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention the ecosystem only gets better by the day.

So yeah, Elixir is one of my main tools when I want to get things done elegantly and productively. And if for some reason I need to speed things up a bit here and there, I just add a little rust into the mix. [1]

[1] https://github.com/hansihe/rustler

Re: Would you still pick Elixir in 2019?

#105

Yes! And most likely in 2020 as well. I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively. In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention th…

What sort of work have you been doing with it?

Re: Would you still pick Elixir in 2019?

#106

This post is killing me. I’ve been really really loving Elixir and for a while was fighting the “everything looks like a nail” syndrome once I learned it. But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don’t have enough production Elixir experience to have confidence in myself to deliver something of the right caliber.…

Honestly? I'd still encourage you to do it. The thing that's nice about Elixir, is that it gives you the tools to screw up and make good on it.

This isn't to say you'll write great Elixir from the beginning. I'm on a codebase now that was from back before the semantics of good Elixir were really well known(2016). It's not uncommon for me every week or two to rewrite a portion of it to look cleaner, and be more performant.

The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers.

We're still on one box. We still have plenty of the old, harder-to-read, less-performant code. And it still takes under 10 minutes to understand the deepest inner workings of any one feature in the system.

I think you'd be pleasantly surprised.

Re: Would you still pick Elixir in 2019?

#107
>> Node is a single-threaded event loop, if the process crashes for one user, it crashes for all the requests being handled by that process. i.e. one user can crash the server for hundreds/thousands of people! This is a terrible design flaw

This is a design flaw on the part of the team who is using Node.js incorrectly and not a flaw of Node.js itself. There are many ways to implement error handling properly in Node.js so that a user cannot crash a whole server/process and there are a lot of frameworks which implement this by default.

Elixir is over-marketed and over-hyped. It's obvious that there is a big money machine behind it. The entire community is obsessed with evangelizing; they're not getting organic growth; they have very aggressive marketing but it's mostly founded on exaggerations and flat out lies.

In addition to what I've pointed out above, to say that someone can learn Elixir in just 1 week is another example of a lie. It takes years to fully understand the nuances of a language to the point that you can be good at it; there are always a lot of patterns to learn; especially for functional programming languages.

The Elixir ecosystem will never be as significant as that of Node.js because Elixir's ecosystem is founded on hype. Part of the greatness of Node.js is that reality tends to exceed expectations; so-called 'thought leaders' and 'bloggers' have been working very hard to discredit Node.js from the beginning but they failed (see https://news.ycombinator.com/item?id=3062271).

I'm not going to consider using Elixir while it's so clearly over-marketed and over-hyped.

Re: Would you still pick Elixir in 2019?

#108
post #99

Earlier quoted context omitted.

Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.

Uh, what? It might've become the defacto standard for consuming them, but definitely not for creating them. Almost no service I've ever administered used a nodejs backend.

He never said anything about node being prevalent, only that Express was within node.

Re: Would you still pick Elixir in 2019?

#110
post #105

Yes! And most likely in 2020 as well. I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively. In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention th…

What sort of work have you been doing with it?

I've been writing a social collider for real life social interactions on demand. The backend is written in Elixir (which is a collection of services e.g chat subsystem, telemetry, authentication, rate limiting, etc) and the client is an iOS app, so Swift, which is also a nice language btw.
Post reply on HN