Elixir v1.20: Now a gradually typed language

They did get lucky with that. The Python type syntax ended up being similar, but the implementation of type-checking is confusing, also it was annoying how you needed to import the types of basic collections for a while.

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM?

This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue.

Rewriting critical software infrastructure (infostructure) to more reliable typed languages happened to most of the Ruby on Rails (RoR) software unicorn stacks for examples Twitter, Airbnb and Shopify to name a few [1],[2],[3].

The main reason provided for these migration is transitioning away from monolith architecture, but almost all of the new programming languages being used are typed thus make it obvious that the untyped languages are not performant and difficult to scale even by changing the architecture.

[1] Why did Twitter move away from Ruby on Rails?

https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on...

[2] How Airbnb Scaled by Moving Away From a Rails Monolith:

https://www.reddit.com/r/programming/comments/1756q7z/how_ai...

[3] Is Shopify shifting away from Rails?

https://news.ycombinator.com/item?id=33409597

Yes, that is a great talk. He really does an admirable job of exploring all of the reasons why people think that they want a typed language and concludes many (but not all) are not that helpful.

There are two possible locations for comparison that I can see:

https://gleam.run/frequently-asked-questions/#Elixir Here’s a non-exhaustive list of differences:

    Elixir is gradually typed, while Gleam is fully statically typed.
    Elixir's type system does not have generics, while Gleam's type system does.
    Elixir has a powerful macro system, Gleam has no metaprogramming features.
    Elixir’s compiler is written in Erlang and Elixir, Gleam’s is written in Rust.
    Gleam has a more traditional C family style syntax.
    Elixir has a namespace for module functions and another for variables, Gleam has one unified namespace (so there’s no special fun.() syntax).
    Gleam standard library is distributed as Hex packages, which makes interoperability with other BEAM languages easier.
    Elixir is a larger language, featuring numerous language features not present in Gleam.
    Elixir has an official test framework with excellent support for concurrency, partitioning, parameterized tests, integrated error reports, and more. Gleam has no official test framework, but there are multiple community-maintained frameworks.
    Both languages compile to Erlang but Elixir compiles to Erlang abstract format, while Gleam compiles to Erlang source. Gleam can also compile to JavaScript.
    Elixir has superior BEAM runtime integration, featuring accurate stack traces and full support for tools such as code coverage, profiling, and more. Gleam’s support is much weaker due to going via Erlang source, resulting in less accurate line numbers with these tools.
    Elixir and Gleam both use Erlang's OTP framework. Both have additional modules for working with OTP, which provide APIs more in the style of each respective language. Both common use Erlang's OTP APIs directly, but Elixir can do so more conveniently and concisely due to having a less-strict type system.
    Elixir currently has superior deployment tooling, including support for OTP releases and OTP umbrella applications.
    Gleam’s editor tooling is superior due to having a more mature official language server, but Elixir has recently announced an official language server project which is in active development.
    Elixir is more mature than Gleam and has a much larger ecosystem.
    Gleam and Elixir compile at similar speeds due to using the Erlang compiler as their compiler backend. Elixir's macros are evaluated at compile time, so a program that uses macros will take longer to compile the larger the amount of work performed in macros. Gleam has no language features that result in slower compilation.

https://gleam.run/cheatsheets/gleam-for-elixir-users/ This has to much content to reproduce.

I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.