Go with Django. Save yourself a lot of pain
-1 for this comment. It's unrelated.
Ask HN: Who regrets choosing Elixir?
91–100 of 340 posts
Re: Ask HN: Who regrets choosing Elixir?
#92TL;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, handle all the symmetric sessions, etc. It was a good tool for the job and in theory could scale well.
But, there's always a but. We're a Python shop on the backend and C on embedded devices. Engineers move on, there some lean times, and after a few years there was no one left who could support an Erlang system. So we hired for the position, and it's key infrastructure, but not really a full time project, so we hired a Python+Erland person.
But! Now they're on call 24/7 since the regular on call roster are python people and when the Erlang service goes wrong, it's call the one engineer. So, do you hire 2 or 3 people to support the service? No, you design it out. At the time is was 2018, and IoT services were a plenty, so we could use an existing service and python.
Another way of looking at it, let's say it's a critical service and you need at least 3 people to support it/be on call. If each engineer costs $200k/year, that's $600k/year. Does this new language save you that much over using a more generic and widly known language in the org?
Re: Ask HN: Who regrets choosing Elixir?
#93Earlier quoted context omitted.
That seems odd given that the BEAM was designed for reliable real-time telephone switching
You're not wrong! I actually tried doing a bunch of research to figure out how the original Ericsson phone switches worked with Erlang, but couldn't find a whole lot of info.
At least we have this "Erlang: The Movie" demo to reverse engineer some bits: https://m.youtube.com/watch?v=BXmOlCy0oBM
Re: Ask HN: Who regrets choosing Elixir?
#94My 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 code - and it misses a lot of things that, e.g., Java or Typescript would have no problems with.
2. Testing is kind of fiddly and annoying. It's very difficult to consistently mock things out. And yes, yes, it's a functional language so in theory every function should be small and trivially testable, but unless you're writing toy code, eventually you will have dependencies you would like to mock out in tests, and you will have complicated business logic living _somewhere_.
Re: Ask HN: Who regrets choosing Elixir?
#95Earlier quoted context omitted.
This may sound like a dismissal, and in a way it is, but: get a better type system, and really understand it. The kinds of logic problems that you describe can be greatly limited—without wasting one’s time —with a more expressive type system. This is one of the reasons I lean so heavily on TypeScript today; I can express my data in the forms it actually should be expressed in, pretty easily, and use that to constrain…
At the end of the day, it’s about can you deliver that project on time and with limited bugs. Everyone’s experience will be different, so maybe accept that different programmers work better with different systems. I can tell you with 20 years of programming experience that static type systems don’t make me more efficient... and I’ve used them all. And just because I can see the reply coming, I’ve worked with programm…
Put frankly: I’m not going to “accept” that because I’ve watched programmers with twenty years of experience (woe betide me and my mere thirteen!) tank projects through this kind of arrogance. And it is arrogance, to dress up the limitations of a meatbag as a positive against the tireless specificity of the machines.
Then those meatbags realize that they have to refactor their code and the world ends.
The computer is infinitely better at crossing the t’s and dotting the i’s than you are. Or I am. Relying on conscientiousness when you have tools to measure and correct is a sucker’s bet. And I will go so far to say that with the wonderful tools available to us in 2020, dynamically typed languages put “on time” and “limited bugs” in an unnecessary tension.
Re: Ask HN: Who regrets choosing Elixir?
#96I'm one of those raving fans you talk about. I always love sharing the success stories of Elixir with everyone because it deserves so much more love than it currently receives. I came from a Rails background too and Elixir is so much better than even Ruby (which I'm a huge fan of already) simply because it forces you to think in terms of functions rather than OOP based. Most people who try and give up early on Elixir…
> And it always results in better code when you do it functionally
Hard disagree here. Functional code is often better, but certainly not always.
Re: Ask HN: Who regrets choosing Elixir?
#97Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks we stopped the experiment and re-did everything in Ruby. What stopped us was not so much the lack of libraries, but programming ergonomics. E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. Also mocking was difficult in tests. Elixir is a great project with a friendly community, i…
>when using keyword lists for function options Proplists should be replaced with maps pretty much everywhere. >Also mocking was difficult in tests Interesting, what exactly was difficult? You just replace one function with another.
> 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.
Re: Ask HN: Who regrets choosing Elixir?
#98Earlier quoted context omitted.
When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think this should be confusing. Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does. > static types in most languages[2] don't reduce this burden much: there isn't an alternative to th…
I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it. Arguing to build what is essentially a build-time type checker in the form of automated tests seems twice as cumbersome for half the benefit. Instead of building tests that check each branch of a program's types, why not use a language that forbids dynamic typing? You s…
> I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it.
"If you drive carefully enough, a car without seatbelts shouldn't be a problem!"
Re: Ask HN: Who regrets choosing Elixir?
#99Earlier quoted context omitted.
I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it. Arguing to build what is essentially a build-time type checker in the form of automated tests seems twice as cumbersome for half the benefit. Instead of building tests that check each branch of a program's types, why not use a language that forbids dynamic typing? You s…
> You should still have tests, but IMO tests that are just checking that a string is a string are The correct completion to this sentence is "irrelevant.", because that's not what anyone is proposing. The fact is, behavioral tests catch a lot of type errors even without intending to, and more to the point, if you test all the behavior you care about, then you don't care if there are type errors, because they only occ…
> if you test all the behavior you care about, then you don't care if there are type errors, because they only occur in situations where you don't care.
If I test all the situations I care about, the one situation I thought I didn't care about is going to fuck me in production.
Re: Ask HN: Who regrets choosing Elixir?
#100I'm one of those raving fans you talk about. I always love sharing the success stories of Elixir with everyone because it deserves so much more love than it currently receives. I came from a Rails background too and Elixir is so much better than even Ruby (which I'm a huge fan of already) simply because it forces you to think in terms of functions rather than OOP based. Most people who try and give up early on Elixir…
> And it always results in better code when you do it functionally Hard disagree here. Functional code is often better, but certainly not always.
That sounds more like a "soft" disagree. :)