9 ms·

Elixir 1.19

385 points by theanirudh 1y ago

crbelaus 1y ago
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.
asa400 1y ago
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 1y ago
  Anyone downvoting care to comment on why a benchmark of a feature in this release is downvote worthy?
- yuliyp 1y ago
  You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.
  - dns_snek 1y ago
    No their results are correct. It roughly halved the compilation time on a newly generated Phoenix project. I'm assuming the savings would be more extensive on projects with multiple native dependencies that have lengthy compilation. rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile ________________________________________________________ Executed in 37.75 secs fish external usr time 103.65 secs 32.00 micros 103.65 secs sys time 20.14 secs 999.00 micros 20.14 secs rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile ________________________________________________________ Executed in 16.71 secs fish external usr time 2.39 secs 0.05 millis 2.39 secs sys time 0.87 secs 1.01 millis 0.87 secs rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile ________________________________________________________ Executed in 17.19 secs fish external usr time 2.41 secs 1.09 millis 2.40 secs sys time 0.89 secs 0.04 millis 0.89 secs
BAPHOMETA88F 1y ago
Application specific type inference to compile ad hoc reporting using Elixir's Standard Library dynamic() > boolean() integer() > boolean()
deleted 1y ago
[deleted]
ratmeadow 1y ago
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.
- recroad 1y ago
  I quit my job and started a company just so I can use Elixir.
  - pandemic_region 1y ago
    How's that going for you?
    - ludicity 1y ago
      Not the person you're responding to, but I also quit my job and started a company that uses Elixir for internal stuff. It's overkill for some of our problems but it's working fine! We make mistakes, but they're mistakes we'd have made with most other languages. I did have to buy Pragstudio licenses for anyone using Elixir on the team. I'd prefer a few books, but most Elixir/Phoenix books don't seem like they're keeping up with the rate of change.
      - deleted 1y ago
        [deleted]
      - FredPret 1y ago
        Pragmaticstudio is just an awesome starting point for Elixir + Phoenix. I delayed signing up for a long time - wondering if it would be worth the money - but I need not have
    - recroad 1y ago
      Pretty good. The company is jumpcomedy.com and I'm making less money but am much happier. Pair and mob programming have been hugely helpful in sharing learnings and patterns. We only have three developers - all remote. One very nice surprise has been how amazing LLMs are with Elixir, something about a clean functional language maybe, not sure. Getting feedback directly from production has been helpful too to tell us when we didn't think something through. We don't use branches, everything is a commit to main and every push is a production deployment so all three of us are in the loop on what each other is doing. Didn't really buy any books but testing and trying things out in LiveBook has been huge to learn the nuances of the language. The LiveDashboard has been great in monitoring things, especially the PostGres plugin for it. The Discord community has been very supportive as well, and the Elixir Forums as well.
behnamoh 1y ago
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.
- radiospiel 1y ago
  > 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)).
  - thraxil 1y ago
    Erlang/Elixir supervision trees also rely on process linking, which is implemented in BEAM and doesn't have a real equivalent in most other language runtimes (modulo some attempts at copying it like Akka, Proto.Actor, etc, but it's fairly uncommon).
- stanmancan 1y ago
  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.
  - dnautics 1y ago
    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.
Blackarea 1y ago
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
- innocentoldguy 1y ago
  Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.
  - abrookewood 1y ago
    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
    - benzible 1y ago
      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).
      - Blackarea 1y ago
        Profiling tools are something that I miss a bit in gleam - yes, but otherwise I had no problems with OTP bindings. The maturity of the ecosystem is a bit lower of course. But I actually enjoy finding libraries or repos with a few hundred lines. You gotta handroll some things but that's what I am here for. ffi to erlang and js for fullstack apps is as straight forward as it gets, but erlang syntax is indeed a bit crazy. For those interested in gleam but don't want to miss some necessities: https://github.com/gleam-lang/awesome-gleam https://github.com/gleam-lang/awesome-gleam (the gleam community is super nice btw). For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either. I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.
cies 1y ago
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".
- ch4s3 1y ago
  Kotlin is almost the jruby we always wanted.
  - cies 1y ago
    I'd say "more than".
    - ch4s3 1y ago
      I guess it depends on what you wanted.
moomoo11 1y ago
I’m currently using soketi to broadcast events using a pusher sdk on my api services. My app is a mix of real time and rest endpoints, and there’s no heavy computation and even if there was I could just call do that one off in Go or something. Would Phoenix make sense for me? I have some cool collaborative features in the works.
29athrowaway 1y ago
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.
- barrell 1y ago
  I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue). ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, observability, etc of the BEAM is unbeatable. Documentation of elixir, elixir deps, and elixir code is also far and above any language I've ever seen. And the struggles I had supporting minimal concurrency in python were completely alleviated - so even if you don't need massive concurrency, elixir has a good chance of massively simplifying anything that needs minimal concurrency (which is probably most web related projects).
  - deleted 1y ago
    [deleted]
  - 29athrowaway 1y ago
