Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir 1.19

elixir-lang.org

Post reply on HN
Print view View original

51–60 of 152 posts

Re: Elixir 1.19

#51

Post by dnautics »

josevalim wrote: post #12
bmitc wrote: post #6

Earlier quoted context omitted.

The Phoenix churn is definitely real. It's so much so that I've never gotten into it. It's also extremely macro heavy, and so it's its own DSL or collection of DSLs. A concrete example of the churn is that the LiveView book has been "about to release" for five years now. Although, what parts of Elixir itself are rough or missing creature comforts? I generally feel it's stable and fine, but I admittedly haven't writte…

LiveView was still before v1.0, hence the churn, but Phoenix itself did not introduce breaking changes since v1.0, released more than a decade ago. Our skeleton for new applications change, as best practices around web apps are still evolving, but it is completely up to you to migrate. As a reference point, most other web frameworks have gone through several major versions in the same time, changing how new apps are…

> The idea that Phoenix is also mostly macros does not hold in practice

no, but the Framework does push you into using them. A good example is the `use MyAppWeb` pattern. That's a macro that nests other macros. the good news is that you can pretty much excise that and everything works fine, and LLMs have no problem even! (i think they slightly prefer it)

a few cognitive pain points with phoenix macros:

plug: (love it dearly) but a bit confusing that it creates a conn variable out of whole cloth. a minor complaint. worth it, otherwise.

phoenix.router: is a plug but isnt quite a plug.

anyways that's it! the rest is ~fabulous. i think to find a framework where you have two minor complaints is a blessing. remember how activerecord automagically pluralized tables for you?

Re: Elixir 1.19

#52

Post by dnautics »

stanmancan wrote: post #25
behnamoh wrote: post #16

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…

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.

Re: Elixir 1.19

#53

Post by 29athrowaway »

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 spaghetti mess.

The toolchain has much room for improvement. Editing, debugging, profiling, unit testing, or pretty much any basic routine development task, involves a tool that's decades behind the state of the art. Even Borland tools from the 80s have a better toolchain.

Building a team around Elixir is hard. You have to train people on the job and they will probably not write idiomatic code that takes advantage of the language. Or deal with people that won't stop selling you how great the language is.

And the documentation for most of the projects you will use is full of noise, with few workable examples, grandiose claims of performance and fantastic treasures, and the articles are a great read if you want to waste your entire evening.

Support for massive concurrency is nice but you are realistically not going to need it. If you do need it then yes, Elixir can be a good tool for the job.

Re: Elixir 1.19

#54

Post by innocentoldguy »

15155 wrote: post #42
innocentoldguy wrote: post #29

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.

Python allows for memory sharing between threads - which is why a GIL is necessary. A high-level language with a strict shared-nothing concurrency model doesn't need a GIL... but you naturally can't practically share very large objects between BEAM processes.

Hi, 15155. May I clarify a couple of things?

1. Regarding Python's GIL: The issue isn't memory sharing between threads. Java and Go allow you to do this, too, but they don't have GILs. The reason Python has a GIL is that it uses reference counting for memory management. If it didn't have a GIL, multiple threads could simultaneously manipulate reference counts, which would lead to memory corruption/leaks.

2. You can share massive "objects" between BEAM processes. For example, if you're running BEAM in a 64-bit environment, you can share maps, structs, and other data structures that are up to 2,305,843,009,213,693,951 bytes in size.

I hope this information helps. I also hope it is correct. I think it is, but I've been wrong before.

Re: Elixir 1.19

#55

Post by Blackarea »

cies wrote: post #34
Blackarea wrote: post #18

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.

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?

Re: Elixir 1.19

#56

Post by thibaut_barrere »

bryanlarsen wrote: post #21
crbelaus wrote: post #2

The progressive introduction of automated type checking in Elixir should serve as a reference on how to improve a programming language gracefully without breaking changes. So many examples of programming languages have huge breaking changes between versions that end up creating a split in the ecosystem that takes years to resolve. Thankfully José has been very clear about Elixir being done since at least 2018. The la…

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

Ruby 1.8 to 1.9 has been fairly hard, despite being a minor version change. Strings became Unicode, this broke tons of stuff. Also hash ordering.

This caused quite a lot of work on the apps I worked on.

Re: Elixir 1.19

#57

Post by pjmlp »

bryanlarsen wrote: post #21
crbelaus wrote: post #2

The progressive introduction of automated type checking in Elixir should serve as a reference on how to improve a programming language gracefully without breaking changes. So many examples of programming languages have huge breaking changes between versions that end up creating a split in the ecosystem that takes years to resolve. Thankfully José has been very clear about Elixir being done since at least 2018. The la…

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

.NET Framework => .NET

While C#, F#, VB and C++/CLI were kept compatible, it doesn't help when the library stuff you want to call isnt' there any longer.

C++ removal of exception specifiers, GC API,

C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard.

Java, already someone else mentioned.

D, the whole D1 => D2 transition, and Tango vs Phobos drama.

Re: Elixir 1.19

#58

Post by cess11 »

ffsm8 wrote: post #41
jameslars wrote: post #40

Earlier quoted context omitted.

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

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

Deprecations, which also affects libraries, i.e. the dusty one you were chugging along on top of might need to be replaced or adopted because the original maintainer gave up years ago.

Re: Elixir 1.19

#59

Post by pjmlp »

ffsm8 wrote: post #41
jameslars wrote: post #40

Earlier quoted context omitted.

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

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

Re: Elixir 1.19

#60

Post by cess11 »

giraffe_lady wrote: post #11
bmitc wrote: post #9

Earlier quoted context omitted.

That's true for languages that have macros. I just don't like macros, as they get over-abused in every language that has them. I'd much rather deal with just boilerplate and tedious syntax but still straightforward and completely in the language over macros, for the most part. Some macros are indeed useful, like in Rust with `println`, but they still get thrown everywhere.

Frameworks in langauges that don't use macros have this problem too that's what I was getting at with the DSL vs API thing. I don't want to litigate the worthiness of macros for a given purpose here. But if you don't use them for this you have to use something for this the problem doesn't go away. Wherever rails or phoenix has macro-defined syntax to handle a specific task, laravel or whatever will have a collection…

The counterpart in Laravel or Spring Boot or whatever would be annotations. As I understand it, that's how they're doing things on the .NET side too.

It's kind of the standard way to paper over the protocol grit of HTTP and make people able to quickly pump out fresh plumbing between outbound socket and database.

Post reply on HN