Live data from Hacker News

Elixir 1.19

elixir-lang.org

91–100 of 152 posts

Re: Elixir 1.19

#91

Earlier quoted context omitted.

I don’t understand why people drink orange soda. If you want something orange flavoured, eat an orange! If you want something bubbly, drink soda water! .ex compiles to beam files to be run later .exs compiles to memory You don’t need to know Erlang to use Elixir; I’m a few years in now and I’ve never had to write any Erlang.

in the past i would have said learning to read erlang is a very nice to have for an intermediate elixirist but not really anymore, an LLM can translate between the two very easily.

That's true. Even so I would still recommend that you learn to read Erlang because of its unique approach to various software development challenges. It will simply make you a better programmer. The same goes for LISP and possibly Forth because they have some very powerful concepts unique to those languages which you can mimic to some degree in other environments to get some of the benefits.

Re: Elixir 1.19

#92

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…

The difference in reliability between a BEAM based setup and one built on top of Python is so large I wouldn't know where to start to describe it. Erlang is built from the ground up to be reliable, Python has reliability bolted on as an afterthought and even the most advanced python environments (Anaconda, CPython) still suffer from some of the assumptions baked into the language.

Re: Elixir 1.19

#94
>Elixir releases now include a Source SBoM in CycloneDX 1.6 or later and SPDX 2.3 or later formats.

Having the $lang_ecosystem address this sounds godsent. Unfortunately we don't use Elixir at $work.

Re: Elixir 1.19

#95
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?

the OO/FP fusion hypothesis resulted in a complicated language on the OO side (too complicated for enterprise application layer) and on the FP side an autistic culture war at the seam between FP frameworks. Functional Scala remains world class at high reliability services such as video streaming at Disney+ and Comcast, and Amazon search but not so much the Java everyman use case that I recall it being marketed for 15 years ago. And now the Scala leadership and the industry frameworks are pulling in different directions, Scala is academically funded.

Re: Elixir 1.19

#96
post #23

Earlier quoted context omitted.

I quit my job and started a company just so I can use Elixir.

How's that going for you?

Not the person you're responding to, but I also quit my job and started a company that uses Elixir for internal stuff.

It's overkill for some of our problems but it's working fine! We make mistakes, but they're mistakes we'd have made with most other languages.

I did have to buy Pragstudio licenses for anyone using Elixir on the team. I'd prefer a few books, but most Elixir/Phoenix books don't seem like they're keeping up with the rate of change.

Re: Elixir 1.19

#97
post #34

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored it a while back. I'd like to give it another chance some time, but I'm worried that it's like typescript - looks typed on the outside but for many libs and packages the types are just a dynamic/any. Is my fear justified? Beam is amazing btw

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

Elixir can also compile to JS via Hologram!

Granted, it's alpha software and it's currently embedded in the Hologram framework, but still.

https://hologram.page/

Re: Elixir 1.19

#98
post #80

Earlier quoted context omitted.

Python has a GIL and is mutable, which makes concurrency impossible and error-prone, respectively. Elixir doesn't have a GIL and is immutable.

Not really. CPython used to have a GIL, it is no longer the case since the latest version, 3.14. Other Pythons, jPython, GrallPy, PyPy, never had a GIL. Languages and implementations aren't the same.

It still has a GIL unless you're using the free-threaded build, which most people do not.

Re: Elixir 1.19

#99

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…

Even though I do not write Elixir on the job, I often cite their docs as a gold standard. They're succinct, easy to read, and most often show an example of how a method is used. What's better is that the language has documentation as a first-class citizen (it's even testable!) meaning your auto-generated docs will look as nice as the language's.

I complain about OCaml docs all the time. But Elixir? no way.

Re: Elixir 1.19

#100
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...

On top of that, there was the removal of built-in J2EE; you needed to add external copies of the J2EE pieces, and some of them (like CORBA) weren't available as separate packages. And later versions of these external J2EE packages changed the namespace of all their classes, which is especially painful in Java due to its common use of dynamic loading of classes by name and lazy linking (and lazy linking errors do not inherit from Exception, which allows them to escape from catch-all "catch (Exception e)" clauses). The rest of the ecosystem is starting to depend on these new versions, so staying with old versions of these J2EE packages is not an option.
Post reply on HN