5 ms·

Show HN: Ruby static type checker – proof of concept

115 points by stereobooster 9y ago

wasd 9y 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?
- stereobooster 9y 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 9y ago
Another interesting project is RDL: https://github.com/plum-umd/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 9y 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 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.
  - stereobooster 9y 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-317079792 https://github.com/plum-umd/rdl/issues/33#issuecomment-31707...
- chrisseaton 9y 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/ http://rubybib.org/
- woodruffw 9y 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 9y 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.
- stereobooster 9y 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).
xuejie 9y 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 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 9y ago
  I've been having a look http://dry-rb.org/ http://dry-rb.org/ it seems pretty interesting
- stereobooster 9y ago
  But those are for dynamic typing. I was looking for static typing
  - xuejie 9y 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
    - stereobooster 9y ago
      Again Crystal is not Ruby. https://github.com/crystal-lang/crystal/issues/4731#issuecomment-318486278 https://github.com/crystal-lang/crystal/issues/4731#issuecom... > we might never get static typing for Ruby anytime soon Yes we will not get type declarations as a part of Ruby syntax anytime soon, but this doesn't mean we can not have static type checking right now
hamandcheese 9y 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 https://crystal-lang.org
- mbell 9y 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 9y ago
    Crystal supports metaprogramming. Just on a much lower level. Ruby metaprogramming is convenient - Crystal's is powerful.
- stereobooster 9y ago
  Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecomment-318486278 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 9y 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 9y 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 9y 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 9y 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.
- stereobooster 9y 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-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
pmontra 9y 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 https://ruby-doc.org/stdlib-2.4.2/libdoc/drb/rdoc/DRb.html

115 points by stereobooster 9y ago

wasd 9y 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?

stereobooster 9y 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 9y ago

Another interesting project is RDL: https://github.com/plum-umd/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 9y 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 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.
- stereobooster 9y 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-317079792 https://github.com/plum-umd/rdl/issues/33#issuecomment-31707...
chrisseaton 9y 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/ http://rubybib.org/
woodruffw 9y 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 9y 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.

stereobooster 9y 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).

xuejie 9y 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 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 9y ago
I've been having a look http://dry-rb.org/ http://dry-rb.org/ it seems pretty interesting
stereobooster 9y ago
But those are for dynamic typing. I was looking for static typing
- xuejie 9y 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
  - stereobooster 9y ago
    Again Crystal is not Ruby. https://github.com/crystal-lang/crystal/issues/4731#issuecomment-318486278 https://github.com/crystal-lang/crystal/issues/4731#issuecom... > we might never get static typing for Ruby anytime soon Yes we will not get type declarations as a part of Ruby syntax anytime soon, but this doesn't mean we can not have static type checking right now

hamandcheese 9y 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 https://crystal-lang.org

mbell 9y 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 9y ago
  Crystal supports metaprogramming. Just on a much lower level. Ruby metaprogramming is convenient - Crystal's is powerful.
stereobooster 9y ago
Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecomment-318486278 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 9y 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 9y 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 9y 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 9y 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.
stereobooster 9y 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-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

pmontra 9y 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 https://ruby-doc.org/stdlib-2.4.2/libdoc/drb/rdoc/DRb.html