Back when autocompletion and stuff were only available in Visual Studio/Xcode/Other bug IDEs, I was forced to use Ruby and fell in love with it. It didn't matter what I used as my editor was Sublime. But when VSCode came and language features became democratized, I never touched a type-less language again. Why should someone opt for a language with absolutely no features where one can have autocompletion, typechecking, deep data type exploration, jumping to definitions and implementations? I really think it's a bad choice of Ruby not to care for types. And well we now have Crystal which again makes me question why Ruby? And it’s a shame no language is as beautiful as Ruby, not in features choices, design elegance, balance, beauty of the syntax, joy of programming mindset, not even in the name and logo. I wished Matz rethinked this part.
zarzavat · 9m ago
This was always true, to be honest. Statically typed languages have always been better. Free IDEs such as Eclipse have been available for a long time. Good JVM languages such as Scala have been available for a long time.
If only the Ruby ecosystem had adopted Scala instead of Ruby, with cutesy books and eccentric underscored personalities, history might have been different.
javaunsafe2019 · 31m ago
Fully agree. Had to work in the past with ruby. Loved it but type errors during runtime where a thing and therefore I would never use ruby in production again.
I use kotlin nowadays…
manuelfcreis · 1h ago
I fully agree to the points here, even as a full time ruby lover. Jumping around different languages over the past 10 years really shows staleness in Ruby as a language, even if the ecosystem tries to keep up.
The ergonomics of ruby still have me very much liking the language as it fits how I think, but there are a lot of good developments in the usual neighbors, and I see myself picking up both Python and JS ever more for small projects.
khoury · 34m ago
Ruby fully typed would be awesome imo, but I know that goes against a lot of the fundamentals in the language. I just like the syntax and expressiveness of it, but coming from typescript, its just such a bad DX having to work in a large Ruby codebase.
melvinroest · 1h ago
This post reminds me of something.
During my first Introduction to Programming course at university, I was taught Java. One thing that I found very troubling is that it wasn't easy, or possible in many cases, to change the programming language. Sure, you can write new functions or methods or classes, but I can't change the keyword for an if-statement. I also remember the TA saying "why would you want that?" I caught myself thinking "if we can program a computer, then why can't we program a language?"
15 years later, I still have this issue a bit, except I made my peace with it. It is what it is. There are some exceptions though! Such as: Lisp, Smalltalk and similar languages. It's in part why I have worked for a company that professionally programmed in Pharo (a Smalltalk descendant [2]). I remember hacking a very crude way for runtime type checking in Pharo [1], just for fun.
I'm not a Ruby programmer, all I know is that Ruby has some things that are identical to Smalltalk. But my question to the author would be: if you long for things like keyword arguments, type hints and namespaces why don't you program it in the Ruby language yourself?
Or is that really hard, like most other languages?
[2] Fun fact, I learned about Lisp, Smalltalk and Pharo through HN! So I know most of you know but I suspect some don't.
lmm · 1h ago
The language is the easy part. Getting tool support for your language change is the hard part. Getting the library ecosystem to adopt it is even harder.
I think that's why extremely flexible languages have seen limited adoption - if your language is more of a language construction kit where everyone can implement their own functionality, everyone has to implement their own tool support (or, more likely, live without any) and there's a limit to how far you can go with that. The best languages find the sweet spot where they give you enough flexibility to implement most reasonable programs, but are still constrained enough that tools can understand and work with all possible code.
dale_glass · 1h ago
Too much change isn't good though. There's value in consistent basics. I've seen people doing things like:
#define BEGIN {
#define END }
because they liked Pascal, and that way lies madness.
zelphirkalt · 1h ago
Lets not equate silly and possibly dysfunctional string substitution macros with macros in higher level languages, which let you inspect and act according to the structure of the AST.
Ygg2 · 21m ago
> that way lies madness.
Flashbacks to scala operator PTSD.
No. I don't want to use ++<>^^%% operator! I am not a number! I'm a man!
zelphirkalt · 1h ago
> I also remember the TA saying "why would you want that?"
Is a typical response of someone without the background and without the imagination. It may well be, that doing Java-only for too long robs one of both. An alternative response could have been: "What a fascinating idea! How would you apply that? / What would you do with that?"
I am happy for you, that you found the exceptions and that your picture of the computer programming world is not as incomplete and bleak as that of the TA back then.
sfn42 · 25m ago
So your suggestion to the TA is to ask literally the exact same question but slightly different?
brainzap · 18m ago
I feel the samw, happy that Python is improving and getting more good tooling
IshKebab · 16m ago
Yeah Python with uv and Pyright is downright tolerable. As long as you don't care at all about performance anyway (and can guarantee that you never will in future).
sushibowl · 58m ago
I'm sort of the inverse of this author: I have always liked Python and disliked Ruby. It's true though that python has changed a lot, and it's a mixed bag IMHO. I think every language feature python has added can have a reasonable argument made for its existence, however collectively it kind of makes the language burgeon under the weight of its own complexity. "one way to do it" really hasn't been a hard goal for the language for a while.
I'm really charmed by ML style languages nowadays. I think python has built a lot of kludges to compensate for the fact that functions, assignments, loops, and conditionals are not expressions. You get comprehensions, lambdas, conditional expressions, the walrus operator... most statements have an expression equivalent now.
it seems like, initially, Guido was of the opinion that in most cases you should just write the statement and not try "to cram everything in-line," so to speak. However it can't be denied that there are cases where the in-line version just looks nice. On the other hand now you have a statement and an expression that is slightly different syntactically but equivalent semantically, and you have to learn both. Rust avoids this nicely by just making everything an expression, but you do get some semicolon-related awkwardness as a result.
zelphirkalt · 39m ago
I feel similar about "weight" in Python. Some people can really overdo it with the type annotations, wanting to annotate every little variable inside any procedure, even if as a human it is quite easy to infer its type and for the type checker the type is already clear. It adds so much clutter and at the end of the day I think: "Why aren't you just writing Java instead?" and that's probably where that notion originates from.
I used to be like that. When I did Java. I used to think to myself: "Oh neat! Everything has its place. interfaces, abstract classes, classes, methods, anonymous classes, ... everything fits neatly together."
That was before I learned more Python and realized: "Hey wait a moment, things that require me to write elaborate classes in Java are just a little bit of syntax in Python. For example decorators!" And slowly switched to Python.
Now it seems many Java-ers have come to Python, but without changing their mindset. Collectively they make it harder to enjoy using Python, because at workspaces they will mandate the most extreme views towards type annotations, turning Python into a Java dialect in some regards. But without the speed of Java. I have had feedback for a take-home assignment from an application process, where someone in all seriousness complained about me not using type annotations for what amounted to a single page of code(, and for using explanatory comments, when I was not given any guarantees of being able to talk with someone about the code - lol, the audacity).
Part of the problem is how people learn programming. Many people learn it at university, by using Java, and now think everything must work like Java. I mean, Java is honest about types, but it can also be annoying. Has gotten better though. But that message has not arrived yet at what I call the "Java-er mindset" when it comes to writing type annotations. In general languages or their type checkers have become quite good at inferring types.
wewewedxfgdf · 53m ago
It's the never ending "end"s that bother me about Ruby.
class Mess
def chaos(x)
if x > 0
[1,2,3].each do |i|
case i
when 1
if i.odd?
puts "odd"
else
puts "even"
end
when 2
begin
puts "trying"
rescue
puts "failed"
end
else
puts "other"
end
end
else
puts "negative"
end
end
end
Clear away all those ends and the program logic pops out. Much fresher!
class Mess:
def chaos(self, x):
if x > 0:
for i in [1, 2, 3]:
match i:
case 1:
if i % 2 == 1:
print("odd")
else:
print("even")
case 2:
try:
print("trying")
except:
print("failed")
case _:
print("other")
else:
print("negative")
Alifatisk · 11m ago
The indent in your Ruby code is a bit weird
class Mess
def chaos(x)
if x > 0
[1, 2, 3].each do |i|
case i
when 1
if i.odd?
puts "odd"
else
puts "even"
end
when 2
begin
puts "trying"
rescue
puts "failed"
end
else
puts "other"
end
end
else
puts "negative"
end
end
end
I would have done it this way instead
class Mess
def chaos(x)
if x > 0
[1, 2, 3].each do |i|
case i
when 1
puts i.odd? ? "odd" : "even"
when 2
puts "trying"
else
puts "other"
end
end
else
puts "negative"
end
end
end
Or if you allow me to create a separate private method
class Mess
def chaos(x)
return puts "negative" unless x > 0
[1, 2, 3].each { |i| handle_item(i) }
end
private
def handle_item(i)
case i
when 1 then puts(i.odd? ? "odd" : "even")
when 2 then puts "trying"
else puts "other"
end
end
end
PaulRobinson · 45m ago
I mean, that's a horrific piece of Ruby that doesn't do much, and you've not indented it properly.
Of course you can get all this down to a single line with ; demarcation.
And your `.each` could use `{ ... }` syntax, just like C or Java or... you know, everything else.
But sure, whitespace is better, or whatever it is you prefer.
schappim · 40m ago
What looks like stagnation to Steen is actually [1] Matz’s remarkable foresight that provided stability and developer happiness.
Steen’s not wrong that Python evolved and Ruby moved slower, but he’s wrong to call Ruby stagnant or irrelevant. Just think what we've enjoyed in recent times: YJIT and MJIT massively improved runtime performance, ractors, the various type system efforts (RBS/Sorbet etc) that give gradual typing without cluttering the language etc.
Ruby’s priorities (ergonomics, DSLs, stability) are different[2] from Python’s (standardisation, academia/data). It’s a matter of taste and domain, not superiority.
Likes Lisp Ruby and Typescript, interesting tastes (in a good way... nuanced)
dudeinjapan · 1h ago
I still like Ruby. 15+ years in, I find myself in the camp of not wanting it to change. 25 year old me would have been totally jazzed about the addition of namespaces in Ruby 3.5/4.0. 40 year old me wants namespaces to get off my Ruby lawn.
zelphirkalt · 37m ago
Doesn't Ruby essentially already have namespaces, in terms of having modules? If one has proper modules, why would one ever need an alternative, weaker, concept for referring to things?
Manfred · 26m ago
To make sure code loaded from gems doesn’t shadow the namespace of the application.
dudeinjapan · 9s ago
Right. Today Ruby has essentially a global namespace, where every defined module/class/const is put in the same "global dumping ground" and can override/"monkey patch" each other.
Ruby 3.5 will introduce a new language keyword "namespace"
```
class Foo
def foo; puts "foo"; end
end
namespace Bar
class Foo
def foo; puts "bar"; end
end
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.
I've been on a similar journey. I was deep into rails early in my career. Then I moved on, especially liking typescript. I thought I wouldn't go back. But you don't always get the choice, a great job came up and it was a rails app. I found joy in it again - and I'm still there nearly 10 years on. Ruby feels like how OOP should be, it's so very easy to implement patterns that other languages make verbose and horrible. I'm guilty of a lot of metaprogramming, hope you forgive me, I am over 40. I think it can be an undervalued super power of the language: something isn't working or you need deeper insight, just break into the innards of any library you're using and insert logging and/or your own code.
Anyway, that said, for new personal projects I like typescript and rust. But recently I needed to stick an admin interface on such a project and rails shines there, you can get something good and secure stood up with less code and faff than anything else. In today's world of LLMs that is helpful too, rails is concise and old and has lots of open source projects to pull from, so AI breezes through it.
If only the Ruby ecosystem had adopted Scala instead of Ruby, with cutesy books and eccentric underscored personalities, history might have been different.
I use kotlin nowadays…
The ergonomics of ruby still have me very much liking the language as it fits how I think, but there are a lot of good developments in the usual neighbors, and I see myself picking up both Python and JS ever more for small projects.
During my first Introduction to Programming course at university, I was taught Java. One thing that I found very troubling is that it wasn't easy, or possible in many cases, to change the programming language. Sure, you can write new functions or methods or classes, but I can't change the keyword for an if-statement. I also remember the TA saying "why would you want that?" I caught myself thinking "if we can program a computer, then why can't we program a language?"
15 years later, I still have this issue a bit, except I made my peace with it. It is what it is. There are some exceptions though! Such as: Lisp, Smalltalk and similar languages. It's in part why I have worked for a company that professionally programmed in Pharo (a Smalltalk descendant [2]). I remember hacking a very crude way for runtime type checking in Pharo [1], just for fun.
I'm not a Ruby programmer, all I know is that Ruby has some things that are identical to Smalltalk. But my question to the author would be: if you long for things like keyword arguments, type hints and namespaces why don't you program it in the Ruby language yourself?
Or is that really hard, like most other languages?
[1] https://youtu.be/FeFrt-kdvms?si=vlFPIkGuVceztVuW&t=2678
[2] Fun fact, I learned about Lisp, Smalltalk and Pharo through HN! So I know most of you know but I suspect some don't.
I think that's why extremely flexible languages have seen limited adoption - if your language is more of a language construction kit where everyone can implement their own functionality, everyone has to implement their own tool support (or, more likely, live without any) and there's a limit to how far you can go with that. The best languages find the sweet spot where they give you enough flexibility to implement most reasonable programs, but are still constrained enough that tools can understand and work with all possible code.
Flashbacks to scala operator PTSD.
No. I don't want to use ++<>^^%% operator! I am not a number! I'm a man!
Is a typical response of someone without the background and without the imagination. It may well be, that doing Java-only for too long robs one of both. An alternative response could have been: "What a fascinating idea! How would you apply that? / What would you do with that?"
I am happy for you, that you found the exceptions and that your picture of the computer programming world is not as incomplete and bleak as that of the TA back then.
I'm really charmed by ML style languages nowadays. I think python has built a lot of kludges to compensate for the fact that functions, assignments, loops, and conditionals are not expressions. You get comprehensions, lambdas, conditional expressions, the walrus operator... most statements have an expression equivalent now.
it seems like, initially, Guido was of the opinion that in most cases you should just write the statement and not try "to cram everything in-line," so to speak. However it can't be denied that there are cases where the in-line version just looks nice. On the other hand now you have a statement and an expression that is slightly different syntactically but equivalent semantically, and you have to learn both. Rust avoids this nicely by just making everything an expression, but you do get some semicolon-related awkwardness as a result.
I used to be like that. When I did Java. I used to think to myself: "Oh neat! Everything has its place. interfaces, abstract classes, classes, methods, anonymous classes, ... everything fits neatly together."
That was before I learned more Python and realized: "Hey wait a moment, things that require me to write elaborate classes in Java are just a little bit of syntax in Python. For example decorators!" And slowly switched to Python.
Now it seems many Java-ers have come to Python, but without changing their mindset. Collectively they make it harder to enjoy using Python, because at workspaces they will mandate the most extreme views towards type annotations, turning Python into a Java dialect in some regards. But without the speed of Java. I have had feedback for a take-home assignment from an application process, where someone in all seriousness complained about me not using type annotations for what amounted to a single page of code(, and for using explanatory comments, when I was not given any guarantees of being able to talk with someone about the code - lol, the audacity).
Part of the problem is how people learn programming. Many people learn it at university, by using Java, and now think everything must work like Java. I mean, Java is honest about types, but it can also be annoying. Has gotten better though. But that message has not arrived yet at what I call the "Java-er mindset" when it comes to writing type annotations. In general languages or their type checkers have become quite good at inferring types.
Of course you can get all this down to a single line with ; demarcation.
And your `.each` could use `{ ... }` syntax, just like C or Java or... you know, everything else.
But sure, whitespace is better, or whatever it is you prefer.
Steen’s not wrong that Python evolved and Ruby moved slower, but he’s wrong to call Ruby stagnant or irrelevant. Just think what we've enjoyed in recent times: YJIT and MJIT massively improved runtime performance, ractors, the various type system efforts (RBS/Sorbet etc) that give gradual typing without cluttering the language etc.
Ruby’s priorities (ergonomics, DSLs, stability) are different[2] from Python’s (standardisation, academia/data). It’s a matter of taste and domain, not superiority.
[1] I'm stealing a point DHH made on Lex's podcast. https://www.youtube.com/watch?v=vagyIcmIGOQ
[2] I'm once again parroting DHH/Matz
Ruby 3.5 will introduce a new language keyword "namespace"
``` class Foo def foo; puts "foo"; end end
namespace Bar class Foo def foo; puts "bar"; end end
endFoo.new.foo #=> "foo" ```
Fun times. See here: https://bugs.ruby-lang.org/issues/21311
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
Anyway, that said, for new personal projects I like typescript and rust. But recently I needed to stick an admin interface on such a project and rails shines there, you can get something good and secure stood up with less code and faff than anything else. In today's world of LLMs that is helpful too, rails is concise and old and has lots of open source projects to pull from, so AI breezes through it.