jacquesm 1y ago
That's neat, Elixir is one of the most promising web development environments in my opinion, every time I come across it professionally it is a level above what we normally encounter, as are the teams that are using it. Elixir keeps setting standards for how you should approach this kind of continuous development.
andybak 1y ago
If anyone is interested in helping out on an real-world open source Elixir project - a major component of what used to be Mozilla Hubs and is now an independent project is written in Elixir: https://github.com/Hubs-Foundation/reticulum https://github.com/Hubs-Foundation/reticulum
ValtteriL 1y ago
>Elixir releases now include a Source SBoM in CycloneDX 1.6 or later and SPDX 2.3 or later formats. Having the $lang_ecosystem address this sounds godsent. Unfortunately we don't use Elixir at $work.
losvedir 1y ago
Very cool! As a professional Elixir developer who loves types, I'm so happy to see them coming more and more to the language. I have a question about how the type inference works. Dialyzer, which also attempts to do type inference, uses "success" typing which means it will not flag something if it could work. It tries to minimize false positives. In practice, this means it hardly ever catches anything for me (and even when it does warn about something, it's usually not real anyway!), so I don't find it that useful. Does this approach use "success" typing as well? I found the `String.Chars` protocol example interesting, since I've had my fair share of crashes from bad string interpolations. But in the example, it's _clearly_ wrong, and will fail every time. That's not that useful to me because any time that code is exercised (e.g. in a simple test) it would be caught. What's more useful is if some particular code path results in trying to interpolate something wrong. I know under the hood, the Elixir type system has something to do with unions of possible values, so it is tracking all the things that "could" be passed to a function. Will it warn only if all of them fail, or if any of them fail?
h14h 1y ago
This might be hot take, but I really wish Elixir had more variety in its ecosystem -- particularly in its client-side ergonomics. I absolutely love the language, the way it fits into the Erlang runtime, and especially Jose's stewardship. But Phoenix/LV don't jive with my brain nearly as well as Elixir itself does. Additionally, the push towards native development never evolved to a place where it could realistically supplant Expo & RN for me. This probably sounds insane to anyone who hates how the TS/JS community has a million different frameworks, but I think the upside of all that chaos is that a plethora of new ideas that get explored, and the truly exceptional ideas end up getting adopted anywhere. My gut feeling is that the Elixir world has a TON of amazing ideas that have yet to be explored.

385 points by theanirudh 1y ago

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.

asa400 1y ago

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 1y ago
Anyone downvoting care to comment on why a benchmark of a feature in this release is downvote worthy?
yuliyp 1y ago
You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.
- dns_snek 1y ago
  No their results are correct. It roughly halved the compilation time on a newly generated Phoenix project. I'm assuming the savings would be more extensive on projects with multiple native dependencies that have lengthy compilation. rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile ________________________________________________________ Executed in 37.75 secs fish external usr time 103.65 secs 32.00 micros 103.65 secs sys time 20.14 secs 999.00 micros 20.14 secs rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile ________________________________________________________ Executed in 16.71 secs fish external usr time 2.39 secs 0.05 millis 2.39 secs sys time 0.87 secs 1.01 millis 0.87 secs rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile ________________________________________________________ Executed in 17.19 secs fish external usr time 2.41 secs 1.09 millis 2.40 secs sys time 0.89 secs 0.04 millis 0.89 secs

BAPHOMETA88F 1y ago

Application specific type inference to compile ad hoc reporting using Elixir's Standard Library dynamic() > boolean() integer() > boolean()

deleted 1y ago

[deleted]

ratmeadow 1y ago

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.

recroad 1y ago
I quit my job and started a company just so I can use Elixir.
- pandemic_region 1y ago
  How's that going for you?
  - ludicity 1y ago
    Not the person you're responding to, but I also quit my job and started a company that uses Elixir for internal stuff. It's overkill for some of our problems but it's working fine! We make mistakes, but they're mistakes we'd have made with most other languages. I did have to buy Pragstudio licenses for anyone using Elixir on the team. I'd prefer a few books, but most Elixir/Phoenix books don't seem like they're keeping up with the rate of change.
    - deleted 1y ago
      [deleted]
    - FredPret 1y ago
      Pragmaticstudio is just an awesome starting point for Elixir + Phoenix. I delayed signing up for a long time - wondering if it would be worth the money - but I need not have
  - recroad 1y ago
    Pretty good. The company is jumpcomedy.com and I'm making less money but am much happier. Pair and mob programming have been hugely helpful in sharing learnings and patterns. We only have three developers - all remote. One very nice surprise has been how amazing LLMs are with Elixir, something about a clean functional language maybe, not sure. Getting feedback directly from production has been helpful too to tell us when we didn't think something through. We don't use branches, everything is a commit to main and every push is a production deployment so all three of us are in the loop on what each other is doing. Didn't really buy any books but testing and trying things out in LiveBook has been huge to learn the nuances of the language. The LiveDashboard has been great in monitoring things, especially the PostGres plugin for it. The Discord community has been very supportive as well, and the Elixir Forums as well.

