If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

You might find Gleam[0] a better fit.

[0] https://gleam.run/

If you're only willing to use languages with the same features, what's the point? Learning how a different paradigm manages without types can be more insightful.

Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)

I'm curious what it is going to find in my 10 year old Elixir codebase (still in active production use).

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

Author here.

Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests) and you are still on your own when it comes to actually recovering from unexpected errors (something Erlang/Elixir were designed for).

I'd say there are two flip sides to your question:

1. Given types do not replace tests, if you can use AI to automate full test coverage, are there actual benefits in static typing for coding agents? The downside of tests for humans is that we suck at writing them (but guided agents can do better) and they can take time to run (which agents do not care)

2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about)

My gut feeling is that local structure, documentation, quality and quantity in the training data, etc are likely to play a more important role than typing for coding agents. I'd also love to measure how agents perform on specific domains. If you are writing concurrent software, how does Elixir/Java/Rust/Go compare? But without data, it's hard to say.

[AutoCodeBenchmark]: https://github.com/Tencent-Hunyuan/AutoCodeBenchmark

This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs.

Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies.

Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).

I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types.

People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught.

They also overstate how much types help their AI agents write code. I haven’t seen AI write a type related bug in years at this point.

I work with typescript on the front end, and my experience is totally different there. AI is constantly introducing type errors, but only because the original type wasn’t declared properly. Agents waste a ton of time and tokens appeasing typescript. Ruby and Elixir are very token efficient in comparison.

That said, now that I am not writing code by hand anymore, I am considering switching to something like Go. Mainly so I can run my side projects on smaller machines

Not necessarily. Since the word "typed" language is not well-defined.

For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define structs for each of your types (which would increase compile time & size)

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.

> is there any advantages of using untyped programming language

without any evidence, i claim the corpus might have higher quality variable names and conventions that are "human crutches" around not having types.

LLM knowledge in your non public codebase must be strictly local, and so checking on details and identities of types incurs a cost for the LLM to go fetch that info. if the LLM can "just know" (guess with very high confidence) then thats better for the LLM.

> non-typed languages has more traning data

as per anthropic "poisoning llms with 250 examples" finding, i suspect that corpus size does not really matter that much for any language that is reasonably well used.

> Rewriting critical software infrastructure (infostructure) to more reliable typed languages

Instagram (and Threads) is still using Django, which is even slower than Rails. Once you get to unicorn scale, your app is going to bespoke, with some microservices, and super custom stuff. If you can go faster in a gradually typed language, that can be a very good reason to choose one.

> untyped languages are not performant

Typing generally slows down languages, not speed them up because of all the additional checks that must be done. The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.

I don’t understand this question at all. Types are there to prevent human programmers from making a certain class of mistakes. But is the same true for AI. Because if not, static types are just needless cruft.

I use Elixir not because of typed/untyped, but because of BEAM and OTP.

Example:

https://xlii.space/eng/from-rust-to-ruby/

The thesis that you're making is biased. Huge tech corps can move away from Rails, but it's similar to argument of "why the most successful people in the world don't drive Toyotas". Which is true, but it doesn't mean people should stop using Toyotas and buy Koenigsegg instead.

Typed languages have consequences. Some designs are either non-ergonomic or impossible. Rust: if you want to have a swappable adapter you're in Box<dyn> world. Many apps don't have to live in Box<dyn> at all but they need to test which is the sole reason to change architecture and wrap in boilerplate.

None of these reasons matter if you're multimillion tech corporation with unlimited resources.

But these are very important reasons to consider when you have small-medium sized team and cannot afford to fight language.

Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy.

I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?

IMO all of these higher level languages that were designed for humans have a very short lifespan at this point.

The only thing propping them up seems to be loyalty for the most part.

Rails is still fantastic and handles massive load. 15 percent of all US commerce uses Ruby on Rails

I tried to get into elixir and ruby, but my mind just refuses statically untyped languages apparently.

I'm even less prone to use them with AI.

People no can Rust so people no use Rust. Simple as.

Elixir's gradual type system cannot change the asymptotic complexity of your programs. The design explicitly rules out mechanism that causes slowdowns in other gradual type systems (runtime casts at static/dynamic boundaries)

