Live data from Hacker News

Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

news.ycombinator.com

271–280 of 297 posts

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#271
post #31

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elix…

oh boy. where to begin > We built a few services So you never really committed to it in the first place. Also, this complicates the deployment problem. > after a few years some of the original people that introduced it left the company Probably left for a company that actually committed to Elixir. :P > and it became very difficult to hire for In a world where everyone is remote and where 10 Elixir people apply to eve…

> In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing

That's really inaccurate, not everyone is remote and looks like post COVID most companies will be hybrid office/remote. So hiring is still a problem, and getting hired is a problem for people who don't want to be 100% remote.

> "We can underpay cheap devs again"

I don't think Rails devs are particularly cheap though I'm not sure if that's what you meant.

> mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel)

Rails comes with parallel testing since Rails 6. As for concurrency - I know that Gitlab moved to Puma (a threaded webserver) and tons of huge companies use Sidekiq which is threaded as well. I'm not saying there are never any problems but it seems to work well for many many companies.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#272
post #246

Earlier quoted context omitted.

Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones. Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines. Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless a…

In my personal experience (the last bunch of companies I've been at) that milestone you mention is more like what is the current fashion and what the new hires want to work on because of the latest blog post they've read. At my previous job we had * ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the fro…

The CTO should be fired, what the hell. In fact maybe we should start naming the companies (not the CTOs I will respect their privacy) so we can know where NOT to work.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#273
post #201

Earlier quoted context omitted.

Those advantages are really overblown and not worth the hit in missing libraries or missing hires.

Totally agree. I've been in this industry since 2001 and never, ever had a performance problem which couldn't be solved with just thinking what your code is actually doing. The bottleneck has been always the database, or the network, etc. The only problem I've had with threaded languages is running out of threads/processes due to making external API network requests, etc, but you learn to not block threads by using j…

I fully agree with you, but the demographics in HN is special -- you may be talking to people who work at Google-scale :P

Anyway I believe you really need a very special case to make Elixir shine. Obviously you can build whatever you want with it, and it's really nice, but if you are doing consulting you are going on for a hard sell. And startups will sooner or later feel the crunch of more expensive and/or difficult hiring.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#274
post #31

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elix…

Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones. Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines. Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless a…

I really don't see any reason to move from Rails other than a new CTO trying to shake things up with a tech he's more familiar with. If Shopify/Github/Gitlab/ can build it on Rails so can you. If the monolith is too big you can break it down with engines or to separate apps. Now I like Rails but I would say the same about PHP/Node or most popular stacks. Rewrites to another language are almost always unnecessary.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#275
post #10

If you invest time learning Erlang everything around Elixir will make sense and it will be a pleasant experience not only to "write" but to test, debug and maintain as well. I would go through this slightly dated but gentle introduction before learning Elixir: https://learnyousomeerlang.com/content Thinking in processes and knowing/using the GenServer abstraction is the core of Elixir programming. So, one negative is…

> If you invest time learning Erlang everything around Elixir will make sense

But this seems like a big issue to me. It probably makes the learning curve high if u basically need to learn 2 languages.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#276
post #81

Earlier quoted context omitted.

I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)

> complains about tooling in IDEs >> I strongly disagree (doesn't use IDEs) ??

"Tooling is just terrible." <- this is a generalization, to which I strongly disagree :)

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#277

We’ve skipped so many additional things like Redis, Memcached, Sidekiq and tons of libraries because it’s so easy to write a module to replace stuff. Switched from ruby to elixir 4 years ago and the only time we touch ruby is to maintain some old system. It’s so darned easy to add functionality to an exiting app that you have to be careful of bloat. And the functional paradigm is like second nature now. It’s hard to…

How do you deal with deployments and not losing things you could otherwise persist in Redis or Memcached? Of is your application stateless in that way?

[deleted]

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#278
post #196

Earlier quoted context omitted.

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Really appreciate the effort that you've put into this post but it's 99% saying you can do better but without examples of stacks that would be better. For those who don't have your knowledge could you provide some examples?

The core insight of Erlang is that having lots of little processes communicating over a message bus is a great way to design code. It also proves by demonstration a statement that many programmers, especially in the past decades, would have found hard to believe, that you can structure code as a whole bunch of relatively small self-contained services. Many programmers, perhaps even today, would not believe how far yo…

This comment sold Elixir for me more than anything. On a small team, each of those are massive headaches. Using Elixir I can have all of that with a unified vocabulary, documentation, deployment, syntax, repository, etc. Sure, each might be slightly worse that the best thing on offer today, but I don’t have to glue them together.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#279
post #31

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elix…

oh boy. where to begin > We built a few services So you never really committed to it in the first place. Also, this complicates the deployment problem. > after a few years some of the original people that introduced it left the company Probably left for a company that actually committed to Elixir. :P > and it became very difficult to hire for In a world where everyone is remote and where 10 Elixir people apply to eve…

I’m sitting in Africa and I can whisper “Elixir job” out my bathroom window and have 10 people interested in it. Maybe it used to be difficult.

Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

#280

As an SRE who has had to baby sit production elixir apps I'd highly recommend first having a talk to your operations guys. I've never had a more challenging system to debug and keep running. It's only a matter of time until you hit something as confusing as https://elixirforum.com/t/dbconnection-connectionerror-pid-x...

> I've never had a more challenging system to debug and keep running.

Heh, the core system I put in place at work 3 years ago and is updated daily has never gone down once. Isn't that the point of the BEAM and supervision trees?

It's different, requires to learn a new skillset, but I wouldn't call it "challenging to keep running."

Post reply on HN