Live data from Hacker News

Show HN: Ruby static type checker – proof of concept

github.com

11–20 of 25 posts

Re: Show HN: Ruby static type checker – proof of concept

#11
post #5

So far, the author writes, it only supports 1.8 and not all of standard library. But if it ever supports 2.4 + Rails, that would be enormous.

> it only supports 1.8

Yes, it is because this is a fork of a project started in 2009 (and not maintained afterward). I spent a couple of evenings trying to resurrect it and see what this thing is capable of. There is a lot of things to do to make this really usable. But I was able to get it to the point to run examples (those examples are the same in ruby 2.4).

Re: Show HN: Ruby static type checker – proof of concept

#12
post #2

I'm incredibly impressed. @stereo, can you speak a bit to your ambitions? Have you talked with any ruby-core team about integrating what you're doing?

This rather tends to be a middle ground solution while we do not have an idea how to do types right in Ruby. Let me remind you that whole Ruby core team struggles with this question. But this thing can work with original source code without modification or with type annotations in comments, so it intentionally stays out of Ruby syntax.

Re: Show HN: Ruby static type checker – proof of concept

#13
If you’re interested in this, you might also be interested in the Crystal language.

> Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs.

> Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language clean, Crystal has built-in type inference, so most type annotations are unneeded.

https://crystal-lang.org

Re: Show HN: Ruby static type checker – proof of concept

#14

If you’re interested in this, you might also be interested in the Crystal language. > Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs. > Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language cl…

Crystal bears only very superficial resemblance to ruby. What makes ruby unique is meta-programming and it's object model neither of which Crystal supports in a remotely similar way.

Re: Show HN: Ruby static type checker – proof of concept

#15
Perhaps this went completely over my head somehow?

I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken without it.

I've been programming with Ruby every day for 5+ years, and it performs and debugs just fine without static typing.

My summary opinion is if static typing makes you happy go for it. Please don't try to force it into Ruby as a feature of the language, however, as it's current model of dynamic typing is one of it's best features.

Re: Show HN: Ruby static type checker – proof of concept

#16
post #15

Perhaps this went completely over my head somehow? I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken without it. I've been programming with Ruby every day for 5+ years, and it performs and debugs just fine without static typing. My summary opinion is if static typing makes you happy go for it. Please don't try to force it into Ruby as a feature of the language…

Optional static verification is becoming the norm in dynamic languages, Ruby has several libraries for it already. (This one seems different from other ruby ones I've seen in that it type checks vanilla Ruby rather than requiring annotations for type checking.)

This is a good thing for dynamic language adoption, because it means that organizations that evolve to where static typing is more important (larger teams and code bases, basically) don't have to either do a ground up rewrite or forgo it's benefits.

Re: Show HN: Ruby static type checker – proof of concept

#17
Ruby's standard library has a dRuby which is a distributed object system for Ruby [1]. I used it once almost 10 years ago.

I guess that the number of Ruby developers knowing about the two drubies is more or less the same, but maybe DRuby is not the most fortunate choice for a name.

[1] https://ruby-doc.org/stdlib-2.4.2/libdoc/drb/rdoc/DRb.html

Re: Show HN: Ruby static type checker – proof of concept

#18
post #14

If you’re interested in this, you might also be interested in the Crystal language. > Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs. > Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language cl…

Crystal bears only very superficial resemblance to ruby. What makes ruby unique is meta-programming and it's object model neither of which Crystal supports in a remotely similar way.

Crystal supports metaprogramming. Just on a much lower level. Ruby metaprogramming is convenient - Crystal's is powerful.

Re: Show HN: Ruby static type checker – proof of concept

#19
post #7

Although this might not be a direct comparison, based on how things go in the Ruby community, personally I feel dry-types & dry-struct ( https://speakerdeck.com/flashgordon/typed-ruby ) might be a better solution for typing. Yes it doesn't solve every problem, but for the business logic side of problem, this can be a decent solution.

But those are for dynamic typing. I was looking for static typing

Personally I feel we might never get static typing for Ruby anytime soon, at least it won't be widely adopted in the community, so I'd settle on dynamic typing like this.

After all, Crystal is already quite good as a Ruby+static typing solution

Re: Show HN: Ruby static type checker – proof of concept

#20
post #3

Another interesting project is RDL: https://github.com/plum-umd/rdl Both Diamondback and RDL come out of UMD. I'm curious what drives this research there. From what I can tell, Ruby is barely touched otherwise by academia.

Ruby is also taught in UMD's undergraduate PL classes, as a sort of transitional language for the functional paradigm (which we learn in OCaml).

I don't know what motivates Ruby research particularly, but those two languages make up a large chunk of our PL classes.

Post reply on HN