Most gradual type systems insert coercions when values cross the types/untyped boundary (checking every element of a list, wrapping values in typed proxies, etc) but Elixir's team published a "strong arrows" result specifically to achieve soundness without those runtime checks. The bytecode the compiler emits is semantically identical to untyped code.

The stability of the language is such a blessing.

I think that's part of the reason that LLMs do so well with it, despite its relative lack of popularity.

Elixir's heavy reliance on pattern matching has always made it kind of "dynamic language where you still have to think about types" vibe to it. It's also always had a spec meta-language (taken from Erlang) which a lot of people use. You should read up on how they have been implementing the type system, it's pretty interesting! I would not say it's "bolted on." It also has full inference so all codebases get the benefit of it whether you specify types or not.

Conversely, TypeScript is my favourite type system because it has to support the wild things people did in untyped languages.

I think Elixir is taking a very mature path to typing. No type-annotations (yet) just type inference from existing language constructs like function guards and pattern matching. Also trying to minimize false positives, only giving type errors when it would provably crash at runtime.

I agree with you but an alternative view, "Why are gradual static types so great?" https://www.benkuhn.net/gradual/

I've experienced this, but it's mostly because languages like Python and TypeScript give you way too many escape hatches. I get the intent: allow devs to convert their code base slowly. But in practice it just lets developers opt out of the benefits of typing to "save time" in the short run.

It also takes a long time for the ecosystem to catch up. It can be hard to retrofit static types over something that wasn’t built with them in mind

So JavaScript didn't work well and is successful?

It was poorly bolted on in Python. Well I dislike types to begin with, but aside from that, Typescript somehow did it better.

Typescript is brilliant and should be carefully studied by anybody introducing a type system to a single typed ("untyped") language.

I don’t know if it satisfies “already convenient to use”, but IMO ocaml fits “adds great features reliably and safely”. They merged their multicore compiler ~4 years ago, which was a pretty huge change that added parallelism through domains. Notably, they had a working version ~10 years ago, but refused to merge it until they sorted out some performance issues that would have affected existing single-threaded code.

I only say it’s not “already convenient to use” because I heard tons of complaints about the dev environment - mostly that there’s no debugger, no official package manager, etc. But they are working on ‘dune’, and just like the language itself, I got the impression that the dune developers were being conscious to “add great features reliably and safely”. So overall I thought it was a great language/ecosystem, ymmv though.

whats so excellent about it? i tried their ruby, swift and python tracks and i was left with a meh. i tried 30% of the Ruby path for instance and its just "do this" and " if you get stuck here are the docs".... and it calls itself " a learning path", there is nothing to learn.

Do you like Rust or do you like Erlang? Writing Gleam is like writing Rust, writing Elixir is like writing Erlang.

I don't know the current state of Gleam OTP, but last I checked it wasn't great.

If you don't care about either of those things and only about types, use Gleam. But then why not just use Rust?

Check Gleam website, they have the comparison right there.

Gleam doesn't have macros, which many Elixir libraries (such as Phoenix and Ecto) uses to great effect.

Gleam for example has issues with verbosity of decoding/encoding json whereas in Rust you derive serde and in Elixir it's just a function call away.

Elixir has a more mature ecosystem. While you can for example use Phoenix with Gleam (or some other Gleam framework) the experience just isn't the same.

The big draw with Gleam over Elixir is the typing (where Elixir is now closing the gap) and being able to compile to JavaScript (which is also what Hologram is doing for Elixir).

I prefer Gleam's typing system and the Rust-like syntax, but for now I feel Elixir is the better choice for all my web dev projects.

Phoenix and Ecto, really.

Why are types anti-lisp?

> you don't get bugs related to typing because elixir is somehow magic,

I've never followed Elixir particularly closely, but what I saw in some Erlang discussions was different. Discourse there was that you need to gracefully handle failure anyhow, so type errors can (should?) just get handled by the failure recovery machinery you're supposed to have anyhow. I disagree with that point of view, but it's much more defensible than "$LANGUAGE is magic".

It’s not so much language magic as it is “clustering preparedness” IMO.

Since any node in a cluster can be updated at any time and Elixir/Erlang code on the BEAM is designed make it easy to pass function calls to other nodes you don’t have any way of guaranteeing the Type contract between nodes. Types create a sort of false confidence in those situations where pattern matching handles everything very cleanly.

