Consider Static Typing in Ruby | Hacker News Reader

Consider Static Typing in Ruby

codon.com

93 pointsmxhold35 comments

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.

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.

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.

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

> but if the price to pay is to start declaring types like I did in C and Java, no thanks

Modern type systems have such good inference that you won't need to declare types "everwhere."

I know, but I think it's difficult to make static type inference when you can build both the class and the method dynamically. Examples: object.send(expression) or Class.send(expression) are hard enough, building the value of Class at runtime adds extra complication, adding that method only to that object is further along the way of complication. And I'm probably only scratching the surface.

So, either Ruby 3 is so different from Ruby 2 in a way that Python 3 hasn't been from Python 2 or its static typing will be limited to some scenarios. If you do too much metaprogramming you give up using it. Something like using a subset of a language to get some bonus features (example: JS and ASM.js

If its a gradual type system, you can choose whether to use it or not in a specific situation. Because of that it simply becomes just another tool in your toolbox, unlike in languages such as Java where its more of a anchor and chain

From the article's introduction:

> That’s right: static typing! A lot of people were worried when they heard that, which is understandable; in the Ruby community we don’t get much exposure to static type systems, and they immediately make us think of languages like C and Java.

The author then proceeds to explain why static typing in ruby would be much better than "Java-flavoured-Ruby", and how it would "go beyond the features of the static type systems you’ve used in the past".

I know this is off topic, but I'm genuinely curious why people refer to themselves in such isolated bins like Rubyist and Pythonistas? Why do you refer to yourself in that way, instead of, say, a developer or programmer or software engineer?

Because it clearly states what the current area of work and experience is?

I would like to see optional static type checking. I don't even really care that much if the error is caught at runtime or not. I'd just like to be able to assert that certain functions always took or returned certain types, or that certain variables were always of a certain type.

I'm already winding up documenting these interfaces in YARD and testing this in spec tests. It'd be nice to just assert it in code as well.

I still like duck types to be able to write methods that take random objects and #to_s them or whatever without having to worry about declaring that they implement some Stringable interface -- but the more common case I'm running into is where parameters, variables and return types could really use strong typing to avoid errors.

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?

Not really -- with strong typing you can still use duck typing.

Swift has a cool approach to this.

Unless I read something wrong, the proposal was to add static typing not strong. Dynamic vs static, and strong vs weak are two different things, although the exact meaning of strong vs weak isn't really settled.

Many people already consider ruby to be pretty strongly typed. It's definitely already more strongly typed than javascript.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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%... (microsoft's javascript with types)

https://code.facebook.com/posts/1505962329687926/flow-a-new-... (facebook's javascript with types)

https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-... Soundscript, google's javascript with types

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

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

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

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

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

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

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

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

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

There's a great collection of gradual typing papers here:

https://github.com/samth/gradual-typing-bib

On Dart's type system:

https://www.dartlang.org/articles/optional-types/

https://www.dartlang.org/articles/why-dart-types/

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.

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 [2] https://github.com/dart-lang/linter

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 Sorry for offtopic, ruby devs :)

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.

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.

Haskell has dynamic types, too https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-D...

Scala has a Dynamic type that is used occasionally.

http://www.scala-lang.org/api/current/scala/Dynamic.html

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.

Reply on news.ycombinator.com