T-Ruby Is Ruby with Syntax for Types

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.

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'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.

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

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.

Religious coders spreading their religion.

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.

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.

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.

The developers who are using the statically typed languages, which are slower to develop in, with are being pushed to use the faster languages.

But those developers don't know how to code in type free languages. So they attempt to add the types back in.

This of course reduces the software development speeds back to their previous speeds.

This means the whole thing is basically folly.

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.

Exact same program but the development costs went up proportionally to the increase in the strength of the type system.

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.

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.

Two reasons.

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 a method signature.

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.

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).

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).

Types may be rarely important for local variables, but they matter for API contracts.

Strong static typing is a must for large scale software engineering. And by "large scale" I mean anything longer or more complicated than like a utility shell script.

These type extensions let you get some of the benefits of static typing for projects already written in Python or Ruby.

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?

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.

Picking a “better” language or learning a framework in another language is not always a pragmatic choice.

It is desirable to have types at the entrypoints and at IO usually. Even rails has validations and SQL has schemas , or there are file formats

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.

> what is the point of the recent wave of types for python, Ruby, and similar languages?

Code that doesn't integrate directly with wires (controllers, active record, websocket, etc)

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.

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.

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?

It's a way to dig yourself out of the hole without a full rewrite, and with a smaller retraining effort for your developers.

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.

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, but 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.

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).

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.

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.

You could use an entirely different language of course, but that involves other changes and compromises.

Those who hate Java and C# without understanding are doomed to recreate them.

keyword arguments are, internally, syntactic sugar over a hash. It probably doesn't easily work with typing the explicit values of a raw hash

Their docs say that something like:

`def greet(name: String, greeting: String = "Hello"): String`

will work for kwargs with default values — https://type-ruby.github.io/docs/getting-started/understandi...

  def greet(name: String | "Hello"): String

Yeah, it doesn't work with keyword arguments. In the playground I tried a simple keyword with default value, and it converted to the wrong thing, as if "someone" was a valid type.

    def greet(name: "someone"): String
      "Hello, #{name}!"
    end

It would seem that in T-Ruby all arguments are keyword arguments, although they don’t really spell this out.

https://type-ruby.github.io/docs/learn/functions/optional-re...

The obvious thing that comes to mind when looking at their spotlight example.

However, no mention of this basic head scratcher in the docs. :rolling_eyes:

I'm sad you're getting downvoted. This is objectively uglier Ruby code. Ruby is a gorgeous language, and aesthetics is seemingly not allowed in the conversation.

I'm not convinced that the time savings of types exist at all, but even if it took twice as long to do anything with types, there is a completely valid argument that "it's worth it to look at nicer code".

This could be interesting, but do you have arguments other than "stop ruining muh languages" or "u r dumb"?

I've just come from another thread where you wrote a response much like this.

In both cases, I'd say you're undercutting your own points by being overly bombastic and harsh towards people with different viewpoints.

You'll engender equally impassioned responses, which won't actually engage with your overall points, but which will instead be mean and catty right back at you. Maybe this is what you want, but I doubt it. There's much more useful discussions to be had on HN.

Most ruby code isn't written like that - it's written like most static languages, where objects conform to interfaces / traits / type classes / pick your poison. The community is shifting towards explicitly specifying and statically checking types now. rbs and sorbet are a testament to this.

I wouldn't say it's really a beauty of the language, it may have been the original design intent but time has shown what's actually maintainable.

Using #respond_to? is normally a code smell. The point of duck typing is exactly that it allows you to avoid checking the type of a class. As long as the object responds to the correct messages, the type does not matter.

    def unpicky(something)
      if something.respond_to?(:each)
        # unpack using each or recurse to something.each do |item| unpicky(item) end
      else
        # main body
      end
    end

respond_to?/method_missing should be rare, usually in a situation where its the only way to accomplish something. There's never been a reason to write something like:

    class Car
        def respond_to?(name)
            true
        end
        def method_missing(name, *args)
            if name == :color
                @color
            elsif name == :color=
                @color = args.first
            end
        end
    end

Instead of

    class Car
        def color; @color; end
        def color=(value); @color = value; end
    end

Or, more idiomatically

    class Car
        attr_accessor :color
    end

And for that last case, T-Ruby apparently covers it with:

    class Car
        attr_accessor :color: String
    end

Structural typing like this is completely compatible with the concept of duck typing. Indeed, it's basically doing static checking of duck typing.

Yeah, I think it would be great if this project made it clear how this compares with Crystal.

How alike actually are Ruby and Crystal? I’ve heard the similarity is only skin-deep: similar syntax but quite different semantics.

In other words, isn’t describing Crystal as “Ruby with types” similar to describing C++ as “JavaScript with types”?

> Ruby, with types!

"Language with ruby-like syntax" more appropriate.

Not on Firefox Android. Either they already fixed the problem or it's OK here. I didn't check with Firefox on desktop yet (Linux).

We were raving about new atheism too. Bad ideas come and go.

The problem I see with low-code is that it lacks static analysis to evaulate type usage before runtime and, I don't think, it has any support for tooling so you can't get method usage information in the editor.

I think that static analysis could be done with an extension to rubocop via Prism though. Same for documention features via Ruby-LSP tooling.

I think if they worked on those they would very quickly pick up support as the syntax is quite nice.

Typescript. I imagine most people writing Rails applications are also writing typescript for front-end code, so being able to use the same muscle memory for Ruby typing seems high desirable. That is the thing that stood out to me when I saw this site: it looks like they are taking the very positive lessons from Typescript and applying them to Ruby.

I agree with other posters here. I don't need everything typed - Ruby's duck typing is an awesome feature - but I do wish that some of the more important interfaces in our code were more strongly self-documenting and enforced.