Earlier quoted context omitted.
Sadly that HN thread is biased toward the person/team that is "leaving" Elixir because it wasn't a good fit for them. For the people who understand Elixir/OTP's strengths it's excellent. We use Elixir for several apps and haven't had any issues recruiting/training people (remote). If we were to chose again we would 100% pick Elixir; nothing else comes close for our use-case.
I went though that persons submissions/comments on HN. its literally the only time they mention Elixir, everything else is ruby/rails or python. Makes me wonder if it's a troll post.
Elixir 1.12
81–90 of 109 posts
Re: Elixir 1.12
#82Several versions ago Jose talked about how Elixir is basically "done", which is so refreshing these days! But since then, the developer experience has improved by leaps and bounds through all these improvements other than the core language. As a professional Elixir developer for the last 4 years, I'm loving it. A few improvements in the last few versions off the top of my head that have been really nice: * Robust, ti…
> Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT support for better performance. I'm really interested to see how the JIT effects our app. I've seen some reports suggesting that a 20% bump in speed isn't unreasonable to expect.
Re: Elixir 1.12
#83Earlier quoted context omitted.
I highly recommend using the hexpm docker images, which you specify with elixir, erlang, and distro versions, e.g. hexpm/elixir1.12-erlang24.0-debian-buster. Since the official Elixir versions aren't pinned to a version of Erlang, we had issues where either Erlang or the distro should change out from under us. But not with the hexpm ones.
Only issue here is that they don't do subpatch versions. We needed Erlang 22.3.4.1 for something, so had to build by hand.
Re: Elixir 1.12
#84Earlier quoted context omitted.
I went though that persons submissions/comments on HN. its literally the only time they mention Elixir, everything else is ruby/rails or python. Makes me wonder if it's a troll post.
What made you do that? Genuinely curious. You immediately suspect trolling when you see people complaining about Elixir?
Thinking back, I remember that the guy had 1-2 good points but the rest was mostly ranting. They are fun to read but rarely are informative.
Re: Elixir 1.12
#85Earlier quoted context omitted.
Sadly that HN thread is biased toward the person/team that is "leaving" Elixir because it wasn't a good fit for them. For the people who understand Elixir/OTP's strengths it's excellent. We use Elixir for several apps and haven't had any issues recruiting/training people (remote). If we were to chose again we would 100% pick Elixir; nothing else comes close for our use-case.
> For the people who understand Elixir/OTP's strengths it's excellent. Is there any place to read about this on a more or less basic level? I bet many people will just ask what benefits they may get from this instead of apps build using Go (for example) + rabbitmq
Many underestimate this but it's a huge benefit for most projects that don't need a complex deployment pipeline.
Re: Elixir 1.12
#86See also, https://news.ycombinator.com/item?id=27192873 (Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?) with great insights about the language. Another popular thread that comes to mind is the one about Discord scaling Elixir ( https://news.ycombinator.com/item?id=14748028 and https://news.ycombinator.com/item?id=19238221 )
Re: Elixir 1.12
#87See also, https://news.ycombinator.com/item?id=27192873 (Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?) with great insights about the language. Another popular thread that comes to mind is the one about Discord scaling Elixir ( https://news.ycombinator.com/item?id=14748028 and https://news.ycombinator.com/item?id=19238221 )
Re: Elixir 1.12
#88Earlier quoted context omitted.
Sadly that HN thread is biased toward the person/team that is "leaving" Elixir because it wasn't a good fit for them. For the people who understand Elixir/OTP's strengths it's excellent. We use Elixir for several apps and haven't had any issues recruiting/training people (remote). If we were to chose again we would 100% pick Elixir; nothing else comes close for our use-case.
> For the people who understand Elixir/OTP's strengths it's excellent. Is there any place to read about this on a more or less basic level? I bet many people will just ask what benefits they may get from this instead of apps build using Go (for example) + rabbitmq
If you're going all in on cloud, microservices, and managed services, then - outside some specific problems - I'm not sure if Elixir is any better of a choice than other language. I personally like immutability+FP but that feels a bit subjective.
But I've worked at small companies for most of my career, and it's my (obviously subjective) opinion that Elixir will let you build a better system if you don't have the luxury of using the "right tool for each task".
Re: Elixir 1.12
#89Earlier quoted context omitted.
Only issue here is that they don't do subpatch versions. We needed Erlang 22.3.4.1 for something, so had to build by hand.
We do build for subpatch versions: https://hub.docker.com/repository/docker/hexpm/erlang/tags?p...
Re: Elixir 1.12
#90Earlier quoted context omitted.
> if a call at the beginning of the pipeline returns a tuple of `{:ok, result}` In my understanding, pipeline are mostly reserved for “unfailable” operations operating on raw data; whereas the where/else/do macro is more oriented towards errors handling; would it work better in your case?
I think you mean `with`, not `where`? Yes, it helps a bit in some cases, but it's not a replacement for a pipeline - mainly because you'd need to name your intermediate results and "thread" them through the calls yourself. I think I gave a bad example, the better one would be a function returning datetime in the format of :erlang.localtime: `{{Year,Month,Day},{Hour,Min,Sec}}`. I would like to be able to use this valu…
Indeed, my bad.
> the better one would be a function returning datetime in the format of :erlang.localtime: `{{Year,Month,Day},{Hour,Min,Sec}}`
I see what you mean. Yeah, I agree with the rest.