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

31–40 of 152 posts

Re: Elixir 1.19

#31

Post by abrookewood »

burnt-resistor wrote: post #4
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…

Elixir still seems kind of rough and missing creature comforts, needs stabilization and guides to accomplish goals. There's a lot of broken/under-maintained packages and unhelpful guides that don't work because there's so much Phoenix ecosystem churn. It could get better but all the things™ need curation and approachable documentation. Not everyone wants LiveViews or to use their component system, and the learning cu…

"Python 3 was really, really needed to fix things in 2. Hence 2 became 3. They managed it pretty well".

I don't know how you can say this honestly - it was turbulent and fraught with trouble and angst. It most certainly was NOT handled well.

Re: Elixir 1.19

#32

Post by abrookewood »

innocentoldguy wrote: post #28
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

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam

Re: Elixir 1.19

#33

Post by cies »

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

Re: Elixir 1.19

#34

Post by cies »

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.

Re: Elixir 1.19

#35

Post by zdragnar »

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…

It really depends on how good your inspecting tools are. Using runtime methods and functions instead of macros mean the code is all right there, and what you're debugging is what you see in your editor (setting aside silly things like reflection shenanigans).

With macros, even language servers may need customization if they introduce new syntax. The code that runs doesn't exist until it runs, so you can't see it ahead of time.

This doesn't sound like too big a problem if you're familiar with the tooling already, but trying to figure out where some random method comes from in a rails code base when you're new to Ruby is somewhere between a nightmare and impossible without debugging and using the repl to tell you where the source is.

React has a JSX macro, and I love using it, so there's definitely room for them. There is a world of difference in developer experience when macros are used versus when not, however, and it is wrong to say that it is all the same.

Re: Elixir 1.19

#36

Post by ch4s3 »

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…

“It’s all regular functions” should be on our collective bumper sticker.

Re: Elixir 1.19

#37

Post by benzible »

abrookewood wrote: post #32
innocentoldguy wrote: post #28

Earlier quoted context omitted.

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam

They both ultimately produce BEAM bytecode, but Gleam compiles to Erlang source first (then through the Erlang compiler), while Elixir compiles to Erlang's abstract format. Gleam doesn't prevent OTP use - it has type-safe OTP bindings, but they're less mature/feature-complete than Elixir's, plus Elixir has better BEAM runtime integration (stack traces, profiling tools, etc).

Re: Elixir 1.19

#38

Post by distantprovince »

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…

these are all surprisingly specific questions that can actually be answered!

1. It's dynamic 2. It's compiled 3. Elixir script is just a file with Elixir code that compiles and runs right away 4. I've been writing Elixir for 7 years and barely know any Erlang. I even submitted bugs to OTP team with reproductions in Elixir, they're chill. 5. Preemptive scheduler, immutable data

Re: Elixir 1.19

#39

Post by jen20 »

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.

Although it was somewhat optional, adding async to Rust had a similar feel. Also various Swift versions had source breaking changes back in the day.

Re: Elixir 1.19

#40

Post by jameslars »

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.

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