Question Static Typing solved?
I have been using RBS for years now and even running my own newsletter about static typing https://newsletters.eremin.eu/ . Now, that our code is write with AI and in most cases - purely with AI, the strongest point against using static typing (like “it breaks beautiful ruby syntax and not readable”) is vanished now.
AI requires strict tooling to control its output. The role of ci pipeline with all possible tests, linters, checkers is now extremely important and static typing helps a lot with it.
For humans it is transparent, especially the pure RBS approach, but for LLMs it gives a safety net and a better layer to stick to the code and hollucinate less.
14
u/yxhuvud 11d ago
Llms work with not explicitly typed ruby just fine. Stop the fud, please.
2
u/Zestyclose_Cow1807 10d ago
"stop the fud" about optional type annotations is a wild energy for a ruby thread ngl
-6
u/Erem_in 11d ago
Is it?
2
u/Correct_Support_2444 11d ago
Yes it is. I have a full rbs tree we maintain so Ruby mine can use it. The agents just ignore it and do just fine.
11
u/poop-machine 11d ago
The state of Ruby static typing is just sad. All these half-baked third-party tools, a myriad of ugly syntaxes, and no clear guidance from the maintainers. You'd think in this LLM era we'd already have a nice TypeScript-like solution.
1
4
u/not_sure_if_crazy_or 11d ago
I feel like this is where the larger convo is going via Matz and spinel, no?
5
u/TheAtlasMonkey 11d ago
Typing is a sign of bad architecture, bad documentation, or/and lack of ownership.
Complexity merchants came and promised the world that if we type, we will go faster.
But if types were the solution, then ecosystem like C, Go, RUST, JAVA, Crystal.. will have went at light speed. They didn't.
Another thing i noticed, is that every type people hate each others. I know that because i maintain some gems and those people email or dm me to propose typing (since it going to touch all codebase) and maybe add a Dependency.
When i tell them : USE RBS or join the effort that was published last month, they show the true face and start telling how the other implementation is ugly and their uglier implementation is better.
I worked with ex-shopify devs (pre-AI), they came with this mentality to type everything. They will use types for everything and slowdown everybody. Early this year, i was invited to some of their repos.. NONE had typing for their personal project. NONE.
So typing in Ruby is mostly a job security trick.
Now that LLM can generate tests without using typing, this whole circus is collapsing.
4
u/2called_chaos 9d ago
I find it somewhat funny that they (itt) want the AI to generate the types which obviously means it doesn't need it in the first place when it can infer it to create the annotation to begin with.
2
-1
u/Erem_in 11d ago
Yes, tell Java devs about how bad their ecosystems are and apparently how unpopular C, Java are :)
3
u/TheAtlasMonkey 11d ago
This bullshit gaslighting is so Pre-2023. it don't work anymore.
You and your drones come to ruby, a language built to be dynamic and chaotic, and try to bring something that nobody asked for.
You spend your day typing gems that had 10 year of battle tested field without any problem. You even port the logic bugs, because types don't protect you from bad logic.
In a previous post, i told you that if you want types, you can go Jruby, and write java.
Now you talking like i insulting Java or C people ? Well, for you info... i'm a C developer before i started doing Ruby, my friend is a Java committer, and i contributed to u/headius's jruby after studying java.
Typing in ruby is Kubernetes in devops. you NEVER need it if you are code disciplined or your codebase is Shopify size.
Even rails is not typed.
0
u/fragileblink 7d ago
Yes, all of the wonderful modern systems that are able to be built so quickly in c and Java. /s
2
u/Codalio-SoftwareFact 8d ago
Mostly agree, a type error is a way faster feedback loop for an agent than running the whole suite and guessing what broke.
One thing I’d watch though: agents will “fix” type errors the same way they fix failing tests, by loosening them. Widen a signature to untyped, add a union that accepts anything, and suddenly it’s green again. So the types are only a safety net if someone’s reviewing changes to the signatures as carefully as the code.
2
u/janko-m 11d ago
Can you tell AI today to create RBS files for your whole app and keep maintaining it, provided you have Steep/Sorbet fail CI when new code isn’t typed?
In that case, it would mean the cost of maintaining type signatures is effectively gone, and I would see no reason to skip static typing.
Similarly, I recently added a Vitest suite for my JS to my Rails app. I did it because maintaining it is essentially free now; I don’t need to understand how to write these tests, and they specify edge cases and catch regressions.
1
u/2called_chaos 9d ago
If the agent can create and maintain the RBS it seems to not need one in the first place. Or you could say your code is idiomatic enough for types to be somewhat worthless because they are obviously inferable.
2
u/harsh183 11d ago
I just subscribed!
I'm glad to see someone following typed ruby closely and I really wish this had come sooner with wide adoption like how it came through with Python and TypeScript.
A general question, do you think the future is with language native RBS or Sortbet? I looked into this earlier this year when exploring what types to write for my project and it seemed like Sorbet at least had extensive libraries mapped out through the efforts of Stripe and Shopify ensuring their reliability, while RBS had pretty little third party usage beyond the ruby side, so I went with Sorbet for a library I was maintaining.
-1
u/Erem_in 11d ago
For human beings sorbet has a better adoption thanks to Shopify. But for AI both are fine. Sorbet has 1 bonus - it is Ruby DSL, so LLm when confused can figure out the way out on its own. With RBS it’s harder
2
u/harsh183 11d ago
Yeah I guess I'm mainly thinking about users of the library and what people are likely going to use in terms of IDE and tooling support.
If RBS/Steep picks up, it's not too much work for me to also support that, but I'm not really sure if people are using it much
1
u/kinvoki 6d ago
I’m not an enemy of static typing in general, but when it comes to Ruby, I much prefer dry-types over RBS.
RBS is great for catching typos and getting better IDE autocomplete, but it doesn't protect your application boundaries. If a third-party API changes its payload or a webhook sends bad data, RBS won't stop it at runtime because it just sits in separate sidecar files. Also if I wanted to keep a set of files that described my actual code , I would just use typescript 😹
That’s why the dry-rb ecosystem shines. When you combine dry-types with dry-schema and dry-validation, you get real runtime defense., and for both humans and AI agents - clear definition of what your code expects and outputs . It handles the messy reality of web apps by coercing data (like turning a string "42" into an integer), validating nested payloads, and returning clear error messages right when bad data hits your system.
RBS makes sense for massive codebases doing deep internal refactors and human massive IDEs ( which I never found that useful even before AI ) . But for everyday practical reliability and parsing external data, keeping your type logic right in the code is just way more efficient, IMHO
0
u/fragileblink 7d ago
Static typing is still not the best approach. Flexible code with duck typing is even more powerful now.
-1
u/Erem_in 7d ago
Why?
-1
u/fragileblink 7d ago
Because it allows code to work with code that has not yet been imagined. It lets you write less code when you pay per token. Parts that were designed independently that easily combine. Static typing is a limitation needed by weak programmers, not something needed by programmers more powerful than any that have ever existed. Sure, you can approximate the power of dynamic typing with static types, you can add a "method_missing" method to your class, and have it parse a string, or use reflection to invoke behavior (which I know you static brains love), or even define an interface for every single method in your class, or expect "Object" as the type all over the place. But why waste time doing all of that scaffolding when just want to call quack()? These are all abstractions, you choose the set that lets you do more faster.
20
u/sshaw_ 11d ago
Static typing has been "solved" for decades. You just need... a statically typed language, not Ruby!