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?
garrison
cevado
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).
2
garrison
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.
1
cevado
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.
2
plcholder
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.
3
sodapopcan
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.
5
DaAnalyst
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.
1
sodapopcan
DaAnalyst
Sure maybe not now, but just wait a few months!
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).
4
venkatd
I am already seeing that AI agents will produce a solution with a typing violation (in Typescript) and correct themselves on the fly. I am certain when Elixir types land, the same will happen with Elixir.
Imagine you optimize for a new engineer is joining your project and they need to get productive quickly. Whether that new engineer is an AI or a human being will is almost irrelevant. Because it’s a very similar thought process:
- Documentation helps
- Comments help
- Consistent project structure help
- Being concise is better than being too verbose
- Types will reduce the chance they structurally break things
I think it might matter because sometimes us humans might still need to pop open the hood to inspect what’s going on. It might also matter for the AI itself. After all, the AI will need some sort of representation of the code that’s easy for the AI to work with. And i think that higher level representations are probably more efficient.
For arguments sake imagine AIs had to write assembly code instead of JS. It would be a lot harder for even the AI to produce working code. Again the point is that the code representation will still be very important for AIs. Perhaps languages will need to evolve to be easily digestible for humans AND AI, but it seems to me there is a lot overlap.
3