I would recommend Erlang over Elixir. Rubyish syntax and leak of Erlang abstraction is a tough combo.
Ask HN: Who regrets choosing Elixir?
101–110 of 340 posts
Re: Ask HN: Who regrets choosing Elixir?
#102I’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.
Re: Ask HN: Who regrets choosing Elixir?
#103Earlier 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…
> 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!"
Exactly
Re: Ask HN: Who regrets choosing Elixir?
#104I deal with Elixir currently.
Although, actually, I'm converting it all to C#, since we don't really have a lot of elixir people in the shop (I had to learn Elixir just to do the maintenance when I came onboard.)
The lack of APIs can be painful at times. What is there sometimes isn't the most fun to deal with outside of the ecosystem (the driving force of the language conversion was issues using Phoenix Channels reliably with non-elixir consumers, and during the conversion we are dealing with the minor pain of pulling certain data out of an mnesia data store.)
But, I mostly enjoyed my time playing with it.
Biggest observation was that the IDE Tooling didn't feel as nice as, say, F#, which makes a bit of a difference when you're not dealing with the language day-to-day and need helpful reminders for how you're getting certain things wrong.
Re: Ask HN: Who regrets choosing Elixir?
#105I don’t, I’ve being pushing everywhere I go to use it.
The main question is always the same, “how much effort it will take me to find Febe if I need them”.
And my answer is always the same, “make them come and work with you, and focus people excited and open to learn a new technology”.
Re: Ask HN: Who regrets choosing Elixir?
#106I tried implementing an algorithm for tracking multiple objects based on graph-cuts using Elixir. I was disappointed in the lack of strict typing in the language, since this is one of the things that made me want to try functional programming.
In order to tell the type of various method signatures, it seems like you have to go looking at other areas of your program. I’m aware that it’s possible to annotate method signatures, but this still didn’t lead me to feel secure. I think I was hoping for/expecting something more Haskell-like.
Re: Ask HN: Who regrets choosing Elixir?
#107TL;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?
Re: Ask HN: Who regrets choosing Elixir?
#108Earlier quoted context omitted.
> They lack static type checking, but I find that a thorough test suite catches most type errors anyway. Maybe ruby is different than python in this regard, but with python I see a lot of “assert isinstance(arg, dict)” in functions which would not be necessary with type checking. Feeding an unexpected type into a function, and having it carry on as normal, is really scary.
I've seen this too, but I tend to think of it as an antipattern. The fact is, in most cases a Python function won't carry on as normal if you feed it an unexpected type, because while Python's type system isn't static , it is fairly strong . In general I am a fan of strong types and I would like it if Python's type system were a lot stronger. But ultimately this isn't what my post was about: I'm talking about modelin…
What do you mean it's fairly strong? Not challenging you, I'm just trying to get my head around all the type stuff.
Re: Ask HN: Who regrets choosing Elixir?
#109TL;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…
> Who's on call?
Side note: Pagerduty comes with many hilarious sounds, including a very realistic meow. Thus we practice meow driven development: I don't want my phone to meow desperately.
Re: Ask HN: Who regrets choosing Elixir?
#110Earlier 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.
IIRC a good way to put is that the phone switches didn't work with erlang, but the phone switch controllers did.