Live data from Hacker News

T-Ruby is Ruby with syntax for types

type-ruby.github.io

21–30 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#21

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?

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.

Re: T-Ruby is Ruby with syntax for types

#22
post #4

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?

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

Re: T-Ruby is Ruby with syntax for types

#23

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?

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.

Re: T-Ruby is Ruby with syntax for types

#24
post #12

Earlier quoted context omitted.

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 dynam…

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.

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.

Re: T-Ruby is Ruby with syntax for types

#26
post #12

Earlier quoted context omitted.

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 dynam…

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.

Re: T-Ruby is Ruby with syntax for types

#28
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 :)

Re: T-Ruby is Ruby with syntax for types

#29

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?

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

Re: T-Ruby is Ruby with syntax for types

#30

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN