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