Live data from Hacker News

Elixir 1.12

elixir-lang.org

81–90 of 109 posts

Re: Elixir 1.12

#81
post #4

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.

What made you do that? Genuinely curious. You immediately suspect trolling when you see people complaining about Elixir?

Re: Elixir 1.12

#82
post #74
post #8

Several 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.

Haven't had a chance to observe a lot of runtime stats yet but I can tell you that my compile times in big projects fell down dramatically with Erlang/OTP 24.0, at times with 35%.

Re: Elixir 1.12

#83

Earlier 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.

We do build for subpatch versions: https://hub.docker.com/repository/docker/hexpm/erlang/tags?p...

Re: Elixir 1.12

#84

Earlier 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?

Of course not. But reading how somebody who is strongly convinced that their current tech choice is good is trashing another tech that didn't immediately solve all their problems isn't a compelling or objective criticism either, wouldn't you say?

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

#85
post #25
post #4

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.

> 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

One big selling point is having almost everything you need right there with you in the same runtime environment (the Erlang's BEAM VM).

Many underestimate this but it's a huge benefit for most projects that don't need a complex deployment pipeline.

Re: Elixir 1.12

#86

See 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 )

[deleted]

Re: Elixir 1.12

#87

See 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 )

[deleted]

Re: Elixir 1.12

#88
post #25
post #4

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.

> 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 trying to limit your exposure to different technologies, then I think Elixir is a great choice.

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

#89
post #83

Earlier 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...

Ooooh that didn't used to be true, from what I saw! Happy that changed. I can clean up a bunch of images on my side.

Re: Elixir 1.12

#90
post #65

Earlier 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…

> I think you mean `with`, not `where`?

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.

Post reply on HN