6 ms·

Matz at RubyConf 2014: Will Ruby 3.0 Be Statically Typed?

40 points by timr 12y ago

AnimalMuppet 12y ago
The idea that a type is defined by a set of methods sounds almost exactly like Go...
- robertknight 12y ago
  The more general name for this approach is structural typing - http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system
- blktiger 12y ago
  Except in Go don't you have to define the set of methods in interfaces? In Matz's system the interfaces would be discovered by the interpreter at run-time.
  - AnimalMuppet 12y ago
    If I understand correctly, yes, in Go you have to define the methods that make up the interface.
  - jabbrwcky 12y ago
    In Go you define the methods in interfaces but implementors do not have to specify that they implement a given interface. Instead any object (though Go has no real objects) is considered to be an implementation of an interface iff it implements all define methods.
- deleted 12y ago
  [deleted]
barendt 12y ago
Really minor nitpick - I think Matz claimed that about 30% of his prior RubyConf predictions were false, so about 70% of his prior RubyConf ideas eventually did make it to production.
- TheRubyist 12y ago
  From 3 features he presented (Concurency, JIT, Soft Typing) I would put 5 $ on JIT, rest is pretty much against his philosophy.
Paddy3118 12y ago
There seems to me to be an overlap between Matz's typng ideas and some of the "static" typing generated by Julia: https://www.youtube.com/watch?v=jhlVHoeB05A https://www.youtube.com/watch?v=jhlVHoeB05A https://www.youtube.com/watch?v=VCp1jUgVRgE https://www.youtube.com/watch?v=VCp1jUgVRgE
emmanueloga_ 12y ago
If you want to see how an statically typed ruby would look like, you should check crystal-lang out. The compiler is bootstrapped so crystal itself is the first big (medium?) size application running crystal :) [1]. The authors may correct me, but I'm pretty sure the project objective in the beginning was to compile ruby to native code. As the project progressed, it was clear it wouldn't be possible without some syntax changes (like type annotations). The changes pile up until it no longer made sense to call the resulting language "ruby" anymore. 1: http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.html http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.ht...
- asterite 12y ago
  Yes, exactly. At first we wanted Ruby, but compiled. We started with something that was very, very similar to Ruby (except some dynamic aspects) but the type inference algorithm was very slow. So we made some sacrifices (like telling the compiler the types of Arrays and Hashes) and that made the compiler very fast. But at that point we diverged from Ruby because the syntax was starting to be different at places. Then because of how we deal with Nil we changed some of Ruby's semantics (like, Array#[] raises when out of bounds), so we can't say Crystal is a compiled Ruby: it's a totally different language. It just happens to have a pretty similar syntax and API to that of Ruby :-)
  - emmanueloga_ 12y ago
    Could you comment a bit how the approach you took on Crystal differs from what's described in the OP? (... “Soft Typing” [1], introduced by Mike Fagan in his 1991 dissertation ...) 1: http://scholarship.rice.edu/handle/1911/16439 http://scholarship.rice.edu/handle/1911/16439
    - asterite 12y ago
      It's hard to say, the paper is really long and it's full of mathematical notation that is hard to digest and there are no examples to make it easier. Or, if they are, they are for a symbolic lambda calculus program. The problem with this kind of papers is that they are for a hypothetic programming language based on lambda calculus. In Ruby we have objects, instance variables and blocks. We have inheritance and modules. It's hard to make a 1-1 mapping between the paper and the real language. This is why Matz said (if I remember correctly) that the algorithm would need to be adapted to an object oriented language like Ruby (so you can imagine, the paper doesn't even deal with objects, probably just functions!). Before developing Crystal we read some papers, but all of them were pretty limited (they only dealt with primitive types like int and float). We had to think of a new algorithm that adapted well to all of the language features. And the algorithm is very specific to the language, which is something good because we can make it optimal, instead of for a general language. It's hard to describe the algorithm in detail. We'll eventually do so in blog posts.
ksec 12y ago
From https://news.ycombinator.com/item?id=8621913 https://news.ycombinator.com/item?id=8621913 Deoptimizing Ruby A decent JIT should brings at anywhere from 4 - 20x speedup. Why is it Matz was only seeing possible 3-4x difference?
- chrisseaton 12y ago
  Because doing what we do (I did the deopt presentation) requires the whole VM and runtime to be written with a very different architecture compared to what is currently in MRI. Matz wants to add a JIT, not rewrite MRI entirely. I think setting a modest goal was a really intelligent decision by Matz. He wants a good-enough JIT, not the best JIT in the world.
shawn42 12y ago
Supporting some sort of JIT in Ruby is a long time coming. Glad to hear it! I wonder how this "soft typing" would affect things like method_missing magic and the like. Would it be an optional runtime option to enforce the implicit interface?
- timonovici 12y ago
  But doesn't Rubinius already have a JIT? Why wait for MRI v3?
pmontra 12y ago
As a developer who makes money with Ruby (not exclusively) I'd say: 1) I'm happy with Ruby as it is now and I don't want to see type annotations in method definitions. If I ever need static typing I can pick one of the zillion languages that have static types right now. I believe that I'll be served better than with a language that got them as an afterthought. I still remember C (without ++) and Java. 2) JRuby does JIT and it's not particularly faster than MRI. After all even the JVM must resolve method calls at every method invocation instead of getting them resolved at compile/link time. Rubinius tries to do some magic there but it's still in line with MRI performances (a little slower actually). Based on the benchmarks I saw for JRuby vs MRI I'd say that only long running programs will get sped up, but after all who cares about interactive programs completing in 1 or in 0.01 s? Development time is definitely more important there. However I trust Matz on that speedup factor and any 0.00x% of speed if welcome.

