
Consider Static Typing in Ruby - mxhold
http://codon.com/consider-static-typing
======
pmontra
As a 10 years Rubyist I'm conflicted about this.

First, if I wanted to use a static typed language I have plenty of them to
chose from, when I started using Ruby and more right now. One of the reasons
I'm using Ruby is that it works well enough without having to tell types to
the interpreter (which is already pretty strict about them because - example -
it doesn't automatically cast strings and numbers into each other like JS and
Perl do).

However, in some very rare cases an object without method M gets passed as
argument where an object with method M is expected and the code fails at
runtime. It would be nice to catch this in advance, but if the price to pay is
to start declaring types like I did in C and Java, no thanks. The problems I
had because of dynamic typing have not been big enough to go through all that
pain again (and code pollution.)

We'll see what Matz ends up proposing to us, then we'll discuss it. I hope to
be able to keep my code free from type declarations and optionally throw in
some constraint when I really want to be sure that an object belongs to some
class or has some methods. Nothing more.

~~~
grandalf
The bad things about Ruby are mostly Ruby cultural norms, like willy nilly
metaprogramming often done by unskilled people, published as a gem, and used
by many others, some of whom create useful gems.

Static typing would be a benefit. I think Matz realizes that with the rise of
Javascript transpilers Ruby is going to have to fight hard to remain relevant.
Give Swift a few more months and there is already a pretty solid language with
ruby-like simplicity and a well designed type system.

~~~
lukeschlather
Ruby obviously competes with Node, but is there any chance of Ruby and Swift
competing directly?

Go or <insert JVM/CLR language that already directly competes with Ruby here>
would probably be better examples.

~~~
grandalf
Perhaps you are correct (though I'm curious which languages you'd nominate as
more likely contenders).

------
learc83
So much of what makes Ruby Ruby is based on dynamic types. Is this going to be
optional? I've been moving away from Ruby a bit over the years specifically
because I want static typing, but I can't imagine that the majority of Ruby
devs feel this way.

Also isn't Crystal basically a compiled, statically typed version of Ruby?

~~~
ryan-allen
I've been doing C# after years of Ruby, and every time I find myself needing
or wanting to do 'duck typing', what falls out is an interface and then using
generics.

After years of Ruby, this is so handy because you end up formalising 'on the
side' the commonalities of your modelling.

I had no idea what generics were for, and I thought interfaces were mostly for
over-abstraction but lo, I was wrong. They are very handy. They are typed duck
typing!

Combine that with type inference, and you've limited all the ugly 'everything
is typed' code, and what you get is code that looks a lot like Javascript.

And if you don't like, that, there's F#, that as an ex-Ruby guy, looks rather
compelling, but with all the benefits of C# as well.

I didn't realise until I was out of the echo chamber that Ruby is only a small
spot on the radar compared to the rest of the software world.

~~~
learc83
I completely agree with everything you wrote, that's been my experience as
well. I'm also a Ruby guy who's moving a lot of my projects over to .Net. F#
is actually what attracted me, but I'm really enjoying C# as well.

------
VeejayRampay
Another very interesting (and well-thought) article on the topic is Tony
Arcieri's latest blog post: [http://tonyarcieri.com/an-open-letter-to-matz-on-
ruby-type-s...](http://tonyarcieri.com/an-open-letter-to-matz-on-ruby-type-
systems).

I can't wait to see how this develops, the simple fact that people inside the
Ruby community are willing to put all this on the table is a good sign about
the dynamism of all involved.

