Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#121

Post by choiway »

A couple thoughts after using it for a couple years.

1. It actually takes a while to get your head around the fact that the biggest advantage of elixir is having access to the battle tested features in OTP. It takes longer to realize that these benefits don't come for free and elixir might not be the best solution to your problem.

2. The learning curve for writing functional code is different for different people. As a result, it's impossible to figure out before hand how long it will take a team used to writing pythonic code, for example, to start writing functional, elixir code.

3. You're able to emulate something like type checking between pattern matching and ecto schemas but it's not type checking. Be prepared to spend time coming up with best practices for writing tests.

Re: Ask HN: Who regrets choosing Elixir?

#122

Post by PragmaticPulp »

nicoburns wrote: post #107
as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Why not get your existing engineers to learn erlang if you have such a need?

Because engineers don't take kindly to companies changing the direction of their career development.

If you're an up-and-coming Golang developer, how happy are you going to be when your company takes you off of a Golang project and makes you the new Erlang person?

Now how happy are you going to be when you're informed that you're learning Erlang to maintain an old, flakey codebase written by 2 guys who left the company and are now unreachable?

Oh, and you're going to need to be on call for this because no one else knows how to fix it.

Re: Ask HN: Who regrets choosing Elixir?

#123

Post by dnautics »

rorygreen wrote: post #118
hartator wrote: post #102

I’ve played with Elixir/Phoenix a little bit and was not very happy with a few things: - Debugging is hard. You can’t throw a REPL wherever your want in your code and pipe states are hard to inspect. - Serving static files in Phoenix is oddly super hacky. - Deploy is hard. Mostly by the lack of support out there in term of documentation and services.

> You can’t throw a REPL wherever your want in your code In my experience, I found I could throw a `require IEx; IEx.pry` pretty much anywhere in the code to get a REPL. This seemed like a unique superpower of Elixir to me. Where have you found that this isn't possible? I agree with the pipe states point. My main complaint with Elixir is that I'd discover really stupid mistakes with run time errors. The sort of thing…

dialyzer is terrible, but vscode/elixir_ls + dialyzer is quite frankly amazing.

Re: Ask HN: Who regrets choosing Elixir?

#124

Post by jeremyjh »

dnautics wrote: post #112
pavel_lishin wrote: post #97

Earlier quoted context omitted.

> Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.

This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer…

It probably depends more on where they are coming from. Mox has more overheads for sure than options in Ruby or Javascript. Its more like mocking in Java or C++; where you declare an interface(behaviour), program against that, and then use dependency injection to load the mock or real code at the right time. I'd been working with Elixir for several years when I first tried using Mox and it still took awhile to get my head around it and figure out how to integrate it into our project. I would not be surprised to hear that newer teams really struggle with it.

Re: Ask HN: Who regrets choosing Elixir?

#125

Post by rlander »

as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.

Re: Ask HN: Who regrets choosing Elixir?

#126

Post by bluesnowmonkey »

pavel_lishin wrote: post #94

My employer has chosen it, and while it was fun to learn and is very neat, I don't think I'd ever write Elixir code for anything but a hobby project, especially if a large team is working on it. 1. Dialyzer is just a huge piece of shit. It's an incredibly impressive piece of shit, and makes it possible to pretend that Elixir supports typing, but it has so many edge cases that we've run into them writing even trivial…

With regard to mocking, I’ve found that it works better to swap in a fake process rather than a fake module. If you have a FooClient genserver that makes RPC calls to a service or database, make a FakeFooClient that responds to the same kinds of genserver calls and returns canned responses. Or even implement a simplified version of the external service in the genserver.

Re: Ask HN: Who regrets choosing Elixir?

#127

Post by RSZC »

ajkjk wrote: post #116
eshyong wrote: post #111

Earlier quoted context omitted.

Probably cost of training. You'd have to hire consultants to teach best practices and that could cost significantly more than hiring a new engineer. Plus there are other risks to maintaining two codebases in different languages.

You have to hire consultants to teach best practices?

Honestly it's not a bad idea. Erlang is not a language that is easy for an experienced engineer to pick up and quickly create maintainable code.

Re: Ask HN: Who regrets choosing Elixir?

#128

Post by jeremyjh »

I've been developing Elixir since 2013, and professionally full-time since 2017. Honestly my only complaint is the lack of static typing. There is no way I'd prefer Ruby; Elixir gives you a lot more compile time checking and static analysis. As a project gets larger, it gets harder and harder to refactor because of the despair that sets in when contemplating fixing dozens or hundreds of broken tests that you can only discover by running them.

I really don't know what I'd prefer to it though, every language has its pros and cons and static typing systems while nice also can introduce their own problems. I've spent days tinkering with type abstractions in Haskell rather than getting work done - not because I had to but because I knew more expressive solutions were possible and the allure of them was too hard to resist. Elixir is a fantastic language for getting work done.

Re: Ask HN: Who regrets choosing Elixir?

#129

Post by brazzy »

PragmaticPulp wrote: post #122
nicoburns wrote: post #107

Earlier quoted context omitted.

Why not get your existing engineers to learn erlang if you have such a need?

Because engineers don't take kindly to companies changing the direction of their career development. If you're an up-and-coming Golang developer, how happy are you going to be when your company takes you off of a Golang project and makes you the new Erlang person? Now how happy are you going to be when you're informed that you're learning Erlang to maintain an old, flakey codebase written by 2 guys who left the compa…

So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? That way it's a broadening rather than a redirection of their career, they can help each other, the on call duties are shared, and the business isn't dependant on a single person.

Re: Ask HN: Who regrets choosing Elixir?

#130

Post by aethant »

nicoburns wrote: post #107
as-j wrote: post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Why not get your existing engineers to learn erlang if you have such a need?

All well and good if the engineers want to learn/work with that language. But not everyone does. I’ve left jobs over forced decisions like this.
Post reply on HN