Live data from Hacker News

Elixir 1.19

elixir-lang.org

121–130 of 152 posts

Re: Elixir 1.19

#121
post #73
post #68

Earlier quoted context omitted.

I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?

Don't know about Scala alternative, but the language I've found most enjoyable on the JVM is definitely Kotlin.

I wonder sometimes how much Kotlin contributed.

It’s certainly a case that languages need to be championed by competent IDE writers otherwise they fail to scale. Because you can’t have 50 devs all using neovim - and only neovim - without making a huge gigantic mess. Large projects can sustain a few brilliant people working with one hand tied behind their back but not everyone.

Re: Elixir 1.19

#122

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

Java 4 to 5 was very rough. Sun kept trying to defer major changes, sort of how Elixir claims it is mostly done. But something changed in 5 and the floodgates opened. They made too many changes at once, and so out in the field you would bump into projects stuck on Java 4 even as 6 was in beta. And then 7, and a few past that.

Re: Elixir 1.19

#123
post #59
post #41

Earlier quoted context omitted.

Uh, wasn't the only breaking change a rename/changed path in some standard lib path?

Introduction of modules, closing down of APIs that no one should be using, since Java 9 deprecated methods actually get removed a few versions later. Also breaking changes do happen, see list of removed methods https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...

The fact that Sun never removed any deprecated methods even after they were proven dangerous was a sticking point that generated friction between coworkers over new code using deprecated functionality.

Re: Elixir 1.19

#124

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

NodeJS with its commonjs vs modules, it's a huge mess IMO. Add typescript and build systems for bonus clusterf*cks.

I’m trying to port a reasonable popular node module to ESM and it’s not going well. I’m finding bugs in createRequire() and meanwhile functional differences between require and import might make some idiomatic code patterns not function at all.

Re: Elixir 1.19

#125

Elixir is still confusing, not the language, but the ecosystem, tooling, and philosophy. Is it dynamic or static? Is it compiled or not? If it's not, then why do we have Elixir scripts, which have different file extension? If it uses BEAM and you'd inevitably need to know Erlang when you hit the edge cases, then why not just learn Erlang? If it solves concurrency the "right way" due to supervision trees, why not use…

Upvoting you because we should have clear answers for these concerns. To those in the community downvoting: we should take these kinds of posts as opportunities to improve.

Elixir and Erlang are dynamic compiled languages.

The actor model being built in to the runtime offers many benefits, all of which I cannot enumerate here, but prominent among them are the ability for the VM to preemptively schedule actors, and the fact that actors are independent in memory and cannot mess with the internal state of other actors.

The jump from Elixir to Erlang or vice versa is small.

The hardest (and most rewarding) part is learning OTP and the whole BEAM runtime system, which you can do with either language.

Erlang and Elixir are slightly different syntaxes for the same semantics, and if you know one you can learn to read and probably write the other in less than a day.

It isn’t like Clojure and Java where Clojure is significantly higher level than Java in many ways. Elixir adds a few things to Erlang but is otherwise the same programming model.

> I just don't know which niche applications Elixir targets and excels at.

Pretty much any application where concurrent IO and state management are the main problems. Web applications, proxies/brokers, long running network stuff, semi-embedded low power devices that are hard to physically access and must remain reliable for years at a time, that kind of thing.

I actually agree with you that the ecosystem and tooling and especially the value proposition are confusing, and the sales pitch over the years has often been poor.

The whole BEAM community would do well to speak more plainly about the concrete benefits for programmers and companies, and the existing successful applications rather than the theoretical beauty of the syntax or the actor model.

I hope this helps.

Re: Elixir 1.19

#126
post #68

Earlier quoted context omitted.

Scala 3 has failed to be widely adopted, and now the language as a whole is more or less dead. Not that that’s due to the 2-to-3 transition entirely.

I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?

Ruby, Clojure, Kotlin n dare to say Groovy

Re: Elixir 1.19

#127
post #65

Elixir was not a happy experience. The language itself is maybe OK but the overall experience is not. On a production build, stack traces look like Erlang code, which is the weird syntax that Elixir tried to improve upon. Then you have macros, which make code unmaintainable at the 10k SLOC mark, and increasingly harder to maintain as projects get larger. Running "mix xref graph" on most Elixir projects shows a spaghe…

I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue). ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, ob…

[deleted]

Re: Elixir 1.19

#128
post #65

Elixir was not a happy experience. The language itself is maybe OK but the overall experience is not. On a production build, stack traces look like Erlang code, which is the weird syntax that Elixir tried to improve upon. Then you have macros, which make code unmaintainable at the 10k SLOC mark, and increasingly harder to maintain as projects get larger. Running "mix xref graph" on most Elixir projects shows a spaghe…

I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue). ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, ob…

When you say "above any language I've ever seen", can you be more explicit? Do you have an example?

I have a lot of respect for the community behind it but the experience is still not there.

Re: Elixir 1.19

#129
post #34

Earlier quoted context omitted.

Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.

What? Gleam can compile to js. I don't see the similarity to kotlin being oo and all. Gleams compile time is lightyears ahead of anything on the jvm. I appreciate kotlins nullability constraints but to me it seems the jvm ecosystem is too grown to give kotlin the space it needs. Also heared that java's pattern matching and exhaustive checks have surpassed kotlins? In that case it's just easier to role with java, no?

Dunno. Wrote a lot of both. Happy with Kotlin. Grateful Java is being maintained well...

My last team wanted to port all remaining Java code to Kotlin, because they just enjoyed working with it so much more.

While porting I've regularly replaced 5-8 lines of Java with a single line of Kotlin.

Kotlin needs Java like Ruby needs C or Elixir needs Erlang.

Re: Elixir 1.19

#130
post #44
post #33

I don't program in Elixir, but I'm a fan. I was a fan of Ruby -- because of it's pragmatism and subjective beauty -- but then I got into type systems. Elixir now also has a type system and, so does Ruby... Though I know program in Kotlin, which syntax-wise is very much a "typed Ruby".

Kotlin is almost the jruby we always wanted.

I'd say "more than".
Post reply on HN