Show HN: Ruby static type checker – proof of concept

https://github.com/stereobooster/diamondback-ruby/tree/master/examples

by stereobooster • 9 years ago

115 24 9 years ago

wasd• 9 years ago

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?

stereobooster7• 9 years ago

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.

jbackus• 9 years ago

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.

kyleashipley• 9 years ago

From what I could gather from this talk at Strangeloop, RDL seems like an evolution or expansion of Diamondback: https://m.youtube.com/watch?v=buY54I7mEjA (See ~21:30ish for discussion of the various attempts along the way.)

Was a really interesting and well-done talk, IMO. I am not a type system geek, but thought it was fascinating to hear all of the tradeoffs that go into designing a system like this.

stereobooster7• 9 years ago

RDL and Diamondback have a different approach. Diamondback works with given code without modification and able to find (some) errors, RDL needs code modification. See this issue https://github.com/plum-umd/rdl/issues/33#issuecomment-31707...

chrisseaton• 9 years ago

From what I can tell, Ruby is barely touched otherwise by academia.

There’s a tiny bit more Ruby in academia but not much http://rubybib.org/

woodruffw• 9 years ago

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.

ainar-g• 9 years ago

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.

stereobooster7• 9 years ago

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

xuejie2• 9 years ago

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.

vvdcect• 9 years ago

I've been having a look http://dry-rb.org/ it seems pretty interesting

stereobooster7• 9 years ago

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

xuejie2• 9 years ago

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

hamandcheese• 9 years ago

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

mbell• 9 years ago

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.

pkd• 9 years ago

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

stereobooster7• 9 years ago

Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecom...

Imagine you have a big ruby project in production and you want to add static type checking. You won't be able to use Crystal for it, while the idea behind Diamondback Ruby is to be able to integrate it gradually.

nine_k• 9 years ago

Crystal is closer to Ruby in many aspects than e.g. Rust or Haskell or Nim. It might be an easier step into the land of static typing for someone acquainted to Ruby.

It's not a static type checker for Ruby, though.

krapsna• 9 years ago

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.

dragonwriter• 9 years ago

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.

kazinator• 9 years ago

If, without sacrificing any dynamic aspects of a language, we can be better informed about programs and expressions before they are executed, it's almost a pure win, and therefore a no-brainer. ("Almost" because we pay for it with some machine cycles and memory required to execute the checks.)

If you call a three-arg function with only two-args, it is more helpful to see a diagnostic than not to see a diagnostic, all else being equal.

stereobooster7• 9 years ago

The reason is to fight with bugs, which are caused by type errors. Current approaches are:

1) use guards 2) add tests which check types 3) use error reporting software, like Sentry, and cath errors in production

Is there any reason you do not want not catch type errors without additional code and useless tests before you deployed it to production?

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

pmontra• 9 years ago

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

Show HN: Ruby static type checker – proof of concept

Related Stories