Example: You may not need to match on a full type, just a specific element name in a hash.

When people say Elixir doesn’t need types it’s not claiming that types are without value. It’s a claim that the mechanisms that already exist are enough without the added complexity.

I appreciate the gradual approach so that we can lean on both.

This is the Goomba fallacy.

https://en.wiktionary.org/wiki/Goomba_fallacy

I don't think anyone serious in the Elixir community ever said "you don't get bugs". Maybe you do get fewer bugs as a result of immutability and pattern matching features, but "no bugs" is definitely not a promise I've ever heard.

The thing you DO hear a lot, though, is that you don't need to worry about bugs nearly as much as you do in other languages. But that's not because Elixir is "magic", rather, it comes from Elixir's runtime (Erlang/BEAM) providing best-in-class fault tolerance primitives like lightweight process isolation and supervision trees.

In practice that means the blast radius of bugs is generally tiny and any resulting crashed processes are often recoverable. The phrase you often hear is "let it crash", since the effort that goes into exhaustive defensive programming is usually more costly than the bugs you'd be trying to prevent.

How did Elixir manage to attach static type checking to a language after the fact without drastically revising the type system or incurring runtime validation costs? I don't know Elixir, but I have some impression that the BEAM's famous qualities played a role: immutability, "let it crash" philosophy, no inheritance malarkey, etc. Elixir itself had to have a type system that was already relatively orderly for it to be possible to write the relevant proofs way after the fact, right?

Maybe the things that made this transition feasible are the "magic" that used to make people say "Elixir doesn't really need types". Maybe what they meant was something like "Elixir is an orderly language in a bunch of ways that makes the lack of static typing less painful to me than usual".

And I guess we'll see how much people get out of this when they add type annotations later. Maybe the value add will be big after all, and then they'll really be proven wrong. But I can sort of imagine how the apparent contradiction fits together.

It was the same thing with javascript/typescript and python. Sometimes you just have to let people think what they want.

I can’t swear I’ve never seen that claim - but I can’t remember seeing it if I ever did and certainly it would be a tiny minority position. The actual con arguments are basically “it is nice but has costs, maybe those don’t all get a good return”.

It’s possible that position was correct before set-theoretic type theory was developed.

I think Elixir is interesting and there is real value but some stuff being sold as "all these libs/packages that haven't had any updates for over a year is fine because Elixir" I just don't buy it

and to that point around typing feels like the same wish-washy hand waving from the community that is very off putting

BEAM has genuine use cases but its not as wide as its made to believe. There are very good places where that is a perfect fit but it simply cannot upend Typescript.

Elixir feels very similar to how Clojure started getting traction and then ultimately forgotten apart from its die hard fans, I'm not saying Elixir will go the same way but seems very hard for something new and bold to replace what is popular and boring.

I do want Elixir to succeed (also Clojure as well and I advocated for it for a bit) but the low number of jobs still puts it in similar proximity to Clojure but BEAM I think would still provide uplift where Clojure simply could not

It's the circle of life. Dynamically typed language has fans. Other people correctly say that it would be a lot more useful with static types. Fans take this personally and say it doesn't need static types because (they aren't useful anyway/it goes against the spirit of the language/it's only a scripting language anyway/you can just use a debugger/static types hurt productivity/etc. etc.)

Then eventually they add static types. Happened to Python, JavaScript, Ruby... I'm sure there are more.

Please share that conversation you reference where the community said Elixir doesn’t need types because it is magic.

> you don't get bugs related to typing because elixir is somehow magic

Really? All the Elixir fans were saying that?

Not really a contradiction. You don't need typing, but it can help.

No, this comes from interacting with the community, companies, and large projects throughout the years, followed by research, publishing of papers, and careful analysis on the costs and benefits of introducing said feature! Only then we added it.

https://pragprog.com/titles/lhelph/functional-web-developmen...

don't let the title fool you - the first half of the book is just elixir

over the past 8 years this is the book i've used to ramp back up on elixir and it works like a charm every time - i've never finished it

for me, a mark of a good programming book in this tutorial-project style is that I have started it half a dozen times and never finished it because at some point before the end I've been equipped w/ the tools to go off and do my own thing

I invite you to ask on ElixirForum. I have never seen a truly hostile response.

Sometimes posts don't get traction due to ambiguity, and some smelled like "do my homework" so people ignored them.

