I think static-typing will be useful for the short term
I’m not a fan of static types/have no intention of (or don’t think I’ll be) using them/don’t think they are worth it now or will be in the foreseeable future (feel free to elaborate in thread)
Other (please say in thread)
0voters
(Please note this is a general discussion, not necessarily about Elixir)
Static typing will be always useful because it reduces the problem search surface for any computer, be it a strict algorithm or an LLM. Less assumptions + more certainty = better solutions.
I voted other. 1) I think we’re a long ways away from LLMs/AI getting to the point where where types are superfluous. 2) As an engineer I’ve simultaneously enjoyed the wild west of Ruby and and more “locked down” languages with modern type systems. I could honestly go either way (right tool for the job, etc.). But I do think types will be invaluable for the next ~5 years. LLMs perform best when they have access to quick self correcting feedback loops. Right now types and tests serve that role.
Here’s a screenshot from the Matz keynote at RubyKaigi 2025 where he talks about this very topic. My only wish is for better subtitles since the ones there are from the live translation during the talk so it’s a bit hard to understand the context.
Perhaps this should be in the related thread, but someone mentioned Scala as having a ‘next level’ type system. I asked G2.5P about this in ref to Elixir’s plans:
LOL to be clear this was a joke But ya, I actually didn’t even really consider if there was any truth to it. I think it will always be useful since vibe coding doesn’t sound fun (and I don’t really think it’ll take off like some think it will).
The main benefit of a type system is providing a clear format for documentation. After that, the main benefit of a type checker is ensuring the documentation is correct After that, you get the additional benefit of quickly catching small mistakes as you write code, which is convenient for a tighter feedback loop.
Of course if the model is writing code for you then the documentation is for it rather than you, so the question is really “is documentation useful for LLMs?”, and thus far it seems like the answer is “yes, critically”.
Type systems and even unit tests are wholly inadequate for proper correctness testing, you need fuzz/property-based tests and, for distributed systems and things which touch the disk or network, you need a deterministic simulator as well. This requires putting at least as much creative effort into designing tests as you do into designing the program itself, if not more. I doubt current models are as yet capable of that, but who knows where the goalposts will end up!
the video excerpt from the rant(in the description has a link for the full talk
I have an impression that people that really like static typing are the ones that are attached to the editor. While people that prefers dynamic typing is more driven by the repl. whenever i’m working the first thing I do is start iex and then I start doing my changes and call recompile on the repl.
I guess the reason of my pet peeve with static typing is that very few typing systems that I had experience with had a good feedback loop(I guess only Elm was a pleasant experience). Most of the time I was trying to please the type system just to try and test some changes. But I really like the idea of types as first and foremost documentation.
If I don’t typespec my functions I eventually forget what shape of data they accept. Elixir is better than most in that we can pattern match/guard the signatures, but there are still glaring blind spots (you can’t pattern match [{non_neg_integer, %MyStruct{}}]). For that reason, I look forward to the type system!
Obviously you can also write docstrings but those are even harder to keep in sync with the functions; I find I often leave them out of date by accident in practice. That’s what I mean when I say the type checker is useful for ensuring the documentation is correct
I also write typespecs as documentation for the functions. One thing that I’d like to see in the new type system is the possibility to define types with literals other then atoms. it would be really good to explicitly work with functions that transforms external data. But althought the type system allows it, doesn’t seems that they’re going in that directon
Typespecs allow literal integers actually. Literal strings would be interesting but I think the usefulness would be substantially diminished vs. e.g. TypeScript because we mostly use atoms where they use strings for options and such. What other literals would you want?
mainly strings, mostly because i dont like this pattern of enforcing atom keys on everything. I usually set atom keys on data that is built in the code, not the ones that are transformed in the code. I think it makes it easy to deal with external data and schemaless jsonb fields in the db.
TIL that typespecs allow literal integers. I guess the moment I had issues with string literals I stopped trying to use them and added the context that I needed into docstrings(also other thing that would be good is to allow private functions to have docstrings and hexdocs just ignores them when building the docs, it’s better than writing commentaries).
The thing is, when you have string keys it’s generally because they are “un-parsed” structures, i.e. JSON that you got from wherever and haven’t validated. So, at that point, the structures aren’t typed yet. A type system won’t do anything there.
When you do validate the JSON, you are by definition conforming its keys to a known set. And at that point it’s okay to turn them into atoms and use them in types. This is what happens when you cast in Ecto, for example.
I suppose you could make a point that you want to validate the structure but then keep the string keys, but when working with structured data I really prefer to have structs with the data.field syntax and guaranteed keys, so idk.
I was also very surprised when I found out lol. I have yet to actually use them, though.
I don’t like this approach. I’ve worked on systems that derailed pretty bad with a lot of intermediary structs that was terrible to test and terrible to change. I remember one particular case that the same data had 3 different structs that was used just validate/communicate with other systems and check if the data was valid.
I often use schemaless changeset when I need to enforce some some shape/types on data. But when I’m dealing with only reshaping the data to send to another system I prefer to just deal with the shape, I prefer that because the validation and enforcement that I do on my side will be meaningless if the other system rejects it.
I was lost by the question, I assumed this was an easy answer that everyone agreed on. But I guess it depends on what type of AI you have envisioned, my model of AI would be something that can spit code out without the need of runtime verification hence static types are necessary. I dont know enough about type theory, but I think you can verify a programs property or parts of it, just off its types & fn types with a strong statically typed language and even more so with a dependently typed language
Now if you envision an AI that has the mcp form factor , inputs into your running system and then updates code while your system is running, fixes any runtime bugs and writes a bunch of test then I can see the argument.
So again I said this in jest as a jab at “vibe coding.” When I use that term, I mean it in the extreme sense that it has now come to mean where you only interact with an agent and you never look at the code it produces. This would be in the same way that the vast majority (if not all) of us never look at the machine code our high level languages produce. And yes, there are a whole bunch of people who belive that that is where we are headed. In this extreme hypothetical circumstance, how could it possibly matter if code is statically typed or not? You aren’t looking at it so there’s no advantage there. If the agent chooses to use types, they could have bugs, but you’d never know (you’d know when you’re program crashes but you wouldn’t know the cause). More to the point, maybe the LLMs will have gotten so “smart” that they themselves act as the type checker and don’t bother with annotations.
Soooooo ya, it’s a hypothetical that may or may not be a reality sooner or later. Who knows. I’m mostly exhausted by all the AI talk and really any kind of tech hype at this point.
Also, I’m mad because my favourite punctuation is the em dash and now Chat Jippity is making me self-conscious and paranoid about using it.
I think some languages will always require static typing. LLM’s are not omnipotent (actually they are infinitely far from it) and cannot be trusted for tasks that require absolute precision.
On the other hand, some languages do not require any typing whatsoever with or without AI.
Their prospective employers/clients will tell them. Too bad for them they’ll be 5-10 years older than now with no relevant skills. No wonder it’s called “vibecoding” for it sure as hell can’t be called vibeprogramming.
The entire “AI” hype is very reminiscent of the boy bands cult (aka “crypto startups”) from less than ten years ago. Seems it’s been an eternity since given the almost complete loss of collective memory of what the previous greater fool game used to feel like.
In essence, to me this whole thing looks pretty binary: Either we end up inventing AGI (the actual AI) and life will never be the same again, or we end up realizing the smarter autocomplete and cheaper movie production was not really worth all the hype (we’re not yet there with a cheaper movie production, but I dare to assume we will be able to tweak it to consistently fool our senses).
But ya, I actually didn’t even really consider if there was any truth to it. I think it will always be useful since vibe coding doesn’t sound fun (and I don’t really think it’ll take off like some think it will).
After that, you get the additional benefit of quickly catching small mistakes as you write code, which is convenient for a tighter feedback loop.