------
ufo
Weird to see references to soft typing (something quite old that didn't quite
work out) and no references to the much more recent Diamondback Ruby:
[http://www.cs.umd.edu/projects/PL/druby/](http://www.cs.umd.edu/projects/PL/druby/)
It was a research project from the fine folks at the university of Maryland
but it lost steam because Ruby is so dynamic that its very very hard to write
static analysis tools for it.

[http://www.cs.purdue.edu/homes/jv/events/PBD13/slides/JeffFo...](http://www.cs.purdue.edu/homes/jv/events/PBD13/slides/JeffFoster.pdf)

There are some misconceptions about the the Soft Typing approach though that I
think I should clear out a bit:

* What a soft typing system does is use type inference techniques to try to figure out what locations in the program might raise dynamic type errors (accessing inexistent methods, etc).

* Soft typing systems do not check the types of function parameters and return values (since just passing a value around never cause the itnerpreter to throw an error). Some non-soft type systems might check though, adding runtime contract checks if needed.

* Soft typing can guarantee safety if you write your program in a way where the type checker manages to infer a static type for everything.

* On the other hand, writing things in a way that satisfies the type inferencer can be very hard. And to acomodate the flexibility of dynamic languages the type system might evolve into something quite complex. This is an even larger issue for Ruby, which is highly dynamic and has no formal spec.

* The 1991 soft typing paper focuses a lot on speed because back then dynamic type checks were a big reason for the slowness of dynamic language implementations. Nowadays we have tracing JITs (which "inline" away all the type checks, method dispatches, and so on) so there is less of a need to use type inference to speed things up.

------
rubyfan
Crystal seems to offer us a preview of what life might be like with a typed
Ruby. Types in Crystal are _mostly_ unobtrusive. Performance is nice too. I'm
really liking what I see. It's not yet mature and lacks a REPL still but
Crystal offers a serious Rubyesque option that I could see gaining some steam.

------
wpietri
That's really interesting to me.

One of the things I like about Ruby its pliability. It's what I'll turn to
when I'm just hacking something together, exploring a problem/solution space.
But that very pliability becomes an issue when I'm trying to write something
that's reliable. There, I'll often use something like Scala, which yells at me
when it detects fuzzy thinking on my part.

My general approach here is to throw a lot of code out when I try to shift
from exploration mode to high-reliability mode. I'd be very excited to see a
language that let me make that transition gradually.

~~~
tosh
In a few years from now we will expect this from every mainstream programming
language/platform.

Dart allows you to use gradual typing in production right now, PHP and Python
are in the process of adding support for it as well.

------
ddebernardy
I wish Ruby would focus in immutability before this.

As things stand, the language is built in a way that you've no guarantee that
any object you hold as variable won't change without you knowing. The net
result is you either ignoring the problem entirely (until you runinto a
bizarre bug introduced by a new library) or (more rarely) you re-inventing the
wheel by being extremely verbose in all accessors where it matter.

~~~
nitrogen
Ruby has the .freeze and .clone methods on many types, but in general Ruby
expects developers not to monkey with other objects without knowing the
consequences.

------
EugeneOZ
I'm not a ruby-dev, but glad to hear this news - as more web langs turns into
lands of static typing, more other (or new) langs will consider to do it too
:)

------
rurban
OP missed some more development on recent gradual typing efforts in dynamic
languages. I collected those links below when implementing gradual typing for
perl5. perl5 is more lucky than ruby, since perl5 supports syntax for types in
lexical variable declarations for decades already, and more via attributes.

[http://www.typescriptlang.org/Content/TypeScript%20Language%...](http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf)
(microsoft's javascript with types)

[https://code.facebook.com/posts/1505962329687926/flow-a-
new-...](https://code.facebook.com/posts/1505962329687926/flow-a-new-static-
type-checker-for-javascript/) (facebook's javascript with types)

[https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-...](https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-01/JSExperimentalDirections.pdf)
Soundscript, google's javascript with types

[https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/)
(planned python with types)

[http://www.mypy-lang.org/](http://www.mypy-lang.org/) (existing python with
types)

[https://news.ycombinator.com/item?id=8620129](https://news.ycombinator.com/item?id=8620129)
(ruby 3.0 planned with types)

[http://crystal-lang.org/](http://crystal-lang.org/) (a good existing ruby
with types)

[http://hacklang.org/](http://hacklang.org/) (facebook's php with types)

[http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-
typ...](http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-
hints.html) (php 7 types overview)

[https://wiki.php.net/rfc/scalar_type_hints](https://wiki.php.net/rfc/scalar_type_hints)
(php 7)

[https://wiki.php.net/rfc/return_types](https://wiki.php.net/rfc/return_types)
(php 7)

[https://github.com/rurban/perl/blob/master/pod/perltypes.pod](https://github.com/rurban/perl/blob/master/pod/perltypes.pod)
(perl5 inofficial)

~~~
tosh
On Dart's type system:

[https://www.dartlang.org/articles/optional-
types/](https://www.dartlang.org/articles/optional-types/)

[https://www.dartlang.org/articles/why-dart-
types/](https://www.dartlang.org/articles/why-dart-types/)

~~~
EugeneOZ
Dart has dynamic typing. Code will not fail on compilation step and in
runtime, if type mismatch expectations. You can try to get warnings (at least
warnings) with "checked" mode, but it works only with primitive cases, not
with closures (no static analysis), so it's mostly useless and better to
forget about it. It's only hinting for autocompletion in IDE (although
autocompletion is a big thing). Even PHP 5 has strongest typing.

~~~
skybrian
Dart has static analysis as well. There is a server that reports errors and
warnings in an IDE, and you can also run it as a batch job using the
dartanalyzer command if you like. You can run dartanalyzer in a test, parse
the output, and treat warnings as errors, and some people do.

The question is whether the existing static analysis is enough. Some people
think it isn't, and the Dart team has a couple of projects to improve on it.
See the Dart Development Compiler [1] and linter [2].

The DDC project in particular plans to implement a subset of Dart that makes
it easier to check types statically.

This is all supposed to be integrated into the analysis engine using a plugin
architecture so that these errors will show up in IDE's and anywhere else you
want to display errors.

It's work in progress, as are some of the other type checkers.

[1] [https://github.com/dart-lang/dev_compiler](https://github.com/dart-
lang/dev_compiler) [2] [https://github.com/dart-
lang/linter](https://github.com/dart-lang/linter)

~~~
EugeneOZ
I have quite opposite information from one of Dart authors, as response to my
bug report:
[https://code.google.com/p/dart/issues/detail?id=23148](https://code.google.com/p/dart/issues/detail?id=23148)
Sorry for offtopic, ruby devs :)

~~~
skybrian
It's confusing, but that's not a contradiction. The Dart spec defines the
official set of errors and warnings and that particular snippet of code is
within the spec, even though it's broken. The dartanalyzer tool follows the
spec.

But there are other possibilities. The dartanalyzer has hints which aren't
part of the spec. Other tools (like the linter and DDC) can and will check for
more problems.

You could try refiling that as a feature request that the analyzer should
provide a hint here, or perhaps try out DDC.

------
Too
I find it interesting that almost all dynamic programming languages eventually
get some kind of static type system or type annotations, but very rarely the
other way around, C# is the only one i can think of, although i've never seen
anyone actually use the dynamic keyword there. PHP, Perl, Python, JS(via
typescript or other preprocessors) all got it after years of arguing.

~~~
Psyonic
Scala has a Dynamic type that is used occasionally.

[http://www.scala-lang.org/api/current/scala/Dynamic.html](http://www.scala-
lang.org/api/current/scala/Dynamic.html)

------
angersock
Half the fun of Ruby is monkey-patching...how does that play with static
typing?

If they go this route, I'm sure we'll see some very interesting spins on it.