But every post with a genuine curiosity in it gets answered, as far as I can tell.

Do you maybe know some Rust? I'm also not that experienced with FP languages, but Gleam felt familiar enough, due to some Rust-isms, to allow me to focus more on the concepts rather than the syntax. Granted, I spent a few afternoons with it, but if I were to pick a FP language again to wrestle my brain into submission, I'd probably go with Gleam due to familiarity.

> I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again.

I experienced this really painfully when I was in college and took a kind of "survey of programming paradigms" course and tried Haskell for the first time. I'd been programming for years by then, and I couldn't believe how helpless I was at trying to complete things that had long felt "basic" to me.

But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again.

I think you'll gradually improve. I think the thing that finally made functional programming feel comfy for me was realizing how much I love composing code that basically feels like more generously spaced Bash "one-liners". The data starts out in one shape, so you run a command to dump it. Then you think of a step that gets it closer to what you want, you pipe it to that next command, and you take another look. And you keep going and at the end what you're looking at is typically pretty close to a series of transformations of data that you never mutate!

Part of what makes this feel comfy in the shell is that you build up that vocabulary of commands just by puttering around your file system every day. Over the years my library of familiar "functions" in a Unix-like environment has grown quite large. In a pure functional programming environment, you have to do the same thing but it takes a little more effort to learn the vocabulary. Your most frequently used "commands" will be functions like map, fold, and zip instead of grep, cat, or sort. But the core of it is really the same, and what I love about building pipelines applies equally to both: you can build it piece by piece, and for each puzzle you're on, you can forget about the previous steps and just think about the next transformation of the data that's in front of you. There is something refreshingly, relaxingly low-context about that.

Anyway I hope you give it a try and enjoy it. When we can learn to enjoy being bad at something, that's how we finally get good at it.

Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.

Do https://htdp.org and follow all the exercises carefully (yes, it will feel like baby work at first) - you will retrain your brain for functional stuff. :-)

Come hang out on Elixir Forum! Lots of friendly folks there who are happy to answer (and re-answer) beginner questions. It's not quite what it was a few years ago thanks to LLMs, but it's still quite active.

EDIT: I see my cohort has already given you this suggestion :P

What functional stuff is throwing you off? A whole bunch of it can be written procedurally when starting out.

I find beginners respond well to this resource: https://joyofelixir.com/toc.html

community is super nice I am sure you will get help.

How did you score freelance Elixir work?

The syntax you are commenting on has always existed in Elixir, before v1.0, as part of patterns and guards.

You are commenting as if we added this now but we have made no changes to the language surface. The difference is that we now leverage these same language constructs to extract precise type information.

You can of course still do the second thing, the types are not forced if you don't want them!

That is just wrong.

> You need Beam and the Elixir. I find that really weird, because I'm used to just the language like in Python, Java, C, Rust. Not something underneath it, too

The beam is a VM. You get that Java requires a VM too right? It’s called JVM for a reason. And Python requires an interpreter.

> There is no debugger. The way to debug Elixir is to print stuff to the console, like 40 years ago.

That is false. https://www.erlang.org/doc/apps/debugger/debugger_chapter.ht... and you have observer. And you have a lot of other debugging tools. I hear Java has a good one and maybe it’s better (I never used it) but it’s not true there exist no debuggers for the beam.

Java has the JVM the same way that Elixir has Beam/OTP/...

But then you have all the Erlang libraries for free which is huge. And you add to them the Elixir libraries and that gives you a lot of stuff, just like you get with languages with rich libraries e.g. Java, Ruby, ... I find it reassuring.

If you're used to Java, Elixir is like `javac`, Beam is like `java`. Mix is like a (way better) version of Gradle. You need elixir to compile your app, you only need the Beam to run it. Once you've built your project, you don't need Elixir anymore exactly like java/javac. C and rust compile to machine code so don't have a runtime dep, but otherwise they still require you to have a compiler at build time, just like elixir.

I genuinely needed that laugh. Thank you

To be fair, there is more than just print debugging. You have access to tools like red(x)bug https://github.com/nietaki/rexbug, the Elixir-LS project has Debug Adapter Protocol support. And in my opinion, the REPL (and decent software architecture) makes it easy to investigate your code by just running the functions as needed (even if your live production system if you want).