Show HN: Ruby static type checker – proof of concept(github.com)
github.com
Show HN: Ruby static type checker – proof of concept
https://github.com/stereobooster/diamondback-ruby/tree/master/examples
24 comments
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.
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.
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.
It's not a static type checker for Ruby, though.
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.
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.
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.
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.
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.
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...
> 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/
There’s a tiny bit more Ruby in academia but not much http://rubybib.org/
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.
I don't know what motivates Ruby research particularly, but those two languages make up a large chunk of our PL classes.
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.
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
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
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.
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.
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...
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...
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.
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.
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.
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.
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).
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).
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.
I've been having a look http://dry-rb.org/ it seems pretty interesting
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
After all, Crystal is already quite good as a Ruby+static typing solution
Again Crystal is not Ruby. 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
> 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
> 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