I think there is a need for a different language that makes clean architecture natural, well accepted, normal thing. Ruby is great, but trying to change the community and language doesn't seem to be the right approach.
The solution for the performant/distributed/concurrent/data-intensive problems of today and the future seems, to me, to be in the functional space. I know it's trendy to say that but it's the smart people - Rich Hickey, Simon Peyton Jones, etc - who are driving this evolution. A language with a GIL and zero immutable primitives just doesn't seem to have much to contribute. The idea that Twitter was at scale as a Rails app once upon a time is just absurd to me now.
Incidentally I creeped on your bio and saw you created obvious. I read about Obvious a while back and, although I must admit I haven't used it directly, it really had a strong influence on how I think about structuring Rails applications.
I'm glad Obvious influenced you, but I'm not surprised you didn't use it directly. To be completely honest a lot of what I built in the obvious gem, other languages give you just as language feature. For example comparing similar entity and contract structures in Ruby/Obvious, Mirah, and Scala: https://gist.github.com/brianknapp/6178930 I made Obvious work in Ruby because Ruby provided a great platform for figuring out how to make this work well. However, most Ruby devs either don't get it or don't like it because it's not very Ruby or very Rails.
The best Rails code I've ever written is basically using ActiveRecord to pull in a big data tree from the database and then using that to populate and do calculations on a bunch of immutable data structures using Hamsterdam::Struct. The code is really clean and beautiful and very easy to test. The final computed data structure is then used to populate an immutable presenter that helps generate the view. It is very much in the vein of a functional core and mutable shell concept that Gary Bernhardt advocates. My Obvious apps tend to follow a similar pattern, tho I haven't updated the Obvious site to mention functional core and mutable shell, but the code's kind of always been that way.
You can write great code in Ruby and Rails, but to me it's always going to feel more like a prototyping tool than something that will feel great to maintain for long periods of time.
Crystal is one language with Ruby like syntax and the goal of compiling to efficient native code. ( http://crystal-lang.org )
Mirah is another statically typed Ruby like JVM based language, although its development is a bit slow. (http://www.mirah.org)
http://infraruby.com/ is a compiled, statically typed subset of Ruby, compatible with Ruby interpreters.
Can it handle method_missing and *_eval?
Also why is it closed source?
edit: sorry I didn't mean to sound aggressive. please interpret the stream of questions as extreme curiosity.
The type system is roughly the same as in Java, and, as in Java, there are ways around the type system.
> or type safe up until you include an untyped gem and the whole thing becomes indeterminate?
The compiler requires type annotations; you can't include an untyped gem! InfraRuby syntax is compatible with Ruby interpreters, so you can still use your code while you write type annotations for it.
> Does the typing actually improve performance over straight jRuby?
Yes. The compiler is written in Ruby, and uses JRuby to bootstrap. The performance of the compiled compiler compiling the compiler is about 7x JRuby.
> Can it handle method_missing and *_eval?
No. The subset of Ruby supported by InfraRuby excludes metaprogramming and reflection.
> Also why is it closed source?
Because 1. give away your work 2. ??? 3. profit! is not compelling :-p
I also started to question whether Ruby's type system was just too loose for serious work and was yearning for something as pleasant as Ruby but with at least some type safety. Then yesterday I read this relatively old post https://www.ruby-forum.com/topic/217617 about adding static typing to Ruby. There's a lot of recognisable names in the thread, but the posts from Eleanor McHugh nearer the bottom really helped me understand the power and utility behind the apparent simplicity.