Live data from Hacker News

T-Ruby is Ruby with syntax for types

type-ruby.github.io

31–40 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#31

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

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.

Re: T-Ruby is Ruby with syntax for types

#33

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.

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.

Re: T-Ruby is Ruby with syntax for types

#34

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?

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.

Re: T-Ruby is Ruby with syntax for types

#35
Yes. The proper way of adding gradual typing like Python, Typescript, and other platforms have. steep doesn't work in the rbs camp and sorbet in the rbi camp is more powerful with static and dynamic analysis, but it's also painful. The half-measures hand-wringing of separate type files, type, checking fragmentation that isn't usable, and awkward magic boilerplate comments are signs of leadership failure. Matz ain't software Jesus, sorry.

Re: T-Ruby is Ruby with syntax for types

#36

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?

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.

Re: T-Ruby is Ruby with syntax for types

#37

Wait, what happens if you want keyword arguments?

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

Re: T-Ruby is Ruby with syntax for types

#38
As someone who has been raising the concern of lack of type hinting in Python and Ruby since the beginning, this is a welcoming change with a “meh” on top. Also the whole shitshow with Go and generics that never made any sense.

Oh well.

Re: T-Ruby is Ruby with syntax for types

#39

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 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?

Re: T-Ruby is Ruby with syntax for types

#40

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.

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.
Post reply on HN