6 ms·
Happy bday ruby! For the usual doomsdaysayers saying "ruby can't X so I left it for Y", when X is typing, RBS is becoming the accepted standard (now that sorbe
by chucke 9mo ago
Happy bday ruby!
For the usual doomsdaysayers saying "ruby can't X so I left it for Y", when X is typing, RBS is becoming the accepted standard (now that sorbet supports it),and RBS inline notation next to signature/code too (for peeps complaining about separate files); when X is LSP, ruby-lsp is the standard and already supports "go to definition" (its major hole for a long time), and its plugin architecture allows other other features to reuse the same code AST/index (So that each linter/formatter/type checker doesn't have to parse their own); when X is parallelism, ractors are have actually become performant in a lot of common cases, and it's only missing some GC improvements to be truly non-experimental.
There are new shiny things like ZJIT or Box, but even the core team recommends against using them in production for now. But they'll get better, as its been happening with the things listed above.
No wildly new syntax changes is also a good thing. Should help alternative implementations catch up.
- screenothethird 9mo agoIt’s just inferior to Python, nobody is making a more complex argument than that. Why ever use Ruby when there’s a virtually identical system that’s faster with a bigger community.
- amazingman 9mo agoBlanket statements like this are unhelpfully tribal. Ruby has its uses, and underpins one of the most successful (and cloned) MVC frameworks of all time. But yeah, Python received the attention of data scientists early on and now it's a lingua franca of sorts in that domain. Since AI is so hot right now that makes Python seem superior, but really that's just contingency. If you're going to make claims, support them.
- block_dagger 9mo agoWhy? Because Python is generally slower, uses significant whitespace in its syntax, and lacks the metaprogramming features of Ruby.
- BowBun 9mo agoIn what ways is it inferior? Neither Ruby or Python are 'fast', so if that is one of your qualifiers you've already made a suboptimal choice. As for a bigger community, what does that serve? The large python community adds misdirection and more voices to a language that lacks some basic features still. Async/sync code models are still being finalized whereas Ruby has been stable in this regard for 10+ years. Same with tooling - the Ruby side is more consistent and stable: Sidekiq for background jobs (Celery is barely coming to maturity), Bundler for dependencies (pip? poetry? uv?). Mature auth + other frameworks like Devise. Having worked in both languages professionally, I strongly disagree with your take.
- Calavar 9mo agoBecause Ruby is just a better thought out language than Python is. It had a sane package management story 15 years before Python. It doesn't rely on weird hacks like exception throwing for iterator control flow. It doesn't have nearly as many warts and footguns on basic operations (for example, in Python csv.writer(file).writerows(rows) is broken unless you remembered to set the newline mode on the file; in Ruby file.write(rows.to_csv) just works). Thanks to a sane VM design it's mainline JIT can actually run code faster than interpreted code (something that CPython's JIT can't do [1]) Many Pythonistas are woefully ignorant of what's going on outside their siloed community. [1] https://fidget-spinner.github.io/posts/jit-reflections.html https://fidget-spinner.github.io/posts/jit-reflections.html
- lern_too_spel 9mo agoEverything being mutable by default, including strings, is about as big a foot gun as you can find in a high level language.
- nirvdrum 9mo agoHaving immutable objects by default isn’t incredibly commonplace outside of functional languages. It certainly isn’t unique to Ruby and seems out of place in a discussion comparing Ruby to Python. Fortunately, you can defensively freeze any objects you’re passing around to avoid the most common issues with mutable objects. Immutable strings is a more popular programming language feature and Ruby has a mechanism for opting into that. It’s so commonplace that the complaint usually isn’t that a string can be modified, but rather that every source file includes a magic comment to prevent that. Besides data safety, the VM can optimize frozen strings, so popular linters will flip that setting on for you. String mutability isn’t a practical issue for modern codebases. And, as language design goes, it’s kinda nice not needing to use a parallel set of classes for mutable and immutable string data IMHO. With that said, the magic comment is a wart and folks are looking at making immutable strings the default. But, there’s a strong desire to avoid breaking the world. The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.
- 9mo ago
- bjoli 9mo agoRuby is a lot less awful than Python in my opinion. That is of course a very subjective opinion. The only reason I write more Python than Ruby is that ruby lacks the libraries I need. Somewhere along the line Python got all the momentum, and ruby got none and now python is better if you just want to get shit done. But man. I wish it was the other way around. I have one code snippet that summarises what I dislike about python: if input() == "dynamic scope?": defined = "happyhappy" print(defined) Seeing that I understand why I see yuck in just about every corner of python. Edit: in ruby it also works, but the variable is at least always defined.
- sinnsro 9mo ago[dead]
- qezz 9mo ago> in ruby it also works, but the variable is at least always defined. How is this even a pro? I agree that Python scoping rules are frustrating, but tbh not sure if I would prefer Ruby's behavior in this case
- bjoli 9mo agoWell. If python is a dynamically scoped language, what they do is correct. If they are lexically scoped (which python is described as) the variable defined in the if should never have different visibility in the same scope. In a lexically scoped language you don't define variables conditionally. What ruby does is also icky, but obviously the developers of both python and ruby wanted to save the developer an extra declaration. The ruby version is at least more correct from a lexical standpoint (it is set to nil if left "nondefined").
- stouset 9mo agoI’m sure I’ll get downvoted for it, but strict technical merits aside, Python to me seems built by engineers who lacked any sense of taste. Ruby is beautiful.
- BurningFrog 9mo agoA lot of times 2-3 lines of Ruby needs 5-8 lines in Python.
- voidfunc 9mo agoPython is great and I love writing glue in it, but Ruby is just a better designed language and ecosystem overall.
- pansa2 9mo ago> that’s faster In every test I've done, Ruby has been faster than Python. In my experience that's been the case since Ruby 1.9, with the move to YARV.
- osigurdson 9mo agoI don't think anyone says: "I switched from Python to Ruby" (of vice versa) for performance.
- pansa2 9mo agoTrue. Choosing between the two languages usually comes down to their library ecosystems - or more bluntly, to Rails on one hand vs NumPy on the other. Nonetheless, it's still common for people to talk about the relative performance of the two languages, and to claim that Ruby is slower than Python. As someone who's actually tested this, it hasn't been true for 15 years.
- thunky 9mo agoRuby/rails has always felt fragile to me. Like you have to write the same tests over and over to make up for the looseness of it, not to mention the culture of breaking changes adds insult to injury. Just seems like a mess and the nice syntax (subjectively) isn't nearly enough to win when better options exist.
- pxc 9mo ago> Why ever use Ruby when there’s a virtually identical system [...] with a bigger community. There was a time in the history of Python when people who chose Python did so primarily because they found it beautiful or pleasant to work with. These are reasonable factors in choosing a language, and they continue to be popular reasons for choosing relatively unpopular languages today. A related essay has made the rounds on HN before. It might be worth revisiting if this question is on your mind: https://www.johndcook.com/blog/2011/10/26/python-is-a-voluntary-language/ https://www.johndcook.com/blog/2011/10/26/python-is-a-volunt...
- rco8786 9mo agoFairly hardcore rubyist here. Ruby-lsp is excellent. But in no way is RBS becoming standard. Maybe it will, I don’t know. But adoption is very, very low as of today. Rbs-inline is just someone’s pet project and has very little activity (though it does appear that the person who wrote it is trying to implement it directly into Rbs now, which would be great) Personally I can’t see any comment based typing system gaining real traction.
- block_dagger 9mo agoAs long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothing but an impediment to progress.
- throwaway613745 9mo agoDHH also doesn’t like typing in Ruby at all, and Rails is designed around what he likes.
- rco8786 9mo agoI think it will need to be a strong 3rd party that basically gives it the Typescript treatment. Adds type annotations to the core language syntax. The compiler does type checking, strips the annotations, and outputs plain Ruby.
- anamexis 9mo agoSorbet is backed by Stripe. Why is it important to be a separate layer that compiles to plain untyped Ruby?
- rco8786 9mo agoSo that it doesn’t have to go through the Ruby development process. Matz doesn’t want it, and even if he did it would take years just to get people to agree on a syntax, much less actually get it implemented and rolled out. Same reason Typescript was made and we didn’t add types to JavaScript.