Oh no same crap of mixing hash symbol and string keys as in ruby? You didnt have to borrow that Elixir! Does Elixir also have HashWithIndifferentAccess?
Honest question, why is this a problem?
Elixir and Phoenix after two years
21–30 of 111 posts
Re: Elixir and Phoenix after two years
#22To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix. As he says, the templates are compiled and are blindingly fast compared to Rails. Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer mult…
> attempt to avoid all conditionals
I think that's a symptom of the lack of a return keyword (and therefore early returns).
Re: Elixir and Phoenix after two years
#23I wrote elixir for a couple years in a high scale environment, and I agree with OP on most of what he described. My favorite aspects, ranked:
1) immutable data / actor model paradigm
2) mix (super modern build tool that does it all)
3) pattern matching
Re: Elixir and Phoenix after two years
#24Re: Elixir and Phoenix after two years
#25To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix. As he says, the templates are compiled and are blindingly fast compared to Rails. Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer mult…
> and perhaps there could be a more concise enhancement of Erlang which would get the job done
Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters. I would love if Erlang would drop some of its punctuation, as some of it is frankly unnecessary.
Elixir syntax is definitely simpler than Ruby’s. Probably in the same ballpark as Python complexity wise: Elixir has less keywords and less rules thanks to the macro system but on the other hand more affordances, such as optional parenthesis.
Re: Elixir and Phoenix after two years
#26Oh no same crap of mixing hash symbol and string keys as in ruby? You didnt have to borrow that Elixir! Does Elixir also have HashWithIndifferentAccess?
Elixir does not have HashWithIndifferentAccess
Re: Elixir and Phoenix after two years
#27Oh no same crap of mixing hash symbol and string keys as in ruby? You didnt have to borrow that Elixir! Does Elixir also have HashWithIndifferentAccess?
Typically string key maps should exist only at the edges of your system, but they are still often necessary when you're interacting with the outside world. Params in Phoenix come in as a string key map because the atom table does not get garbage collected, so where you don't know what keys may be passed in, string keys are necessary to avoid the risk of running OOM. That said, once I know the shape of the data I'm dealing with, I pretty much always convert to an atom key map as quickly as possible. If I see a string key outside of the context of a controller or worker, I am immediately suspicious.
Re: Elixir and Phoenix after two years
#28I have a dream that one day most of our software will be built with something like elixir and most of the saas products we're using now (octa, zapier, newrelic...) will be just installable modules with a simple api
Re: Elixir and Phoenix after two years
#29Earlier quoted context omitted.
>Lastly, single thread performance is basically a dog. Is that still the case? I thought BeamVM recently added JIT? I don't expect it to be LuaJIT or JS V8, but Ruby and Python Single Thread performance should be reasonable expectation? I also wish some of these experience has more context in terms of code base size and team size. A Production environment of a small project with a team of 2 is very different to produ…
In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.
The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.
Re: Elixir and Phoenix after two years
#30To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix. As he says, the templates are compiled and are blindingly fast compared to Rails. Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer mult…
>Lastly, single thread performance is basically a dog. Is that still the case? I thought BeamVM recently added JIT? I don't expect it to be LuaJIT or JS V8, but Ruby and Python Single Thread performance should be reasonable expectation? I also wish some of these experience has more context in terms of code base size and team size. A Production environment of a small project with a team of 2 is very different to produ…
I've seen several reports of pretty good performance improvements from the new JIT, but keep in mind a couple things:
It's included in the not yet finalized release that is currently only a release candidate. It's a little early to expect people to have experience with it. Some organizations might update quickly, but others will take quite some time. Also, the JIT isn't on all supported platforms; i think it's amd64 and aarch64 only at the moment, which probably covers most performance oriented servers, but maybe not everyone.
The other thing is it's not an optimizing JIT like Hotspot or v8; it 'only' turns the beam opcodes into native code as it's loaded. This eliminates interpretation overhead, but there's potential to optimize the native code in the future.