| I was a full-time Rubyist for a long time. I started the UK's first dedicated Ruby on Rails consultancy in 2006 before Rails was even v1.0 (IIRC the first apps I shipped back then were 0.8.6). I stuck around through the hype chain, and then started to help one employer break up a RoR monolith into micro services and adopt Java and Go (this was a mistake - we should have crafted the monolith better). I've built 4 startups as hands-on CTO with Ruby and Rails. It fed and housed me for many years. In the last 5-7 years I've had to go in other directions. Clojure, Python, Java, even back to C and taking a look at Rust and Zig. I'm now in a role where I don't code so much, but I can see Ruby's problems - performance, the surprises, the fact it allows idiots to do idiotic things (nobody under the age of 40 should be legally allowed to monkey patch a base class or engage in meta programming). And yet when I want to do something for me, for fun, perhaps advent of code, or a quick mock-up of something that's rolling around in my head, I reach for Ruby. Not elixir which has better runtimes, or C or Zig or Rust which has better performance, not something statically typed which leads to fewer bugs, not Python which has a huge data science community to it... A few weeks ago I was listening to the DHH episode of the Lex Fridman podcast [0], where DHH talks about Ruby as a "luxury programming language". This matches my own experience. When I need something to be fast, it's either because I'm dealing with a low-latency problem (and some of my side projects are very latency sensitive - 5ms can make the difference between success and failure), or because I can't afford the luxury of Ruby and Rails and the developer ergonomics. Ruby makes things fun for the programmer. That's the point. It's beautiful to work with, even if it doesn't do all the things that all the coding books and blogs insist I should be ashamed to not have in my language. I was slightly embarrassed to be a Ruby and RoR advocate for a while because of the brogrammer BS that emerged around both ecosystems in the 2010s. I then became very embarrassed because it wasn't as cool as a systems language like Rust or Go, or as intellectually deep as Haskell, or as hot on the ML bandwagon as Python. But I think I don't care anymore. I'm just going to accept it for what it is, and lean into. Life's too short for "shoulds" - I'm just going to like what I like. And I like Ruby. [0] https://www.youtube.com/watch?v=vagyIcmIGOQ |
Languages like C#, Java, C++, Scala, Kotlin, and Python in 2025 feel like industrial computerized bandsaws with twenty different settings and controls. Some more complicated than others. They can be tuned to crank out a factories needs but you could spend days just fussing with a single setting that isn't right.
That being said, modern Python to me feels like the least thought out of these. It has been incrementally changed from one language to another, while being forced to keep many of the worst parts of both. To be honest, I think they should keep up the "breaking backwards compatibility" trend and make Python 4 an optionally-compiled, statically-typed language more like Go, but with more expressivity than Go.
I suppose F# is already like my ideal Python 4. It's possible to run as a script or compiled binary. It's a nice clean syntax, and the type system is a joy to use.
A valid F# program can be a single line script or dozens of configuration files. This let's the developer use it for quick and dirty work, then progressively tweak settings to run in a more industrial scale setting.