40 points by timr 12y ago

AnimalMuppet 12y ago

The idea that a type is defined by a set of methods sounds almost exactly like Go...

robertknight 12y ago
The more general name for this approach is structural typing - http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system
blktiger 12y ago
Except in Go don't you have to define the set of methods in interfaces? In Matz's system the interfaces would be discovered by the interpreter at run-time.
- AnimalMuppet 12y ago
  If I understand correctly, yes, in Go you have to define the methods that make up the interface.
- jabbrwcky 12y ago
  In Go you define the methods in interfaces but implementors do not have to specify that they implement a given interface. Instead any object (though Go has no real objects) is considered to be an implementation of an interface iff it implements all define methods.
deleted 12y ago
[deleted]

barendt 12y ago

Really minor nitpick - I think Matz claimed that about 30% of his prior RubyConf predictions were false, so about 70% of his prior RubyConf ideas eventually did make it to production.

TheRubyist 12y ago
From 3 features he presented (Concurency, JIT, Soft Typing) I would put 5 $ on JIT, rest is pretty much against his philosophy.

Paddy3118 12y ago

There seems to me to be an overlap between Matz's typng ideas and some of the "static" typing generated by Julia: https://www.youtube.com/watch?v=jhlVHoeB05A https://www.youtube.com/watch?v=jhlVHoeB05A https://www.youtube.com/watch?v=VCp1jUgVRgE https://www.youtube.com/watch?v=VCp1jUgVRgE

emmanueloga_ 12y ago

If you want to see how an statically typed ruby would look like, you should check crystal-lang out. The compiler is bootstrapped so crystal itself is the first big (medium?) size application running crystal :) [1]. The authors may correct me, but I'm pretty sure the project objective in the beginning was to compile ruby to native code. As the project progressed, it was clear it wouldn't be possible without some syntax changes (like type annotations). The changes pile up until it no longer made sense to call the resulting language "ruby" anymore. 1: http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.html http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.ht...

asterite 12y ago
Yes, exactly. At first we wanted Ruby, but compiled. We started with something that was very, very similar to Ruby (except some dynamic aspects) but the type inference algorithm was very slow. So we made some sacrifices (like telling the compiler the types of Arrays and Hashes) and that made the compiler very fast. But at that point we diverged from Ruby because the syntax was starting to be different at places. Then because of how we deal with Nil we changed some of Ruby's semantics (like, Array#[] raises when out of bounds), so we can't say Crystal is a compiled Ruby: it's a totally different language. It just happens to have a pretty similar syntax and API to that of Ruby :-)
- emmanueloga_ 12y ago
  Could you comment a bit how the approach you took on Crystal differs from what's described in the OP? (... “Soft Typing” [1], introduced by Mike Fagan in his 1991 dissertation ...) 1: http://scholarship.rice.edu/handle/1911/16439 http://scholarship.rice.edu/handle/1911/16439
  - asterite 12y ago
    It's hard to say, the paper is really long and it's full of mathematical notation that is hard to digest and there are no examples to make it easier. Or, if they are, they are for a symbolic lambda calculus program. The problem with this kind of papers is that they are for a hypothetic programming language based on lambda calculus. In Ruby we have objects, instance variables and blocks. We have inheritance and modules. It's hard to make a 1-1 mapping between the paper and the real language. This is why Matz said (if I remember correctly) that the algorithm would need to be adapted to an object oriented language like Ruby (so you can imagine, the paper doesn't even deal with objects, probably just functions!). Before developing Crystal we read some papers, but all of them were pretty limited (they only dealt with primitive types like int and float). We had to think of a new algorithm that adapted well to all of the language features. And the algorithm is very specific to the language, which is something good because we can make it optimal, instead of for a general language. It's hard to describe the algorithm in detail. We'll eventually do so in blog posts.

ksec 12y ago

From https://news.ycombinator.com/item?id=8621913 https://news.ycombinator.com/item?id=8621913 Deoptimizing Ruby A decent JIT should brings at anywhere from 4 - 20x speedup. Why is it Matz was only seeing possible 3-4x difference?

chrisseaton 12y ago
Because doing what we do (I did the deopt presentation) requires the whole VM and runtime to be written with a very different architecture compared to what is currently in MRI. Matz wants to add a JIT, not rewrite MRI entirely. I think setting a modest goal was a really intelligent decision by Matz. He wants a good-enough JIT, not the best JIT in the world.

shawn42 12y ago

Supporting some sort of JIT in Ruby is a long time coming. Glad to hear it! I wonder how this "soft typing" would affect things like method_missing magic and the like. Would it be an optional runtime option to enforce the implicit interface?

timonovici 12y ago
But doesn't Rubinius already have a JIT? Why wait for MRI v3?

pmontra 12y ago

As a developer who makes money with Ruby (not exclusively) I'd say: 1) I'm happy with Ruby as it is now and I don't want to see type annotations in method definitions. If I ever need static typing I can pick one of the zillion languages that have static types right now. I believe that I'll be served better than with a language that got them as an afterthought. I still remember C (without ++) and Java. 2) JRuby does JIT and it's not particularly faster than MRI. After all even the JVM must resolve method calls at every method invocation instead of getting them resolved at compile/link time. Rubinius tries to do some magic there but it's still in line with MRI performances (a little slower actually). Based on the benchmarks I saw for JRuby vs MRI I'd say that only long running programs will get sped up, but after all who cares about interactive programs completing in 1 or in 0.01 s? Development time is definitely more important there. However I trust Matz on that speedup factor and any 0.00x% of speed if welcome.