That article was way better prepared than I was prepared for. I like how it translates its code into Ruby's official types-in-headers format. Very nice.
I think this is a nice way to include types into a project if you like it. I know when you're working on large Ruby projects - 10s of thousands of lines across hundreds of files - types become really, really helpful to figure out what on earth is happening where. In the past I've used DryRb and was pretty happy with it; but an even deeper connection, like this, looks wonderful.
I don't programme much any more but the whole beauty of Ruby that it pretty much heavily relies on #respond_to? / duck typing and thus you don't rely on types or class checking at all.
The playground seems broken, I can't get it to report any kind of error. It seems to accept even syntactically incorrect files (e.g. just one unmatched closing parenthesis).
I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context.
But what is the point of the recent wave of types for python, Ruby, and similar languages?
If it’s type safety you want there, there’s a bajillion other languages you can use right?
(I'm not sure if this still holds under a world where LLMs are doing the majority of writing code but this is my opinion from prior to LLMs)
From someone who has worked mostly in Ruby (but also Perl and TypeScript and Elixir) I think for web development, a dynamic language with optional types actually hits maybe the best point for developer productivity IMO.
Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
With an actual fully typed language you're much more constrained in terms of what idioms you can use and how you can express and handle code by the type system. If you're not adept or knowledgeable about these things you can spend a lot of time trying to jam what you're attempting into the type system only to eventually realize it's impossible to do.
A gradual type system on top of a dynamic language gets you some of the best of both worlds. A huge amount of the value is just getting typing at function boundaries (what are the types of the arguments for this function? what is the type of what it's returning?) but at the same time it's extremely easy to just sidestep the type system if it can't express what you want or is too cumbersome.
> Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
One of the worst parts of exploring an unfamiliar codebase written in a language without type labeling is tunneling through the code trying to figure out what this thing you see being bounced around in the program like the a ball in a pinball machine actually is.
That is a fair opinion. My opinion is different, but that's totally fine - we have different views here.
What I completely disagree with, though, is this statement:
> Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable.
I have been writing ruby code since about 22 years (almost) now. I never needed types as such. My code does not depend on types or assumptions about variables per se, although I do, of course, use .is_a? and .respond_to? quite a lot, to determine some sanitizing or logic steps (e. g. if an Array is given to a method, I may iterate over that array as such, and pass it recursively into the method back).
Your argument seems to be more related to naming variables. People could name a variable in a certain way if they need this, e. g. array_all_people = []. This may not be super-elegant; and it does not have as strong as support as types would, but it invalidates the argument that people don't know what variables are or do in complex programs as such. I simply don't think you need types to manage this part at all.
> Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
Note that this is intrinsic complexity that is valid for ANY codebase. I highly doubt just by using types, people automatically understand 50.000 lines of code written by other people. That just doesn't make sense to me.
> With an actual fully typed language you're much more constrained in terms of what idioms you can use
I already don't want the type restrictions.
> A gradual type system on top of a dynamic language gets you some of the best of both worlds.
I reason it combines the worst of both worlds, since rather than committing, people add more complexity into the system.
In large - and honestly even medium - and honestly-honestly even _not-small_ python projects, you often end up losing track of what stuff is.
At one of my jobs, i was often plagued by not knowing if "f" - short for file, naturally, that part is fine tbh - was a string, an io-like thing, a path object, a file object, or what-have-you. Sure sure, some argue this is the magic of python - just try to do whatever you want to it, and if it doesn't work, throw an error - I know I know. I'll tell you that's all really cool until you have 8 different people passing around 8 different types and you're just trying to have the darn program not crash and also not print logs like "could not snafucate file: [whatever str/repr comes out when you print() an IO object]". And this isn't one of those cases where being able to shrug at the type is like, buying you anything. It's just a damn file.
So, when python's types came out, I started going in and type hinting f: str where i found it and could determine it was a string. (and various other things like this - obviously f is just an example). And suddenly after enough of this, we just stopped having that problem. Coworkers thanked me when they saw me in the diffs adding them. People just passed in strings.
I'll also add that in most programs, most types are just primitives, built-in collections, and structs composing those two. So while it's quite nice yes that you can do crazy backflips that would simply not work in more rigidly typed languages, often I do want to just reassure everyone that yes, please pass in a str for "file". And if i've typed it as str|IO then do feel free to also pass in an IO. It just lets me talk to the other programmers in the codebase a lot more easily. I'm not trying to enforce correctness of types necessarily. I'm just trying to communicate.
the overall field is known as "gradual typing", and it is an attempt to combine some of the benefits of both static and dynamic typing (or to put it more accurately, to explore more of the benefits and tradeoffs on the static to dynamic spectrum). in the "type checkers for ruby/python/js" part of the spectrum what you are trying to ask is "how much static type safety can I add without giving up the power of the dynamic bits", so for instance you have code that generates classes as runtime (not really compatible with a strictly static type system in the most general case), but specific very common uses of code generation, like python's dataclasses, have support within the type checker.
That still has not really explained why they (those who propose that) need types in ruby specifically. Whether python has it or not is not relevant because it is another language. The argument that "language xyz has it, so ruby needs it", can be compelling, but does not necessarily have to be compelling. It needs to have a use case for ruby in and by itself. I don't see that intrinsic use case.
I work in Ruby a lot on large/old projects. I think the main reasons are: people nowadays are very dependent on editor intellisense, and "undefined method ... for nil" errors in production are very frustrating.
That said, I am actually in the "don't want types in Ruby" camp. Intellisense isn't as needed if you're good at using irb (the repl). And the dynamism makes it super easy to write unit tests, which can give you back a lot of the guarantees you'd otherwise get from static types. Most importantly, a lot of the fun in Ruby comes from the ability to make nice DSLs and aggressively metaprogram boilerplate away.
the argument is not "some other language has it so we should", the argument is "static type checking is very useful even if it is not 100% strict, and ruby's lack of syntactic support for type annotations makes them clunky to use, so here's an enhancement that adds them".
the intrinsic use case is that your code is often implicitly statically typed, even if the language itself doesn't enforce that, so it's nice for tools to check it for you. this gets more and more useful the larger your codebase gets; python and javascript have shown that in practice.
and note that people have already written type checkers for ruby, they are just much less pleasant to use because there is no nice way to express the types you would like to check/enforce.
At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.
I have been programming with Ruby for 11 years with most of the time in a professional context. It's my favorite language :).
I don't care much for types, but it can be useful with denser libraries where IDE's can assist with writing code. It has been helpful in my professional life with regards to typed Python and Typescript.
One potential example that would be interesting is utilizing types for reflection for AI tool calling, the python library for Ollama already supports this[0].
It would make it easier to use such tools in a Ruby context and potentially enhance libraries like ruby-llm [1] and ollama-ruby [2].
Yeah. I have the same question and none of the type addicted
folks could answer that. The explanations usually boil down
to "I used C, so now I need types in other languages too".
That's like 90% of the explanations you can see.
Being able to retroactively apply type definitions to a system can be helpful for large legacy application refactoring where simply choosing a type-safe language is not an option.
Languages take time to get used to and to get productive in. IF you already know Ruby, and want the same safety as C# for instance, then this makes sense.
I agree on the first part. This is valid for all programming languages though.
I disagree that you get the same safety as C# anywhere though. But even more importantly - I don't think people should write C#-like code in ruby. It does not really work that well. It is better to write ruby like ruby; and even in ruby there are many different styles. See zverok using functional programming a lot. I stick to oldschool boring OOP; my code is very boring. But usually well-documented. I want to have to think as little as possible because my brain is very inefficient and lazy; zverok has a good brain so he can write more complex code. It is very alien code to me though, but he also documents his code a lot. You can find his code or some of his code here, it is a quite interesting ruby style, but also alien to me: https://zverok.space/projects/
(Ruby also adopted some habits from perl. I also don't think writing perl-like ruby makes a lot of sense. See also the old global variables inspired by perl; I can not recall most of them off-hand, so I avoid using them. My brain really needs structure - it is such a poor thinking machine really. And slow. My fingers are much faster than my brain really.)
I agree somewhat, but I'd rather call it their brain adjustment than a religion though.
I think about 99% of people who suggest to slap down types onto dynamic
languages have already been using types since decades, or many years,
in another language. Now they switch to a new language and want to have
types because their brain is used to.
If it is at all possible, it would be nice to have a little bit better support for metaprogramming namely around `define_method` and supplying a typed lambda or block for the dynamic method. I can see why this would be a pain to implement, so I don't expect it :).
Otherwise, I think in terms of typed Ruby, this is an incredible undertaking with very well written documentation. Thank you for making this library, I think there's a lot that the Ruby community can benefit from with it. Cheers!
In the context of Lua, I’ve taken a liking to LuaLS (Lua Language Server). You can just write your Lua scripts with annotations (where needed) and the language server can help auto-complete and verify type usage. No compilation step needed.
I never tried “typed Lua” variants (such as MoonScript IIRC), but I believe those do require a compilation step.
def greet(name: String): String
"Hello, #{name}!"
end
Yep - looks like utter s...
I understand that many programmers come from languages
where their brain has been adjusted to necessitate and
depend on types. And they get help from the compiler
in capturing some errors. But it is the wrong way to
think about programs and logic. I'd wish these guys
would stop trying to ruin existing languages. Go add
types somewhere else please.
Note: I also use java, so I am not against types per
se. I am against a want-on need to slap down types
onto everything and your Grandma, merely because your
brain (of type afficionados) needs them for survival.
That article was way better prepared than I was prepared for. I like how it translates its code into Ruby's official types-in-headers format. Very nice.
I think this is a nice way to include types into a project if you like it. I know when you're working on large Ruby projects - 10s of thousands of lines across hundreds of files - types become really, really helpful to figure out what on earth is happening where. In the past I've used DryRb and was pretty happy with it; but an even deeper connection, like this, looks wonderful.
I'd really enjoy it, I think :)
I don't programme much any more but the whole beauty of Ruby that it pretty much heavily relies on #respond_to? / duck typing and thus you don't rely on types or class checking at all.
> https://type-ruby.github.io/playground
The playground seems broken, I can't get it to report any kind of error. It seems to accept even syntactically incorrect files (e.g. just one unmatched closing parenthesis).
Honest question:
I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context.
But what is the point of the recent wave of types for python, Ruby, and similar languages?
If it’s type safety you want there, there’s a bajillion other languages you can use right?
(I'm not sure if this still holds under a world where LLMs are doing the majority of writing code but this is my opinion from prior to LLMs)
From someone who has worked mostly in Ruby (but also Perl and TypeScript and Elixir) I think for web development, a dynamic language with optional types actually hits maybe the best point for developer productivity IMO.
Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
With an actual fully typed language you're much more constrained in terms of what idioms you can use and how you can express and handle code by the type system. If you're not adept or knowledgeable about these things you can spend a lot of time trying to jam what you're attempting into the type system only to eventually realize it's impossible to do.
A gradual type system on top of a dynamic language gets you some of the best of both worlds. A huge amount of the value is just getting typing at function boundaries (what are the types of the arguments for this function? what is the type of what it's returning?) but at the same time it's extremely easy to just sidestep the type system if it can't express what you want or is too cumbersome.
> Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
One of the worst parts of exploring an unfamiliar codebase written in a language without type labeling is tunneling through the code trying to figure out what this thing you see being bounced around in the program like the a ball in a pinball machine actually is.
> the best point for developer productivity IMO.
That is a fair opinion. My opinion is different, but that's totally fine - we have different views here.
What I completely disagree with, though, is this statement:
> Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable.
I have been writing ruby code since about 22 years (almost) now. I never needed types as such. My code does not depend on types or assumptions about variables per se, although I do, of course, use .is_a? and .respond_to? quite a lot, to determine some sanitizing or logic steps (e. g. if an Array is given to a method, I may iterate over that array as such, and pass it recursively into the method back).
Your argument seems to be more related to naming variables. People could name a variable in a certain way if they need this, e. g. array_all_people = []. This may not be super-elegant; and it does not have as strong as support as types would, but it invalidates the argument that people don't know what variables are or do in complex programs as such. I simply don't think you need types to manage this part at all.
> Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase.
Note that this is intrinsic complexity that is valid for ANY codebase. I highly doubt just by using types, people automatically understand 50.000 lines of code written by other people. That just doesn't make sense to me.
> With an actual fully typed language you're much more constrained in terms of what idioms you can use
I already don't want the type restrictions.
> A gradual type system on top of a dynamic language gets you some of the best of both worlds.
I reason it combines the worst of both worlds, since rather than committing, people add more complexity into the system.
In large - and honestly even medium - and honestly-honestly even _not-small_ python projects, you often end up losing track of what stuff is.
At one of my jobs, i was often plagued by not knowing if "f" - short for file, naturally, that part is fine tbh - was a string, an io-like thing, a path object, a file object, or what-have-you. Sure sure, some argue this is the magic of python - just try to do whatever you want to it, and if it doesn't work, throw an error - I know I know. I'll tell you that's all really cool until you have 8 different people passing around 8 different types and you're just trying to have the darn program not crash and also not print logs like "could not snafucate file: [whatever str/repr comes out when you print() an IO object]". And this isn't one of those cases where being able to shrug at the type is like, buying you anything. It's just a damn file.
So, when python's types came out, I started going in and type hinting f: str where i found it and could determine it was a string. (and various other things like this - obviously f is just an example). And suddenly after enough of this, we just stopped having that problem. Coworkers thanked me when they saw me in the diffs adding them. People just passed in strings.
I'll also add that in most programs, most types are just primitives, built-in collections, and structs composing those two. So while it's quite nice yes that you can do crazy backflips that would simply not work in more rigidly typed languages, often I do want to just reassure everyone that yes, please pass in a str for "file". And if i've typed it as str|IO then do feel free to also pass in an IO. It just lets me talk to the other programmers in the codebase a lot more easily. I'm not trying to enforce correctness of types necessarily. I'm just trying to communicate.
the overall field is known as "gradual typing", and it is an attempt to combine some of the benefits of both static and dynamic typing (or to put it more accurately, to explore more of the benefits and tradeoffs on the static to dynamic spectrum). in the "type checkers for ruby/python/js" part of the spectrum what you are trying to ask is "how much static type safety can I add without giving up the power of the dynamic bits", so for instance you have code that generates classes as runtime (not really compatible with a strictly static type system in the most general case), but specific very common uses of code generation, like python's dataclasses, have support within the type checker.
That still has not really explained why they (those who propose that) need types in ruby specifically. Whether python has it or not is not relevant because it is another language. The argument that "language xyz has it, so ruby needs it", can be compelling, but does not necessarily have to be compelling. It needs to have a use case for ruby in and by itself. I don't see that intrinsic use case.
I work in Ruby a lot on large/old projects. I think the main reasons are: people nowadays are very dependent on editor intellisense, and "undefined method ... for nil" errors in production are very frustrating.
That said, I am actually in the "don't want types in Ruby" camp. Intellisense isn't as needed if you're good at using irb (the repl). And the dynamism makes it super easy to write unit tests, which can give you back a lot of the guarantees you'd otherwise get from static types. Most importantly, a lot of the fun in Ruby comes from the ability to make nice DSLs and aggressively metaprogram boilerplate away.
the argument is not "some other language has it so we should", the argument is "static type checking is very useful even if it is not 100% strict, and ruby's lack of syntactic support for type annotations makes them clunky to use, so here's an enhancement that adds them".
the intrinsic use case is that your code is often implicitly statically typed, even if the language itself doesn't enforce that, so it's nice for tools to check it for you. this gets more and more useful the larger your codebase gets; python and javascript have shown that in practice.
and note that people have already written type checkers for ruby, they are just much less pleasant to use because there is no nice way to express the types you would like to check/enforce.
At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.
I have been programming with Ruby for 11 years with most of the time in a professional context. It's my favorite language :).
I don't care much for types, but it can be useful with denser libraries where IDE's can assist with writing code. It has been helpful in my professional life with regards to typed Python and Typescript.
One potential example that would be interesting is utilizing types for reflection for AI tool calling, the python library for Ollama already supports this[0].
It would make it easier to use such tools in a Ruby context and potentially enhance libraries like ruby-llm [1] and ollama-ruby [2].
[0] https://docs.ollama.com/capabilities/tool-calling#using-func...
[1] https://rubyllm.com/
[2] https://github.com/flori/ollama-ruby
Yeah. I have the same question and none of the type addicted folks could answer that. The explanations usually boil down to "I used C, so now I need types in other languages too". That's like 90% of the explanations you can see.
Being able to retroactively apply type definitions to a system can be helpful for large legacy application refactoring where simply choosing a type-safe language is not an option.
Languages take time to get used to and to get productive in. IF you already know Ruby, and want the same safety as C# for instance, then this makes sense.
I agree on the first part. This is valid for all programming languages though.
I disagree that you get the same safety as C# anywhere though. But even more importantly - I don't think people should write C#-like code in ruby. It does not really work that well. It is better to write ruby like ruby; and even in ruby there are many different styles. See zverok using functional programming a lot. I stick to oldschool boring OOP; my code is very boring. But usually well-documented. I want to have to think as little as possible because my brain is very inefficient and lazy; zverok has a good brain so he can write more complex code. It is very alien code to me though, but he also documents his code a lot. You can find his code or some of his code here, it is a quite interesting ruby style, but also alien to me: https://zverok.space/projects/
(Ruby also adopted some habits from perl. I also don't think writing perl-like ruby makes a lot of sense. See also the old global variables inspired by perl; I can not recall most of them off-hand, so I avoid using them. My brain really needs structure - it is such a poor thinking machine really. And slow. My fingers are much faster than my brain really.)
Crystal is a cool Ruby-like.
Religious coders spreading their religion.
I agree somewhat, but I'd rather call it their brain adjustment than a religion though.
I think about 99% of people who suggest to slap down types onto dynamic languages have already been using types since decades, or many years, in another language. Now they switch to a new language and want to have types because their brain is used to.
If it is at all possible, it would be nice to have a little bit better support for metaprogramming namely around `define_method` and supplying a typed lambda or block for the dynamic method. I can see why this would be a pain to implement, so I don't expect it :).
Otherwise, I think in terms of typed Ruby, this is an incredible undertaking with very well written documentation. Thank you for making this library, I think there's a lot that the Ruby community can benefit from with it. Cheers!
interesting idea, good on them for trying something different in the Ruby ecosystem.
The website is quite extensive, but the gem only has ~1.5k downloads. It’s presumably very early on the adoption curve
In the context of Lua, I’ve taken a liking to LuaLS (Lua Language Server). You can just write your Lua scripts with annotations (where needed) and the language server can help auto-complete and verify type usage. No compilation step needed.
I never tried “typed Lua” variants (such as MoonScript IIRC), but I believe those do require a compilation step.
I understand that many programmers come from languages where their brain has been adjusted to necessitate and depend on types. And they get help from the compiler in capturing some errors. But it is the wrong way to think about programs and logic. I'd wish these guys would stop trying to ruin existing languages. Go add types somewhere else please.
Note: I also use java, so I am not against types per se. I am against a want-on need to slap down types onto everything and your Grandma, merely because your brain (of type afficionados) needs them for survival.
Don't show this to DHH
Wait, what happens if you want keyword arguments?