If you can find anyone willing to port Rails to a statically typed subset that requires adding type annotations and also porting every single gem it depends on....
Well that is a starting point.
It would be even harder without it so better having it that not.
Also do you have any alternatives?
Maybe for a start, making a statically typed Sinatra rather than Rails would be a more affordable task.
But anyway I'm not sure this is the right direction for Ruby as I think that more radical and different changes are needed to extract the full potential out of it.
Anyway if Infrared proves to be a nice and quick alternative solution that will let us gain back some lost terrain in those situations where Ruby was discarded because of performance, then I more then welcome it, hoping that a some point the efforts put in it will somehow also be useful to Ruby MRI (or whatever the Ruby reference implementation will be at that time) improvement..
> in those situations where Ruby was discarded because of performance
In most cases where Ruby gets discarded because of performance, it's a red herring. Most of Ruby's main uses are in areas where you can generally make things IO bound fairly easily.
For my part, I don't believe Ruby needs static typing to get far more performant. I'm working on a Ruby compiler, and while it's far from usable, from looking at MRI in particular it's worth noting that MRI implements pretty much nothing of the last 30 years or so of dynamic language optimizations.
Look towards JRuby today, and especially the Truffle backend, for indications of where Ruby optimizations can be going without sacrificing what makes the language attractive in the process.
That's not to say there aren't warts that makes it harder than necessary, but you can get very far with far less impact on the language than taking away dynamic typing.
It trades execution performance for developer performance. If you prefer faster execution and slower dev then another framework might be more appropriate.
Elixir(elixir-lang.org) and Phoenix(www.phoenixframework.org) seems to be coming along nicely. High speed and concurrency by building on the Erlang VM. Written by Rails Core developers who wanted more speed but, the spirit of Rails (though it's not a 1-to-1 port in the least)
"Statically-typed Ruby" that isn't actually Ruby, but a subset of Ruby[1] + mandatory type annotations. A rather misleading title.
E.g. here's an example [2], with stuff like this:
## java.lang.String -> void
def set_title(title)
@title_view.setText(title)
return
end
I kinda doubt this will take off with most Ruby users. Though being able to use something quite close to Ruby to write native Android apps is somewhat appealing even with extra pain (RubyMotion seems nicer to me, but the compiler only runs on OS X).
[1] "The runtime implements selected methods from core classes" [long list omitted]
Heh good luck get any of the Ruby "code" that community cares about like Rails to run on this - it is 99% magic, and DHH likes magik too much to want typing...
Rails has a lot of context which allows developers to rapidly specify what they want to happen in the context of web apps.
Rails is like asking someone to get milk, rails maps a route, obeys the laws of the road while getting there, pays for it, and returns with milk.
In other frameworks you explicitly have to tell it every little detail of how to get milk, usually culminating in the IMammalianFactoryMilkFactory pattern.
22 comments
[ 4.7 ms ] story [ 57.5 ms ] threadMaybe for a start, making a statically typed Sinatra rather than Rails would be a more affordable task.
But anyway I'm not sure this is the right direction for Ruby as I think that more radical and different changes are needed to extract the full potential out of it.
Anyway if Infrared proves to be a nice and quick alternative solution that will let us gain back some lost terrain in those situations where Ruby was discarded because of performance, then I more then welcome it, hoping that a some point the efforts put in it will somehow also be useful to Ruby MRI (or whatever the Ruby reference implementation will be at that time) improvement..
Yes: Not doing it.
> in those situations where Ruby was discarded because of performance
In most cases where Ruby gets discarded because of performance, it's a red herring. Most of Ruby's main uses are in areas where you can generally make things IO bound fairly easily.
For my part, I don't believe Ruby needs static typing to get far more performant. I'm working on a Ruby compiler, and while it's far from usable, from looking at MRI in particular it's worth noting that MRI implements pretty much nothing of the last 30 years or so of dynamic language optimizations.
Look towards JRuby today, and especially the Truffle backend, for indications of where Ruby optimizations can be going without sacrificing what makes the language attractive in the process.
That's not to say there aren't warts that makes it harder than necessary, but you can get very far with far less impact on the language than taking away dynamic typing.
It trades execution performance for developer performance. If you prefer faster execution and slower dev then another framework might be more appropriate.
http://webcache.googleusercontent.com/search?q=cache:7UYpJjG...
E.g. here's an example [2], with stuff like this:
I kinda doubt this will take off with most Ruby users. Though being able to use something quite close to Ruby to write native Android apps is somewhat appealing even with extra pain (RubyMotion seems nicer to me, but the compiler only runs on OS X).[1] "The runtime implements selected methods from core classes" [long list omitted]
[2] http://webcache.googleusercontent.com/search?q=cache:sUdn7y_...
Yes, "statically-typed Ruby" != "Ruby".
> but a subset of Ruby
Necessarily (because "statically-typed"). You can see the supported methods here: http://infraruby.com/reference
This is at least running on a JVM, which gives you a buttload of tooling.
Those problems do exist on all platforms and the tooling elsewhere is usually not as good.
How about any of the major GC languages?
How about the great debugger tooling Java has. Had that in ObjC? How about performance and threading related tooling? How about refactoring tooling?
To that purpose Ruboto is worth a mention too:
http://ruboto.org/
https://github.com/ruboto/ruboto
Tried to figure out what InfraRuby compiles to, but no avail. Is it to JVM?
[1] http://crystal-lang.org
[2] Very impressive result actually. It only performs ~3x slower on a basic Monte Carlo Tree Search compared to Nim, which itself is ~c speed.
You can use InfraRuby code with a Ruby interpreter: http://infraruby.com/blog/why-infraruby
> Tried to figure out what InfraRuby compiles to, but no avail.
Sorry, that should be made clearer...
> Is it to JVM?
Yes! ruby.Object extends java.lang.Object: http://infraruby.com/reference/Object
Rails has a lot of context which allows developers to rapidly specify what they want to happen in the context of web apps.
Rails is like asking someone to get milk, rails maps a route, obeys the laws of the road while getting there, pays for it, and returns with milk.
In other frameworks you explicitly have to tell it every little detail of how to get milk, usually culminating in the IMammalianFactoryMilkFactory pattern.