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

11–20 of 152 posts

Re: Elixir 1.19

#11

Post by giraffe_lady »

bmitc wrote: post #9
giraffe_lady wrote: post #8

Earlier quoted context omitted.

> It's also extremely macro heavy, and so it's its own DSL or collection of DSLs. I mean this describes every full stack web framework right? Like sure if the underlying language doesn't have macros or macro-like tools that limits how perverted the syntax can get but the line between "DSL" and "API" gets really blurry in all of these massive frameworks.

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 of related functions that need to be used in very specific ways to accomplish the same thing. Whether this collection is a "class" with an "api" or whether it is a "language" defined around this "domain" you will have the abstraction and the complexity.

Having a preference for one approach of managing this abstraction & complexity seems fine but "a collection of DSLs" is pretty much what a web framework is so that can't be the problem here.

Re: Elixir 1.19

#12

Post by josevalim »

bmitc wrote: post #6
burnt-resistor wrote: post #4

Earlier quoted context omitted.

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…

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 built but also breaking old ones.

The idea that Phoenix is also mostly macros does not hold in practice. Last time this came up, I believe less than 5% of Phoenix' public API turned out to be macros. You get this impression because the initial skeleton it generates has the endpoint and the router, which are macro heavy, but once you start writing the actual application logic, your context, your controllers, and templates are all regular functions.

Re: Elixir 1.19

#15

Post by mcdeltat »

Elixir just keeps chugging along steadily releasing great features and improvements. It's an astoundingly well designed language and the creators have a solid approach to its development. It's a shame I don't get to use Elixir day to day.

Re: Elixir 1.19

#16

Post by behnamoh »

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 Python libraries that also implement the actor model, making Python code concurrent the "right way"? I just don't know which niche applications Elixir targets and excels at.

Re: Elixir 1.19

#17

Post by asa400 »

asa400 wrote: post #10

Just a data point on the deps compilation, on a small Phoenix app with mostly stock Phoenix deps: MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile 32.30s user 7.23s system 320% cpu 12.336 total MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile 0.37s user 0.49s system 12% cpu 6.970 total MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile 0.38s user 0.50s system 12% cpu 7.236 total Machine is a Mac M1 M…

Anyone downvoting care to comment on why a benchmark of a feature in this release is downvote worthy?

Re: Elixir 1.19

#18

Post by Blackarea »

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

Re: Elixir 1.19

#19

Post by radiospiel »

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…

> If it solves concurrency the "right way" due to supervision trees, why not use Python libraries that also implement the actor model, making Python code concurrent the "right way"?

I can't speak too much about Python – but immutable vars is a core prerequisite for many of the features OTP (the platform underpinning Elixir (and Erlang)).

Re: Elixir 1.19

#20

Post by dmix »

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…

Our transition to Ruby 3 was very smooth. The actual PR was pretty tiny considering how big our project was. Nothing like the crap I dealt with in JS framework upgrades for much smaller projects. Even Rails is pretty easy to upgrade these days, both are very mature.
Post reply on HN