Live data from Hacker News

Elixir 1.12

elixir-lang.org

51–60 of 109 posts

Re: Elixir 1.12

#51
post #9

The one thing I’ll say about Elixir I’m always impressed how disciplined they are with the issue tracker on GitHub. Currently 17 issues for such a broad piece of work seems nothing less than astonishing.

I believe it is due to 2 things: excellent vision and work first, but also the nature of the language (not a coincidence) tend to lead to strong "lever effect", 2nd level order benefits, hard focus on composability. I'm, though, curious if other people have more insights about that, because it is truly impressive :-)

My personal feeling is that it's purity, immutability and simplicity of vision. That most of Elixir is also written in Elixir helps.

Erlang/the Beam also helps - there are only 112 open Erlang bugs.

For reference Golang has 6843 open GitHub issues. I am not sure what to make of this.

Re: Elixir 1.12

#52
post #4

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 )

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.

Same here at Papa - we love Elixir and can't imagine using anything else. The dev ux is tremendous.

Re: Elixir 1.12

#53
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…

Wait Elixir didn't have a good approach for env vars until recently? That is like, item one on my list of things I need to be able to handle in a backend web application.

It had them. But if you did a System.get_env inside the config.exs/dev.exs/prod.exs etc it would be at compile time. Various patterns arose to do that at runtime, by using things like `{:system, "FOO", Integer}` as conventions, but it was always a bit ad hoc. If a lib saw that they would know to punt the actual reading to runtime, which is what many folks did before releases.exs, which runs at RUNTIME, so things like System.get_env work as expected.

Re: Elixir 1.12

#54
post #15

Looking into Elixir, but from what i've heard, Elixir isn't very memory efficient when it comes to web servers. Is that still the case? Also where does one host Elixir apps these days? Heroku, Vercel or Bare metal?

Huh? Elixir isn't memory effecient, compared to what exactly :)?

It also really depends what you're doing - if you need millions of processes almost nothing is more memory efficient.

Re: Elixir 1.12

#55
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…

Wait Elixir didn't have a good approach for env vars until recently? That is like, item one on my list of things I need to be able to handle in a backend web application.

[deleted]

Re: Elixir 1.12

#56

Great news. I'll wait for the official docker image to be updated (I deploy on my own server with CapRover). Seems a bit weird though that they do not generate images for the same elixir version with different OTP versions. Currently the latest is elixir v1.12.0-rc.1 and erlang 23.

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

#57
post #4

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 )

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.

The point how all of Erlangs strengths are now obsolete because of XYZ that now exists misses the point how with Erlang/Elixir all of those things are at your fingertips using a single technology stack that is not hard to use and will scale very well for practically anyone.

Re: Elixir 1.12

#58
post #2

There are some nice bits in here. tap() and then() are fairly minor, but very nice quality-of-life additions. The work on numerical, livebook, Mix.install etc are healthy steps to take. Nice work.

I wish they'd instead fix the compiler to not require .then But in absence of that this is a huge QoL improvement. tap though... OMG yes!

I was very, very disappointed that the `tap` macro has nothing to do with pattern_tap: https://github.com/mgwidmann/elixir-pattern_tap

Basically, in Elixir pipelines are not very friendly to simple destructuring: if a call at the beginning of the pipeline returns a tuple of `{:ok, result}`, you can't use either of shortcut syntaxes for lambdas (&Mod.fun/arity and &Mod.fun(&1)), you have to use `fn` and destructure in its head. pattern_tap solves this quite elegantly, but I was told that it's a "non-standard macro that people don't know, so it shouldn't be used"... So when I saw `tap` in Kernel, I though that maybe it's similar at least... unfortunately, it's not similar at all, and now the global identifier `tap` is taken, which made the situation even worse :(

Re: Elixir 1.12

#59
post #9

The one thing I’ll say about Elixir I’m always impressed how disciplined they are with the issue tracker on GitHub. Currently 17 issues for such a broad piece of work seems nothing less than astonishing.

I believe it is due to 2 things: excellent vision and work first, but also the nature of the language (not a coincidence) tend to lead to strong "lever effect", 2nd level order benefits, hard focus on composability. I'm, though, curious if other people have more insights about that, because it is truly impressive :-)

I'd also add it is pretty amazing how responsive and friendly the core team is. They generally are very clear, but polite when they don't accept something and super fast about addressing bugs.

I started following phoenix and a few other important Elixir repos on github several months ago. I'm amazed how many times the community has taken the time to help someone debug why their specific scenario isn't a bug with the library and pointed them to the right solution.

Re: Elixir 1.12

#60

Earlier quoted context omitted.

I believe it is due to 2 things: excellent vision and work first, but also the nature of the language (not a coincidence) tend to lead to strong "lever effect", 2nd level order benefits, hard focus on composability. I'm, though, curious if other people have more insights about that, because it is truly impressive :-)

My personal feeling is that it's purity, immutability and simplicity of vision. That most of Elixir is also written in Elixir helps. Erlang/the Beam also helps - there are only 112 open Erlang bugs. For reference Golang has 6843 open GitHub issues. I am not sure what to make of this.

Rust has the same number of issues open then what? You're comparing a simple language that is built on top of Erlang. It has a few issues because:

- the code base is small

- it has a few users compare to other languages

- it's built on top of something else

I was curious and I looked at the std lib for Elixir it's very minimal.

Post reply on HN