Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

T-Ruby is Ruby with syntax for types

type-ruby.github.io

Post reply on HN
Print view View original

121–130 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#121

Post by tekknolagi »

dudeinjapan wrote: post #70
torben-friis wrote: post #3

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?

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 the same method argument. 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 a…

YJIT and ZJIT don't use method annotations.

Re: T-Ruby is Ruby with syntax for types

#122

Post by rajangdavis »

Lio wrote: post #101
rajangdavis wrote: post #10

Earlier quoted context omitted.

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

DSPy.Rb uses static Sorbet types if that's what you're looking for. https://github.com/vicentereig/dspy.rb

This is really neat, thank you!

Re: T-Ruby is Ruby with syntax for types

#123

Post by mrinterweb »

vidarh wrote: post #115
mrinterweb wrote: post #62

Earlier quoted context omitted.

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

I would strongly oppose mandatory typing for these reasons, but I'm very happy to have stable low level libraries add type annotations.

When I'm writing code that will be distributed to other devs, I feel type annotations make more sense because it helps document the libraries and there is less ambiguity about what a method will take. As with everything, "it depends"

Re: T-Ruby is Ruby with syntax for types

#124

Post by [deleted] »

sethammons wrote: post #99
ReflectedImage wrote: post #68

Earlier quoted context omitted.

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

I have experience that I think most don't. My experience says you are very, very incorrect. In the past couple of decades I have been through a couple IPOs, a couple of acquisitions, and have been in engineering leadership roles and slinging code in half a dozen different shaped eng/dev cultures. In every case, static typing makes teams faster and gradual typing was a pain with potential payoffs that were muddy. Grad…

[deleted]

Re: T-Ruby is Ruby with syntax for types

#125

Post by dismalaf »

dudeinjapan wrote: post #70
torben-friis wrote: post #3

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?

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 the same method argument. 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 a…

> First, YJIT/ZJIT do much better when they know the type signatures of methods.

The running interpreter knows the type of objects. Ruby isn't untyped.

The annotations do nothing for the interpreter.

Re: T-Ruby is Ruby with syntax for types

#126

Post by dajonker »

rurban wrote: post #114
ReflectedImage wrote: post #85

Earlier quoted context omitted.

Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities. Common Lisp showed you the way. But almost none looked at it. Only PHP did.

At least CPython and CRuby (MRI), the most common implementations of each language, ignore all type hints and they are not able to use them for anything during compile or runtime. So the performance argument is complete nonsense for at least these two languages.

Both Python and Ruby (the languages themselves) only specify the type hint syntax, but neither specifies anything about checking the actual types. That exercise is left for the implementations of third party type checkers.

Re: T-Ruby is Ruby with syntax for types

#127

Post by usernamed7 »

hey this is pretty cool! very interesting concept to transpile to rbs.

in most of my coding career (rails) i have not needed types. But when i was working on a large codebase with many teams, the lack of types was a recurring issue. now i work in a SOA and face different coupling challenges.

But i much prefer this syntax to what RBS required.

Re: T-Ruby is Ruby with syntax for types

#128

Post by jweir »

zingar wrote: post #65
jweir wrote: post #31

Earlier quoted context omitted.

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. 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? “It has a field of type X” has never been a useful test for me, my tests are always more like: “if I send message X I get return value or action Y” … with my admittedly limited experience of types I don’t see how they replicate this. Therefore it looks like I’d only be “replacing” tests th…

We have some tests that ensure the interface is correct - that the correct type of args are passed say from a batch process to a mailer and a mail object is returned.

For these tests we don’t care about the content only that something didn’t get incorrectly set or the mailer interface changed.

Now if the developer changes the Mailer to require a user object the compiler tells us there is an error. Sorbet will error and say “hey you need to update your code here and here by adding a User object”

Before we would have had test coverage for that - or maybe not and missed the error.

Re: T-Ruby is Ruby with syntax for types

#130

Post by sethhochberg »

zingar wrote: post #67
dymk wrote: post #33

Earlier quoted context omitted.

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

I don’t think the existence of a library to do something is evidence of the community shifting. For me the complete absence of types from any Ruby I see IRL or in examples from conference talks, readmes etc is evidence that the community is uninterested despite tons of effort from big players.

I think there's some real sample bias in that definition of "the community" though, because people who are passionate Ruby programmers giving conference talks, running meetups, etc are often a distinctly different group than the regular-old programmers making business software go 'round every day. The big players writing tools for bringing various flavors of type safety into Ruby are doing it because they're experiencing the pain of having lots of programmers working on large, complex software over years-long periods with the tools that Ruby gives you out of the box. They often employ some of those community fixtures, but thats not the majority of an engineering organization.

The reality is that there certainly are enthusiast programmers who can thrive with the lightweight elegance of stock Ruby, but most people writing code professionally aren't enthusiast programmers under ideal conditions. Everything is always a little more distracted, a little less well-defined, and a little more coupled to legacy than anyone would want. And those are the conditions where I want my tools working as hard as possible, automatically, for me / my teams.

Post reply on HN