A couple of guys at my company did their first startup using Elixir years ago, but they weren’t devs so they had to contract a company to do it. They regret it now because no one at our company can work on it, and they have to rely on the contractors who charge a lot. Sure someone could learn it, but we’ve got more important things to do. As much as everyone on HN loves it, you’re going to have to work hard to get ot…
Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
61–70 of 297 posts
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#62We 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…
I’d argue it’s worth the switch, but I’m highly biased!
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#63My 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…
I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.
If it's stupid and it works, it's not stupid. Fashionable is for runway models.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#64As 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...
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#65Earlier quoted context omitted.
> 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 to…
Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff…
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#66I think this is because FP doesn't put emphasis on separation of concerns like OOP does. FP advocates separating state from logic as being more important than separating concerns across components.
With OOP, if some piece of state concerns the same business domain as some piece of logic, then they should be co-located. On the other hand, FP will happily violate this principle in favour of keeping state and logic separate.
Having built highly complex, modular systems with OOP, I don't see how it would have been possible to implement these systems in such a modular way using FP... Co-locating related state and logic is absolutely essential to achieve modularity.
I have yet to see any complex FP system which was not spaghetti code.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#67My 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…
In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#68Earlier quoted context omitted.
> 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 to…
The trick is to use liveview for data that needs to come from the server anyway. I'd guess that the OP did use it for everything, like popups etc and did not do the same with hotwire.
That's what hotwire gives you: an opinionated approach and a golden path to do things in a manageable way.
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#69Earlier quoted context omitted.
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?
> 55 / 2.62 (millions of seconds in a month) ~= 20reqs / second I'm pretty sure Java 1.0 running on an Amiga could handle that...
Re: Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
#70My 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…
I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.
> 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. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.