Honest question:<p>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.<p>But what is the point of the recent wave of types for python, Ruby, and similar languages?<p>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)<p>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.<p>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.<p>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.<p>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.<p>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 <i>actually is</i>.
This is our experience. We have added Sorbet to a 16 year old Rails app. It is a big win in avoiding errors, typos, documentation, code completion, fewer tests are required, etc.<p>And the LLMs take advantage of the types through the LSP and type checking.
I’d love to hear from you or someone in your shoes: what are some patterns or examples of tests that are made redundant by types?<p>“It has a field of type X” has never been a useful test for me, my tests are always more like:<p>“if I send message X I get return value or action Y”<p>… with my admittedly limited experience of types I don’t see how they replicate this.<p>Therefore it looks like I’d only be “replacing” tests that I’d never write in the first place.<p>What am I missing?
One of the big advantages of types is documenting what is *not* allowed. This brings a clarity to the developers and additionally ensure what is not allowed does not happen.<p>Unit tests typically test for behaviours. This could be both positive and negative tests. But we often test only a subset of possibilities just because how people generally think (more positive cases than negative cases). Theoretically we can do all those tests with unit testing. But we need to ask ourselves honestly, do we have that kind of test coverage as SQLLite? If yes, do we have that for very large codebases?
> the best point for developer productivity IMO.<p>That is a fair opinion. My opinion is different, but that's totally fine - we have different views here.<p>What I completely disagree with, though, is this statement:<p>> 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.<p>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).<p>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.<p>> 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.<p>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.<p>> With an actual fully typed language you're much more constrained in terms of what idioms you can use<p>I already don't want the type restrictions.<p>> A gradual type system on top of a dynamic language gets you some of the best of both worlds.<p>I reason it combines the worst of both worlds, since rather than committing, people add more complexity into the system.
The times I've been bitten by type safety issues is far less than the hassle of maintaining types. Seriously, it is a much smaller issue than people make it out to be. I will say that I do get bitten by the occasional `NoMethodError` on `nil`, but it really doesn't happen often. Since ruby is very dynamic it is hard to say how many of those errors would be caught even with type annotation. I also don't find myself needing to write specs to cover the different cases of type checking. For me it is a tradeoff with productivity.<p>That said, I do like it when an LSP can show some nice method signature info, and types are helpful in that way. I think it depends. At the surface level, I like some of the niceties that type annotations can bring, but I've seen how tricky defining more complex objects can get. Occasionally I would spend way too much time fighting types in elixir with dialyzer, and I've often not enjoyed TypeScript for the verbosity. So I understand the cost of defining types. To me, the cost often outweigh the benefit of type annotation.
I fully agree with this. I'm building a site in OCAML, and I just this week spent 90 minutes debugging some weird error I didn't understand because an implicit type was being pulled through in a global context. It was pretty irritating.<p>Maybe this isn't a fair comparison, since I'm pretty new to OCAML and I'm sure an experience developer would have seen what was happening much quicker than I would have. But I'm not sure I spent 90 minutes TOTAL on type errors doing Python web dev.<p>Maybe I'm exaggerating, and I probably just don't remember the first time I hit a type error, but my experience with type errors was that I would very occasionally hit them, and then I would just fix the type error. Pretty easy.
Ruby provides a lot of really nice libraries; and Ruby on Rails - *especially its ActiveAdmin infrastructure* is best-in-class for "build something stupid-fast". Legitimately, I'll spend a day or so per-page on making administrative sites that do a 1/10th of what ActiveAdmin does in like 2 lines. And AA does it much prettier, too.<p>I write in Kotlin for myself, and Ktor and React or Ktor and Htmx + SolidJS, for web stuff; but those are decisions I made for myself, (edit: and) I know what it's costing me to not have the raw convenience that is Ruby's Active Admin infrastructure, among other things, I'm sure.
A bunch of companies started a decade or two ago and became very successful using the dynamic language du jour back then, and now they're facing issues with said dynamism, so they introduce types to fix those issues, see Meta with Hack over PHP and Stripe with Sorbet over Ruby. The point is not for new users, it's for existing users to improve their development environments.
Type free languages like Lisp, Python and Ruby have faster software development times than languages that use types.<p>The developers who are using the statically typed languages, which are slower to develop in, with are being pushed to use the faster languages.<p>But those developers don't know how to code in type free languages. So they attempt to add the types back in.<p>This of course reduces the software development speeds back to their previous speeds.<p>This means the whole thing is basically folly.<p>If you want a real example you can take a look at Turborepo, which in weakly typed Go took 1 developer 3 months to develop and has 20,000 lines of code. The direct port to Rust took a team of developers 14 months to develop and has 80,000 lines of code.<p>Exact same program but the development costs went up proportionally to the increase in the strength of the type system.<p>There are plenty of developers out there who have only used static typing and don't understand it comes with massive software development costs compared to it alternatives.<p>If you are developing a SaaS and you use duck typing, unit tests and micro-services. You will get to market long before your competitors who don't.
This is junk. Writing a type annotation takes basically zero time, then saves you time by preventing the runtime error because you forgot which variable was which, then saves you more time by autocompleting the correct list of valid methods when you hit dot.<p>Acting like Go is comparable to JS is ridiculous; Go's type system is the only kind of type system needed in Ruby. Rust is a staggering outlier in complexity. And the Turborepo port took a long time specifically because they tried to port one module at a time with C interop between the old and new codebases, which massively slows down development in any language, especially Go. This is just about the most dishonest 'example' you could have picked.<p>Either that or you are saying 'weakly typed' to mean type inference in `var := value`, in which case (a) Rust has that too and (b) that's not what the debate is about, nobody is against that
Making the type annotations pass restricts you to writing more bloated and verbose programs in general.<p>Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker.<p>Any commercial code will need to be unit tested so there is no time saving from finding runtime errors earlier and an any good IDE will detect the same errors and provide you with the same auto complete automatically for free without any type annotations at all. These are problems which exist solely in your head.<p>1 developer vs a whole team of developers. I think you need to face the facts.<p>There are studies comparing old dynamically types languages against statically type languages. They always show approximately 1/3 of the lines of code being used with 3x faster development times in the dynamically types languages. This isn't some new discovery.<p>Well even Python is strongly typed but for the sake of this we are discussing type complexity.
You are comparing apples to oranges, and go is pretty strong typed
If you don’t specify types explicitly they have to still exist somewhere: in someone’s head (in oral tradition of “Ah, yea, those IDs are UUIDs, but not those - those are integers”), or denoted through some customary syntax (be it something more formal like Hungarian notation, or less so - suggestive suffixes, comments, supplementary documents).<p>They still exist at runtime, and people who work on the codebase need to somehow know what to expect. Having a uniform syntax helps to formalize this knowledge and make it machine understandable so it can assist developers by providing quick hits and preventing mixups automatically (saving attention/time for other matters).<p>Types may be rarely important for local variables, but they matter for API contracts.
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.<p>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".<p>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.<p>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.
Existing ecosystem. As a random example, there's AWS SDK for ruby and python, but not for crystal and mojo. And if you want good compatibility, you're not writing that one on your own.<p>You could use an entirely different language of course, but that involves other changes and compromises.
I have been programming with Ruby for 11 years with most of the time in a professional context. It's my favorite language :).<p>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.<p>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].<p>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].<p>[0] <a href="https://docs.ollama.com/capabilities/tool-calling#using-functions-as-tools-with-ollama-python-sdk">https://docs.ollama.com/capabilities/tool-calling#using-func...</a><p>[1] <a href="https://rubyllm.com/" rel="nofollow">https://rubyllm.com/</a><p>[2] <a href="https://github.com/flori/ollama-ruby" rel="nofollow">https://github.com/flori/ollama-ruby</a>
Having to support legacy systems with 15y+ development where the system works but you wish you didn’t have to spend so much effort figuring out types?<p>Or maybe you are an expert with a framework, you are very productive with it, you know the tricks, but you wish it had types support so maintaining these systems would be easier.<p>Picking a “better” language or learning a framework in another language is not always a pragmatic choice.
In large - and honestly even medium - and honestly-honestly even _not-small_ python projects, you often end up losing track of what stuff is.<p>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.<p>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.<p>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.
Honestly, that just seems like a case that would just as well be solved by better naming. Get a linter, tell it to forbid one letter names, and then enforce naming that isn't idiotic when doing pull requests.<p>But yes, there are multiple ways to solve communication problems.
It's a way to dig yourself out of the hole without a full rewrite, and with a smaller retraining effort for your developers.
I like to think of typescript, pycharm, and whatever consumes t-ruby as, effectively, type-directed linters. The types are advisory only at runtime, so the full power of the dynamic language can be used. But at compile time the type can be checked and verified (insofar as they correspond correctly to the types at runtime).<p>So the reason to add types to python/ruby is that switching to a statically typed language you lose power and expressiveness. But if you use a type-directed linter, you can prevent many of the common errors writing in a dynamic language.
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.<p>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: <a href="https://zverok.space/projects/" rel="nofollow">https://zverok.space/projects/</a><p>(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.
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.
I have two genuine, straight forward answers for you. One, I have an important codebase written in a non-typed language, that is heavily developed still. So being able to add types to it (assuming I / team prefer that) is nice. Second is, I much prefer working in typed language, but company forces X language(s) (say, Ruby, Python, etc). Now I can use types (which I much prefer), and not change language (they prefer). Those are both real life examples. Third is hypothetical, but perhaps some people starting without types decide they like them later and want to dip their toes on. Most of these languages now offer incremental types for people to try them out.
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.
Two reasons.<p>First, YJIT/ZJIT do much better when they know the type signatures of methods. You pay a performance penalty for implicit polymorphism, e.g. using a mix of types (Integer, Symbol, String) etc in the same method argument.<p>Second, from my experience with Typescript, as much as I naturally dislike type declarations, I find it does help LLMs. Having strongly typed libs/gems and being able to mix in untyped app code would be a nice balance.
I have the same question. I've been in the software industry since the early 90s and I've seen the "static types are the best thing since sex" fad fade in and out repeatedly during that time.<p>Having used plenty of strongly-typed and dynamically-typed languages, I really can't say strong typing has had any effect on me whatsoever. I honestly couldn't care less about it. I also can't remember ever having a type-related bug in my code. Perhaps I have an easier time remembering what my types are than others do. Who knows?
> what is the point of the recent wave of types for python, Ruby, and similar languages?<p>Code that doesn't integrate directly with wires (controllers, active record, websocket, etc)<p>IMO This is for complex, well refactored, testable code that provides a business layer. Coding larger projects like depot management, shipment, order management, middle frequency trading, customs all benefit from types and IDE help. Types basically scale the language beyond just filling in the blanks in your framework. You can get pretty far doing that, but not far enough. That's why all ruby based companies push for type systems. They know the pain of not knowing what to pass, or refactoring code that allows a parameter to be multiple types.
A large preponderance of the former mindshare of Rubyists in the heyday moved on to other platforms. There's a metric crapton of unsupported and broken stuff. Plus, there are few/no assurances of safety or performance as there are in statically-compiled environments because of the narrow focus on "development happiness" without prioritizing much else. Also, rubygems has governance issues that spawned gem.coop and numerous supply-chain vulnerabilities as there's no mandatory cryptographic package signing and public key management. Oh, and it's not reputation but the unprofessional and unwelcoming groupthink and inflated egos expressed in real interactions get in the way and turn people off.
Religious coders spreading their religion.
I agree somewhat, but I'd rather call it their brain adjustment than a religion though.<p>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.
Nah. 99.9% of the people who wanted the addition of DryStructs to a codebase I worked on wanted it because they'd been bit, repeatedly, by someone sending one kind of object into a function rather than what the function accepted and it just not getting caught.<p>A robust type system allows you to make "compiler errors" out of runtime errors. One of these takes *way more tests to catch* than the other. I'll let you guess which.