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

41–50 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#41

Post by webstrand »

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?

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.

Re: T-Ruby is Ruby with syntax for types

#43

Post by cloverich »

shevy-java wrote: post #15
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?

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.

Re: T-Ruby is Ruby with syntax for types

#45

Post by jaggederest »

systemnate wrote: post #40
omarqureshi wrote: post #25

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.

#respond_to? is fine, it's really more #is_a? that is a code smell, in my opinion. As long as you're dispatching based on #respond_to? (i.e. "does this respond to each") by calling the method you're checking, when it does respond, you're fine as far as duck typing goes. It's when you check #is_a? and then dispatch based on type where things get weird.

An example I always used to use was something like a method that could take a single item or a collection:

    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

Re: T-Ruby is Ruby with syntax for types

#47

Post by rezonant »

omarqureshi wrote: post #25

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.

I don't think you're really losing the ability to check if an object responds to a message ie a_car.respond_to?(:color) just because theres type annotations. And I assume the type checker doesnt yell if you do a_car.color after that -- or if it does there's surely an equivalent to Typescript's `any` to accomplish it.

And T-Ruby apparently provides interfaces to avoid needing to do this at all (assuming both sides are written in T-Ruby I assume) https://type-ruby.github.io/docs/learn/interfaces/defining-i...

...which is awesome!

As for authoring classes, respond_to_missing?/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_missing?(name, priv)
            [:color, :color=].include?(name)
        end
        def method_missing(name, *args, &block)
            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

Re: T-Ruby is Ruby with syntax for types

#48

Post by elliotec »

satvikpendem wrote: post #34
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?

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.

Are they _solving_ these issues of dynamism with typing? What other issues does it introduce?

Re: T-Ruby is Ruby with syntax for types

#49

Post by pansa2 »

exabrial wrote: post #44

Worth mentioning is Crystal lang: Ruby, with types!

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

Re: T-Ruby is Ruby with syntax for types

#50

Post by satvikpendem »

elliotec wrote: post #48
satvikpendem wrote: post #34

Earlier quoted context omitted.

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.

Are they _solving_ these issues of dynamism with typing? What other issues does it introduce?

Yes they are. Issues with typing on top is that it's not necessarily always robust enough, and not every company has the resources or premier language developer at the helm like Microsoft's TypeScript's Anders Hejlsberg.
Post reply on HN