10 ms·

The progressive introduction of automated type checking in Elixir should serve as a reference on how to improve a programming language gracefully without breaki

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 language is stable and the language/core foundation is not changing anymore. https://www.youtube.com/watch?v=suOzNeMJXl0 https://www.youtube.com/watch?v=suOzNeMJXl0 Truly outsanding work and stewardship.

TomBers 1y ago
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 1y ago
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 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™ 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 https://livebook.dev, an app that brings Elixir workbooks to a desktop near you. And https://exercism.org/tracks/elixir https://exercism.org/tracks/elixir
- _susanoo 1y ago
  > 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 1y ago
  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 1y ago
    > 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 1y ago
      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.
atonse 1y ago
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.
- flux293m 1y ago
  That's definitely the right way to do it, I've had exactly the same experience.
bryanlarsen 1y ago
> 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.
- dgfitz 1y ago
  C++11 fucking with strings also comes to mind.
  - pjmlp 1y ago
    That was more a GCC problem, but yeah.
  - Blackthorn 1y ago
    C++20 too but luckily basically every compiler has added a switch to turn that insanity off, saving the language.
- laszlokorte 1y ago
  php
- chillfox 1y ago
  Ruby 1.8.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.
  - tyre 1y ago
    triggered. There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.
    - andruby 1y ago
      Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.
zaphirplane 1y ago
Dart is doing slow nullable changes slowly , opt in. Last time I took a peek
- mraleph 1y ago
  We are done with NNBD transition for a few years now. Dart 2.12 (released March 2021) introduced null-safety. That started a 2 year transitionary period during which you could mix nullsafe (language versions 2.12 or above) and non-nullsafe (language versions below 2.12) code in one program. Dart 3.0 (released May 2023) removed support for language versions prior to 2.12 - meaning that you can no longer opt out of null-safety.

TomBers 1y ago

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 1y ago

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 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™ 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 https://livebook.dev, an app that brings Elixir workbooks to a desktop near you. And https://exercism.org/tracks/elixir https://exercism.org/tracks/elixir

_susanoo 1y ago
> 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 1y ago
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 1y ago
  > 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 1y ago
    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.

atonse 1y ago

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.

flux293m 1y ago
That's definitely the right way to do it, I've had exactly the same experience.

bryanlarsen 1y ago

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

dgfitz 1y ago
C++11 fucking with strings also comes to mind.
- pjmlp 1y ago
  That was more a GCC problem, but yeah.
- Blackthorn 1y ago
  C++20 too but luckily basically every compiler has added a switch to turn that insanity off, saving the language.
laszlokorte 1y ago
php
chillfox 1y ago
Ruby 1.8.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.
- tyre 1y ago
  triggered. There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.
  - andruby 1y ago
    Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.

zaphirplane 1y ago

Dart is doing slow nullable changes slowly , opt in. Last time I took a peek

mraleph 1y ago
We are done with NNBD transition for a few years now. Dart 2.12 (released March 2021) introduced null-safety. That started a 2 year transitionary period during which you could mix nullsafe (language versions 2.12 or above) and non-nullsafe (language versions below 2.12) code in one program. Dart 3.0 (released May 2023) removed support for language versions prior to 2.12 - meaning that you can no longer opt out of null-safety.