behnamoh 1y ago

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.

radiospiel 1y ago
> 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)).
- thraxil 1y ago
  Erlang/Elixir supervision trees also rely on process linking, which is implemented in BEAM and doesn't have a real equivalent in most other language runtimes (modulo some attempts at copying it like Akka, Proto.Actor, etc, but it's fairly uncommon).
stanmancan 1y ago
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.
- dnautics 1y ago
  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.

Blackarea 1y ago

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

innocentoldguy 1y ago
Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.
- abrookewood 1y ago
  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
  - benzible 1y ago
    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).
    - Blackarea 1y ago
      Profiling tools are something that I miss a bit in gleam - yes, but otherwise I had no problems with OTP bindings. The maturity of the ecosystem is a bit lower of course. But I actually enjoy finding libraries or repos with a few hundred lines. You gotta handroll some things but that's what I am here for. ffi to erlang and js for fullstack apps is as straight forward as it gets, but erlang syntax is indeed a bit crazy. For those interested in gleam but don't want to miss some necessities: https://github.com/gleam-lang/awesome-gleam https://github.com/gleam-lang/awesome-gleam (the gleam community is super nice btw). For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either. I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.

cies 1y ago

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

ch4s3 1y ago
Kotlin is almost the jruby we always wanted.
- cies 1y ago
  I'd say "more than".
  - ch4s3 1y ago
    I guess it depends on what you wanted.

moomoo11 1y ago

I’m currently using soketi to broadcast events using a pusher sdk on my api services. My app is a mix of real time and rest endpoints, and there’s no heavy computation and even if there was I could just call do that one off in Go or something. Would Phoenix make sense for me? I have some cool collaborative features in the works.

29athrowaway 1y ago

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.

barrell 1y ago
I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue). ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, observability, etc of the BEAM is unbeatable. Documentation of elixir, elixir deps, and elixir code is also far and above any language I've ever seen. And the struggles I had supporting minimal concurrency in python were completely alleviated - so even if you don't need massive concurrency, elixir has a good chance of massively simplifying anything that needs minimal concurrency (which is probably most web related projects).
- deleted 1y ago
  [deleted]
- 29athrowaway 1y ago

jacquesm 1y ago

That's neat, Elixir is one of the most promising web development environments in my opinion, every time I come across it professionally it is a level above what we normally encounter, as are the teams that are using it. Elixir keeps setting standards for how you should approach this kind of continuous development.

andybak 1y ago

If anyone is interested in helping out on an real-world open source Elixir project - a major component of what used to be Mozilla Hubs and is now an independent project is written in Elixir: https://github.com/Hubs-Foundation/reticulum https://github.com/Hubs-Foundation/reticulum

ValtteriL 1y ago

>Elixir releases now include a Source SBoM in CycloneDX 1.6 or later and SPDX 2.3 or later formats. Having the $lang_ecosystem address this sounds godsent. Unfortunately we don't use Elixir at $work.

losvedir 1y ago

Very cool! As a professional Elixir developer who loves types, I'm so happy to see them coming more and more to the language. I have a question about how the type inference works. Dialyzer, which also attempts to do type inference, uses "success" typing which means it will not flag something if it could work. It tries to minimize false positives. In practice, this means it hardly ever catches anything for me (and even when it does warn about something, it's usually not real anyway!), so I don't find it that useful. Does this approach use "success" typing as well? I found the `String.Chars` protocol example interesting, since I've had my fair share of crashes from bad string interpolations. But in the example, it's _clearly_ wrong, and will fail every time. That's not that useful to me because any time that code is exercised (e.g. in a simple test) it would be caught. What's more useful is if some particular code path results in trying to interpolate something wrong. I know under the hood, the Elixir type system has something to do with unions of possible values, so it is tracking all the things that "could" be passed to a function. Will it warn only if all of them fail, or if any of them fail?

h14h 1y ago

This might be hot take, but I really wish Elixir had more variety in its ecosystem -- particularly in its client-side ergonomics. I absolutely love the language, the way it fits into the Erlang runtime, and especially Jose's stewardship. But Phoenix/LV don't jive with my brain nearly as well as Elixir itself does. Additionally, the push towards native development never evolved to a place where it could realistically supplant Expo & RN for me. This probably sounds insane to anyone who hates how the TS/JS community has a million different frameworks, but I think the upside of all that chaos is that a plethora of new ideas that get explored, and the truly exceptional ideas end up getting adopted anywhere. My gut feeling is that the Elixir world has a TON of amazing ideas that have yet to be explored.