[HN Gopher] Elixir 1.19
___________________________________________________________________
Elixir 1.19
Author : theanirudh
Score : 142 points
Date : 2025-10-16 07:31 UTC (15 hours ago)
(HTM) web link (elixir-lang.org)
(TXT) w3m dump (elixir-lang.org)
| crbelaus wrote:
| 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 Jose has been very clear about Elixir being _done_
| since at least 2018. The language is stable and the language
| /core foundation is not changing anymore.
|
| https://www.youtube.com/watch?v=suOzNeMJXl0
|
| Truly outsanding work and stewardship.
| TomBers wrote:
| Completely agree. I feel no pressure to constantly upgrade my
| Elixir versions. I just look at the changes and there is often
| useful features that make me want to upgrade, as opposed the
| feeling of dread when I am pushed to upgrade.
| burnt-resistor wrote:
| 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(tm) need curation
| and approachable documentation. Not everyone wants LiveViews or
| to use their component system, and the learning curve for
| compatibility with other tools and technologies is still way
| too steep.
|
| Python 3 was really, really needed to fix things in 2. Hence 2
| became 3. They managed it pretty well, vaguely similar to Go,
| with automated update tools and compatibility-ish layers. It
| had its speed bumps and breakages as not everything went
| smoothly.
|
| OTOH: Ruby 3 went the wrong way with types separate files and
| fragmentation of tools. And that's not mention having to opt-in
| with boilerplate to change how String literals work. Or: gem
| signing exists but is optional, not centrally-managed, and
| little-used. Or: Ruby Central people effectively stole some
| gems because Shopify said so. PS: many years ago Hiroshi
| Shibata blocked me from all GH Ruby contributions for asking a
| clarifying question in an issue for no reason. It seemed agro,
| unwarranted, and abrupt. So the rubygems repository fragment
| drama seems like the natural conclusion of unchecked power
| abuse lacking decorum and fairness, so I don't bother with Ruby
| much these days because Rust, TS, and more exist. When any
| individual or group believe they're better than everyone else,
| conflict is almost certainly inevitable. No matter how "good" a
| platform is, bad governance with unchecked conduct will torpedo
| it. PSA: Seek curious, cooperative, and professional folks with
| mature conflict-resolution skills.
|
| It's a good idea(tm) to think deeply and carefully and
| experiment with language tool design in the real world before
| inflicting permanent, terrible choices rather than net better
| but temporarily-painful ones. PSA: Please be honest,
| thoughtful, clear, and communicate changes in advance so they
| can be avoided or minimized to inflict least net pain for all
| users for all time.
|
| Honestly, I hope more development goes into making
| Phoenix/Elixir/OTP easier, more complete, more expressive, more
| productive, more testable, and more performant to the point
| that it's a safe and usable choice for students, hobbyists,
| startups, megacorps, and anyone else doing web, non-web, big
| data, and/or AI stuff.
|
| Plug for https://livebook.dev, an app that brings Elixir
| workbooks to a desktop near you. And
| https://exercism.org/tracks/elixir
| _susanoo wrote:
| > PSA: Please be honest, thoughtful, clear, and communicate
| changes in advance so they can be avoided or minimized to
| inflict least net pain for all users for all time.
|
| > Honestly, I hope more development goes into making
| Phoenix/Elixir/OTP easier, more complete, more expressive,
| more productive, more testable, and more performant to the
| point that it's a safe and usable choice for students,
| hobbyists, startups, megacorps, and anyone else doing web,
| non-web, big data, and/or AI stuff.
|
| Seriously, this has been the case all the time. It's a great
| fit for AI, web (Phoenix), non-web (Nerves), students
| (Pragstudio), hobbyists (hi), megacorps (Discord,
| bleachereport).
|
| What do you mean it's not testable, productive, expressive
| enough? Do you mean the entire elixir community is just
| fiddling about with unsafe software?
|
| This comment seems just like a giant ragebait.
| bmitc wrote:
| 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 written Elixir code in a couple of
| years, sadly.
| giraffe_lady wrote:
| > 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.
| bmitc wrote:
| 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.
| giraffe_lady wrote:
| 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.
| josevalim wrote:
| 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.
| atonse wrote:
| Yea each time I've upgraded (been using elixir in production
| since 2017), it's gone way smoother than I had anticipated.
|
| I usually find the Erlang/OTP upgrades to be a bit more
| problematic compatibility-wise.
|
| So I'm often in the latest elixir but one Erlang/OTP version
| behind cuz I wait a few months for all the kinks to be worked
| out.
| asa400 wrote:
| 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 Max, `rm -rf _build` in between each run.
| asa400 wrote:
| Anyone downvoting care to comment on why a benchmark of a
| feature in this release is downvote worthy?
| BAPHOMETA88F wrote:
| Application specific type inference to compile ad hoc reporting
| using Elixir's Standard Library
|
| dynamic() > boolean()
|
| integer() > boolean()
| clumsysmurf wrote:
| I was interested in checking out Elixir vs Gleam to for a
| backend. I typically use Kotlin, and generally like its type
| system, but wanted to try something different. Since I prefer
| statically typed languages, I was leaning towards Gleam, but now
| I am not so sure.
|
| I found this previous discussion on HN:
| https://news.ycombinator.com/item?id=43310117
|
| The top comments seem to imply they are just very different
| languages with different idioms. Is this still valid?
| mcdeltat wrote:
| 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.
| behnamoh wrote:
| 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.
| Blackarea wrote:
| 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
___________________________________________________________________
(page generated 2025-10-16 23:00 UTC)