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