Corroborate the "some libraries now feel unmaintained" view given elsewhere. Also the language itself and best practise seems to change now quite often and there's a bit of a tendency to do things in multiple ways through shorthand macros which can be a bit confusing (bit of the LISP problem going on here). That said the structure of my code is vastly better than when I was doing everything in Python trying to use multiprocessing and/or threads and/or asyncio.
Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
41–50 of 297 posts
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#42[deleted]
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#43We’re very happy with it, essentially using it as a full-stack front-end though, rather than whole app. This is partly due to resourcing issues, partly due to having an aint-broke don’t fix rails service that Elixir replaced part of (our CMS, specifically). I think the rails service will stay, the benefit of porting is just too low as we’re a small team.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#44Nice question, I'm just starting with Elixir for a side project. Has anyone else find it to have a steep learning curve? Coming from Java/Scala and Python, I find it harder to wrap around then Scala was years ago. Shortcuts with mix like mix phx actually make it a bit more complicated for me because I'm used to understanding what is exactly happening under the hood.
Getting hang of functional programming takes time. Writing code elixir way requires unlearning what you have learning from imperative languages.
> Scala
Scala isn't exactly an imperative language. If anything it's the actor model isn't exactly easy to wrap your head around
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#45I've had an niche event ticketing Elixir/Phoenix app in production for 4 years and have had next to zero problems. It gets very bursty traffic (100s of simultaneous users when an event opens for ticket purchases with load quickly tapering off in a negative exponential distribution) and the load average barely changes with insanely fast responses on a $10 VM. I think the only downside for me is having to squint sidewa…
I write very few fragments and many more raw queries. No ORM is worth the trouble of going too deep into the rabbit hole of learning for the nth time how to write SQL in X.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#46We chose elixir in 2016 for our product and never regretted it. Apart from application bugs we’ve caused, it just keeps chugging along and working beautifully. It’s never once been the bottleneck in our stack. Finding people has not been tough at our scale, and they’ve been good quality. We are just scratching the surface with OTP. And between that and the data processing tools, we know we can handle pretty much any…
55 / 2.62 (millions of seconds in a month) ~= 20reqs / second
That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR
But I guess your load is not constant. How many reqs/sec can it handle in the peak time?
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#47My 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…
> Specially now we are using all the hotwire stuff.
Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?
I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.
There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#48My 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…
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented
Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc.
Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.
For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#49Happy to have stayed away from it ever since.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#50I've been using Elixir/Erlang for more than 6 years and absolutely love it. The community is a lovely place to be, tooling is great. Concurrency is awesome. Erlang is battle tested. If you are building applications that have anything to do with networks, you'll be able to build some seriously performant apps without having to reach for other tools and I love the community's focus on performance.