[clienthunter]

I think what you say about Rails is true. Rails isn't a framework, it's a lifestyle.

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.

[programminggeek]

I would love a compiled, statically typed Ruby, but I don't think the Ruby world wants it. I think Ruby is a fine tool in its current state.

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.

[clienthunter]

I've thought the same myself but reading that post made it clear to me that such thing couldn't really have much in common with what we call Ruby today.

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.

[programminggeek]

What I would really want from a language wouldn't have much in common with Ruby. It would look like ruby, but be mostly functional, compiled, with great support for immutable data structures, and named parameters. The closest I've found to this is Scala or Kotlin. I haven't had much time to dig deep into either though.

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.

[clienthunter]

Interesting you should choose Kotlin over Go. What's your take on it? I'm a big Jetbrains fanboy but haven't played with Kotlin yet.

[programminggeek]

I've played with Go and I like it well enough, but it doesn't offer anything interesting in the way of immutability. In fact, it doesn't so much offer it at all from what I've seen. Also, I'd like whatever language I land in to support named parameters.

[sheff]

One of the great things about Ruby at the moment is the number of Ruby implementations around, including several Ruby like languages which attempt to do things slightly differently.

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)

[infraruby]

> I would love a compiled, statically typed Ruby

http://infraruby.com/ is a compiled, statically typed subset of Ruby, compatible with Ruby interpreters.

[clienthunter]

Is this actually type safe, or type safe up until you include an untyped gem and the whole thing becomes indeterminate? Does the typing actually improve performance over straight jRuby?

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.

[infraruby]

> Is this actually type safe

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

[sethboyles]

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.