13 ms·

Do I not like Ruby anymore? (2024)

148 points by Vedor 1y ago

KevinMS 1y ago
When the metaprogramming hits just right, and you are at such a high level, the lack of typing can be excused.
pedrorolo 1y ago
This guy is not up to date regarding the ruby language. Keyword arguments and destructing assignments are there.
- gsinclair 1y ago
  I’m pretty sure he understands that keyword arguments are part of Ruby. But they require special syntax. He appreciates that in Python _any_ argument is a keyword argument if you (the caller) want it to be.
melvinroest 1y 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? [1] https://youtu.be/FeFrt-kdvms?si=vlFPIkGuVceztVuW&t=2678 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.
- lmm 1y 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 1y 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 1y 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.
    - dale_glass 1y ago
      But that's an implementation issue. Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat? If you want to make a special use tool, you can write a function like custom_if(cond, then_callback, else_callback) in most languages. Maybe I'm just getting old, but as time goes by I like it more and more when things are obvious and non-magical.
      - zelphirkalt 1y ago
        > Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat? Ha, no, I wouldn't. Because to me it is important, that anyone can read the code, not just me or a German speaking developer. Just like I wouldn't translate "if" to Chinese. The point is, that this translation serves no purpose. Or rather its benefit, if any, is not sufficient to justify it being done and deviating from the standard. Macros can be useful and justified. But these string substitution macros ... Meh, rather rarely, I guess. Maybe for when you don't have "true" and "false" or something. Some useful examples of macros are: Threading/pipelining, timing, function contracts. Things where the order of evaluation needs to change. Things one cannot easily do with functions alone. Your example of "custom_if" is actually a good one, depending on what "custom_if" does. If it needs its arguments to not be evaluated, unless an earlier argument meets some criteria, it would be a good candidate for a macro. Those things are not done using string substitution macros.
fuckaj 1y ago
Likes Lisp Ruby and Typescript, interesting tastes (in a good way... nuanced)
manuelfcreis 1y 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 1y 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.
  - Lio 1y ago
    > I know that goes against a lot of the fundamentals in the language. You're not the only person to reply with something like this but just to repeat, Ruby has had official gradual static typing support for 5 years now. Gradual typing is fundermentally already part of Ruby. Ruby could do with better static analysis tooling but people are being paid to work on that.
    - khoury 1y ago
      What do you mean with "gradual typing"? People want to know what data type a function takes and what a variable is. That's it really.
      - Lio 1y ago
        Gradual typing would be introducing static typing into an existing codebase. Ideally you would want your entire code base statically typed but if it's a large legacy project realistically you might not be able to stop all development work to do that. Ruby 3.x onwards provides static RBS definitions for the standard library and allows you to statically type your own code too. So the statement: > I know that goes against a lot of the fundamentals in the language is not correct. It's not against the fundermentals of the language, static typing is already part of the current ruby release and has been for sometime. > People want to know what data type a function takes and what a variable is. That's it really. I agree and both Solargraph and Ruby-LSP provide that today, as does the IRB REPL. Unfortutately we have two ways of expressing static types and neither is perfect IMHO. My hope is that a new format, RBS-Inline, will solve that and unite the community. As well as the developer experience I hope that having static types availible at runtime will also allow performance optimisations.
dudeinjapan 1y 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 1y 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 1y ago
    To make sure code loaded from gems doesn’t shadow the namespace of the application.
    - dudeinjapan 1y 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" that scopes behavior to that namespace. class Foo def foo; puts "foo"; end end namespace Bar class Foo def foo; puts "bar"; end end Foo.new.foo #=> "bar" end Foo.new.foo #=> "foo" Fun times. This is intended for isolated code loading similar to "modules" in Python or ES6, but I am worried it will be abused badly. I'm also unsure whether they will add a "use Namespace" construct... See here: https://bugs.ruby-lang.org/issues/21311 https://bugs.ruby-lang.org/issues/21311
- codeduck 1y ago
  In your camp, waving a flag. I love ruby's simplicity when it comes to rapidly prototyping something, and find the wails about production type errors puzzling. Only thing I've come near that gave me as much joy was Elixir, and I simply didn't have time to pick it up more than the most generic basics. my mind just likes a.any? {|x| x.someCondition? }
sushibowl 1y 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 1y 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.
pmkary 1y ago
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.
- javaunsafe2019 1y 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…
  - koakuma-chan 1y ago
    I used Kotlin before it was popular and people laughed at me... And now I use TypeScript...
    - maccard 1y ago
      Kotlin is lovely to work with but holy hell is it slow to iterate on.
      - arunix 1y ago
        What does "slow to iterate on" mean?
- zarzavat 1y 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.
wewewedxfgdf 1y 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")
- PaulRobinson 1y 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.
- deleted 1y ago
  [deleted]
- Alifatisk 1y ago
  The indent in your Ruby code is a bit weird. It should be like this 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 1y ago
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 https://www.youtube.com/watch?v=vagyIcmIGOQ
- jemmyw 1y ago
  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.
schappim 1y 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. [1] I'm stealing a point DHH made on Lex's podcast. https://www.youtube.com/watch?v=vagyIcmIGOQ https://www.youtube.com/watch?v=vagyIcmIGOQ [2] I'm once again parroting DHH/Matz
- drob518 1y ago
  My reaction to that part of the post was, “Well, it seems like Python needed to evolve while Ruby was better-designed from the beginning. That’s a failing of Python, not of Ruby.” Language stability is a good thing, which is why I prefer Clojure myself. I know enough Python and Ruby to be dangerous. I’m certainly no expert in either one. That said, Python always struck me as a bit of a hack, but people seemed to resonate with the “indentation is significant” syntax, whereas Ruby felt like it was better designed, taking “everything is an object” to its natural conclusion, similar to Smalltalk, but suffering from performance issues because that means lots of more heavyweight message dispatch.
  - deleted 1y ago
    [deleted]
brainzap 1y ago
I feel the samw, happy that Python is improving and getting more good tooling
- IshKebab 1y 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).
benrutter 1y ago
I'm a python developer, and a big fan of the features with gradual typing etc. This article really highlights for me though, how python has very much changed from the language it was even 5 years ago. Initially, the celebrated feature of python was that it allowed easy and fast development for newcomers. There was a joke a long the lines, "I learned python, it was a great weekend". As much as I like python's type system (and wouldn't want to see them ever go way!), part of me wonders if moving into a world where hello-world can look like this, is a world where python is no longer the "lean in a weekend" language: from typing import Annotated import typer app = typer.Typer() @app.command() def main( name: Annotated[str, typer.Option("--name", "-n")], ) -> None: """Prints out 'HELLO {name}!!' (name upper cased) to the console""" print(f"HELLO {name:upper}!!") if __name__ == "__name__": app() (obviously the example is silly, and I know this is a lot more than you need to do, hopefully you get my point though!)
- pinoy420 1y ago
  [dead]
- Daishiman 1y ago
  All due respect but Typer looks like the kind of library that you want to use after your CLI has enough args that you wouldn't be able to get away with the sort of "Hello World" simplicity that you pine for. Nobody's stopping you from manually parsing a couple of arguments. I still do it all the time and it's OK. If anything the magic of gradual typing is that you get to use it as necessity arises.
  - maleldil 1y ago
    Typer is very convenient. I don't believe anyone manually parses arguments manually in Python where we have argparse in the standard library, and Typer is a step forward from that.
    - Gethsemane 1y ago
      I really want to like typer, and frequently go down the rabbit hole of rewriting all my argparse into typer, but I keep getting put off by it's high import cost and that development seems to be a bit up in the air (see https://github.com/fastapi/typer/issues/678#issuecomment-3191908435 https://github.com/fastapi/typer/issues/678#issuecomment-319...). A shame because otherwise it's a really nice library!
ZephyrBlu 1y ago
I'm confused by this post because I think Sorbet satisfies basically all the things the author wants, and my experience with Sorbet has been really good!
- deleted 1y ago
  [deleted]
- adamors 1y ago
  It pales in comparison to what the author is talking about, editor support for instance is not good, it took them an awful lot of time to add support for linux-aarch64, it's in general rough around the edges (having to maintain various custom type files for some gems it cannot auto-generate type info for) and in general feels like a chore to use.
ckdot 1y ago
Typescript is a workaround. It exists because web apps got more complex and browsers only support JavaScript. So developers need to stick to JavaScript, but they need typing, therefore TypeScript has been implemented. It’s an exception where it made sense to do so. For all other languages: if you use some dynamic language and you need typing, either wait until the language supports types natively (PHP‘s approach) or „just“ change the language. The additional complexity of an additional typing layer is huge. The complexity of TypeScript - and in general JavaScript‘s ecosystem - is incredibly huge. The biggest issue we have in software development is not that a language isn’t elegant, or you can’t write some some in 3 instead of 15 lines… the biggest problem is complexity. Developers too often forget about that. They focus on things that don’t matter. Ruby vs Python? It doesn’t make a real difference for web apps. If you want a language and ecosystem with low complexity try Go. It’s not perfect. It’s not elegant. Or PHP, which has a lot of drawbacks, but overall less complexity. I don’t say Go or PHP are the best languages out there, but you should try them to get a picture - to decide for yourself what’s important and what not.
nurettin 1y ago
Ruby has a unified interface for select/map/reduce over all containers. They do lazy calculations if specified. You can chain expressions simply by appending them at the end without scrolling to the back of the expression. That is objectively better than lisp and python. Sure, you can always rewrite to match that style with macros in lisp and generators in python, but they weren't meant to be used that way. Sad thing about ruby is how they failed to do typing. I love python's typing module. I think it is the single best thing about python and I wouldn't touch python with a pole if it didn't have that module.
- wild_egg 1y ago
  Lisp was absolutely meant to be used that way.
  - nurettin 1y ago
    What I meant was how (op modifier *params) "homomorphism" is praised by literally everyone and their dog and it is simply worse than params.op1(modifier).op2(modifier)
    - klibertp 1y ago
      What GP (probably) meant is that in Lisp you're supposed to write macros, and when you do, this "is simply not worse" than the dotted message sends: (-> params (op1 mod2) (op2 mod2)) params .op1(mod2) .op2(mod2) There's a reason why just about every Lisp currently in use[1] has `->`/`->>`[2] macros: they're just so easy to write that not having them would be strange. Same with |> in OCaml - with currying, it's literally just `let (|>) x f = f x;;`. So, while it's true that Lisp (or OCaml) base language doesn't have the particular convenience, it's also true that in Lisp (and, in this case, in OCaml) you are meant to extend the language to allow such conveniences. [1] With a glorious exception of PicoLisp, because quote is all you'll ever need. [2] And more! With `doto` you have Smalltalk/Dart cascades, with `nest` (https://github.com/ruricolist/serapeum/blob/master/REFERENCE.md#nest-rest-things https://github.com/ruricolist/serapeum/blob/master/REFERENCE...) you have decorators, etc.
postexitus 1y ago
Ruby is a joy to program in. But Python is a workhorse. Ruby is Miata MX-5. Python is Toyota Corolla.
futurecat 1y ago
I find that Python is a very sad experience to read/write. I find the same for modern PHP. In contrast, Ruby's a joyful experience.
- TiredOfLife 1y ago
  PHP is art. Ruby is outsider art.
nromiun 1y ago
> Python is not my favorite programming language. In fact, allow me to drop the euphemism and express my pure, unadulterated thoughts about it: I never liked Python, I see it as a huge red flag and I think the world would be a better place if we all decided to finally move on from it. Why do people make hating a tool their entire personality? I have noticed this same thing with languages like Go ("oh no Go still bad") and C++. I don't like C++ myself but I don't hate it. It would be like hating a screwdriver. If you don't like a language simply don't use it, there are hundreds of alternatives. If your employer is making you write in that language you should hate your employer, not the language.
- hecturchi 1y ago
  For internet points!
- k__ 1y ago
  Especially strong from someone using Ruby, which is basically Hipster-Python. /s
  - fknorangesite 1y ago
    > Hipster Is it 2007 again already?
- mcdonje 1y ago
  You left out this part: > The reasons behind this choice of employment are very much unrelated to the technology stack. Programming language isn't the only factor for employment. People don't always get to just change jobs when an aspect isn't ideal for them. On top of that, python is ubiquitous in some sectors. It's not as easy to avoid as a lot of other languages.
- frumiousirc 1y ago
  > It would be like hating a screwdriver. I hate Philips screwdrivers (but love JIS).
  - 1y ago
RobinL 1y ago
There's a good interview with DHH, who is the creator of Ruby in Rails here: https://lexfridman.com/dhh-david-heinemeier-hansson-transcript https://lexfridman.com/dhh-david-heinemeier-hansson-transcri... I have no skin in the game having never used Ruby, but I found his arguments interesting
troad 1y ago
Ruby is such an elegant language, but the strong and ongoing hostility to any sort of sensible gradual typing is a real mistake. I know that the Ruby community loves its clever runtime metaprogramming, but even the most metaprogrammed codebase is still going to consist mostly of plain old in-out methods. And as anyone who's ever typed a dynamic codebase knows, you pick up so much low-hanging fruit, in terms of edge cases and errors, when you slap some types on those. You don't need to type everything, but there is real hostility in Ruby circles to gradual typing, even where it would make sense and wouldn't impose any major costs. Personally, I've stopped writing Ruby. Short of any pathway to sensible gradual typing, I just can't shake the feeling that every new line of Ruby is instant tech debt. Which is such a shame, since I find real beauty in the language.
- schappim 1y ago
  Have you given RBS/Sorbet etc a go?
  - troad 1y ago
    I gave Sorbet a red hot go on a decently-sized codebase maybe a year ago. I stopped writing Ruby not long after coming to the conclusion that Sorbet is a dead end. I never seriously considered RBS; the idea of maintaining C-style header files always struck me a kind of nuts from a DRY perspective, and very antithetical to the elegance of Ruby. I ended up rewriting my Ruby codebase in Elixir (with thanks to some kind pointers here on HN). Elixir has perfectly satisfactory gradual typing via Erlang's dialyzer, which will happily power an LSP right now, and work is underway on a handmade gradual set-theoretic type system. It's a direction of travel I feel more confident in than Ruby's.
- Lio 1y ago
  > Ruby is such an elegant language, but the strong and ongoing hostility to any sort of sensible gradual typing I'm not sure what you're basing that on, gradual typing has been built into Ruby since 3.0 (2020). Sorbet can around a bit earlier in 2019. There is on going work to improve both with RBS-Inline support now in Sorbet with runtime support hopefully on the way. IRB uses RBS for autocompletion and Solargraph and Ruby-LSP both support it. I would say there is no hostility to gradual typing in the Ruby community. Quite the opposite, people are being paid to work on it.
jemiluv8 1y ago
This reads like a love letter to programming languages. You can never truly talk about the quirks of a language without dabbling in it. And without experience with other languages - I doubt some of these quirks might even be seen as such. Error handling for instance has always been my pet peeve. With dynamic languages like python, errors were all "exceptions". But then golang came along and decided they'd be values and that only the truly exceptional errors should be "panicked". But the if err != nil syntax became super verbose only after I learned about the Result<Ok, Err> from Rust and the matching syntax associated with it. A lot of people are shocked when they learn about ruby's monkey patching. I for one never truly groked the packaging of python applications until uv came along to deliver an experience similar to npm. And I agree, Typescript is the state of the art as far as static typing on top of a dynamic language is concerned. But I never considered it a programming language. More like a tool to assist developers write/manage large javascript code. In the end, I think the true reason for returning to pythong probably had more to do with getting a python gig. I live in the part of the world where my tech stack ended up being influenced early on by the places I worked. I didn't mind learning Typescript for my first gig or improving my skills with nodejs. In the end, every language can really get things done. And Typescript helps me pay my bills and I couldn't be more grateful. Learn to love the quirks of your language and stop comparing it unfavorably with others. To date, I've never seen a language as elegant as ruby. Nor do I find an ecosystem better than python's at data science.
adamors 1y ago
I'm going through the same processes as the author, after about a decade of Ruby I'm writing Typescript, Go and type-hinted Python, and I don't think I want to go back to the lack of namespaces/packages and the lack of typing. And I've actually used Sorbet with Ruby for 2 years, but that seems like a really bad solution to this problem.
- Alifatisk 1y ago
  What do you think of rbs-inline?
  - adamors 1y ago
    Haven't tried that, but I think adding this from tooling will always lead to friction: "smart comments" are annoying to write.
    - Alifatisk 1y ago
      I understand your point and it's valid. I think RBS is an interesting attempt at typed Ruby while also keeping it backwards compatible. I do however believe that having it as an separate file is not the right solution, it adds more load to the developer and ruins the joy of Ruby RBS-inline is an interesting attempt at solving it!
sriku 1y ago
"I consider TypeScript to be the gold standard when it comes to type systems on top of dynamic languages." Doubly weird, considering that TypeScript work was inspired by typed/racket, and TypeScript doesn't have a sound type system afaik and the OP's first love was Scheme.
iainctduncan 1y ago
As someone who loves Scheme (author of a Scheme exenstion for computer music, Scheme for Max), and who has done lots of Python and little Ruby, I find this odd. To me, Ruby is a much further departure from Scheme. At least in Python I can do something close to functional programming with primitives, though I don't get symbols. Ruby's "everything is an object" has always seemed to me to be even a further departure. But then I really don't know Ruby, so happy to be told why this is wrong...
hk1337 1y ago
Sinatra helped me fall in love with Ruby. I work in Python and PHP every day though.
DonnyV 1y ago
I started my programming journey with VB6. Ruby reminds me of Visual Basic. But its never evolved past that. Python became popular because it was a scripting language that had classes and a nice built out framework of features. But it has a god awful syntax and should never be used for a large project. Also their package management is a dumpster fire. This brings me to C#. At .NET 10 there will be another option then python. .NET 10 brings the ability to run C# script files without the need for a proj file or a main method. This will bring the full .NET Framework and NUGET eco system with it. I can't wait to replace all my python scripts with this.
jbrisson 1y ago
Languages come and go. There was a time when there was a huge momentum behind Ruby (and Rails). It is not (sadly) the case anymore. It is a matter of traction. C'est la vie. I remember back in the 90s there was great interest in Delphi (Borland OO language) but then came Java. I don't even know if someone is still coding in Delphi. I guess Ruby will eventually go the same way.
boombapoom 1y ago
I'm seeing an uptick in RoR gigs within the past week

148 points by Vedor 1y ago

KevinMS 1y ago

When the metaprogramming hits just right, and you are at such a high level, the lack of typing can be excused.

pedrorolo 1y ago

This guy is not up to date regarding the ruby language. Keyword arguments and destructing assignments are there.

gsinclair 1y ago
I’m pretty sure he understands that keyword arguments are part of Ruby. But they require special syntax. He appreciates that in Python _any_ argument is a keyword argument if you (the caller) want it to be.

melvinroest 1y 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? [1] https://youtu.be/FeFrt-kdvms?si=vlFPIkGuVceztVuW&t=2678 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.

lmm 1y 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 1y 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 1y 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.
  - dale_glass 1y ago
    But that's an implementation issue. Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat? If you want to make a special use tool, you can write a function like custom_if(cond, then_callback, else_callback) in most languages. Maybe I'm just getting old, but as time goes by I like it more and more when things are obvious and non-magical.
    - zelphirkalt 1y ago
      > Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat? Ha, no, I wouldn't. Because to me it is important, that anyone can read the code, not just me or a German speaking developer. Just like I wouldn't translate "if" to Chinese. The point is, that this translation serves no purpose. Or rather its benefit, if any, is not sufficient to justify it being done and deviating from the standard. Macros can be useful and justified. But these string substitution macros ... Meh, rather rarely, I guess. Maybe for when you don't have "true" and "false" or something. Some useful examples of macros are: Threading/pipelining, timing, function contracts. Things where the order of evaluation needs to change. Things one cannot easily do with functions alone. Your example of "custom_if" is actually a good one, depending on what "custom_if" does. If it needs its arguments to not be evaluated, unless an earlier argument meets some criteria, it would be a good candidate for a macro. Those things are not done using string substitution macros.

fuckaj 1y ago

Likes Lisp Ruby and Typescript, interesting tastes (in a good way... nuanced)

manuelfcreis 1y 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 1y 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.
- Lio 1y ago
  > I know that goes against a lot of the fundamentals in the language. You're not the only person to reply with something like this but just to repeat, Ruby has had official gradual static typing support for 5 years now. Gradual typing is fundermentally already part of Ruby. Ruby could do with better static analysis tooling but people are being paid to work on that.
  - khoury 1y ago
    What do you mean with "gradual typing"? People want to know what data type a function takes and what a variable is. That's it really.
    - Lio 1y ago
      Gradual typing would be introducing static typing into an existing codebase. Ideally you would want your entire code base statically typed but if it's a large legacy project realistically you might not be able to stop all development work to do that. Ruby 3.x onwards provides static RBS definitions for the standard library and allows you to statically type your own code too. So the statement: > I know that goes against a lot of the fundamentals in the language is not correct. It's not against the fundermentals of the language, static typing is already part of the current ruby release and has been for sometime. > People want to know what data type a function takes and what a variable is. That's it really. I agree and both Solargraph and Ruby-LSP provide that today, as does the IRB REPL. Unfortutately we have two ways of expressing static types and neither is perfect IMHO. My hope is that a new format, RBS-Inline, will solve that and unite the community. As well as the developer experience I hope that having static types availible at runtime will also allow performance optimisations.

dudeinjapan 1y 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 1y 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 1y ago
  To make sure code loaded from gems doesn’t shadow the namespace of the application.
  - dudeinjapan 1y 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" that scopes behavior to that namespace. class Foo def foo; puts "foo"; end end namespace Bar class Foo def foo; puts "bar"; end end Foo.new.foo #=> "bar" end Foo.new.foo #=> "foo" Fun times. This is intended for isolated code loading similar to "modules" in Python or ES6, but I am worried it will be abused badly. I'm also unsure whether they will add a "use Namespace" construct... See here: https://bugs.ruby-lang.org/issues/21311 https://bugs.ruby-lang.org/issues/21311
codeduck 1y ago
In your camp, waving a flag. I love ruby's simplicity when it comes to rapidly prototyping something, and find the wails about production type errors puzzling. Only thing I've come near that gave me as much joy was Elixir, and I simply didn't have time to pick it up more than the most generic basics. my mind just likes a.any? {|x| x.someCondition? }

sushibowl 1y 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 1y 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.

pmkary 1y ago

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.

javaunsafe2019 1y 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…
- koakuma-chan 1y ago
  I used Kotlin before it was popular and people laughed at me... And now I use TypeScript...
  - maccard 1y ago
    Kotlin is lovely to work with but holy hell is it slow to iterate on.
    - arunix 1y ago
      What does "slow to iterate on" mean?
zarzavat 1y 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.

wewewedxfgdf 1y 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")

PaulRobinson 1y 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.
deleted 1y ago
[deleted]
Alifatisk 1y ago
The indent in your Ruby code is a bit weird. It should be like this 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 1y ago

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 https://www.youtube.com/watch?v=vagyIcmIGOQ

jemmyw 1y ago
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.

schappim 1y 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. [1] I'm stealing a point DHH made on Lex's podcast. https://www.youtube.com/watch?v=vagyIcmIGOQ https://www.youtube.com/watch?v=vagyIcmIGOQ [2] I'm once again parroting DHH/Matz

drob518 1y ago
My reaction to that part of the post was, “Well, it seems like Python needed to evolve while Ruby was better-designed from the beginning. That’s a failing of Python, not of Ruby.” Language stability is a good thing, which is why I prefer Clojure myself. I know enough Python and Ruby to be dangerous. I’m certainly no expert in either one. That said, Python always struck me as a bit of a hack, but people seemed to resonate with the “indentation is significant” syntax, whereas Ruby felt like it was better designed, taking “everything is an object” to its natural conclusion, similar to Smalltalk, but suffering from performance issues because that means lots of more heavyweight message dispatch.
- deleted 1y ago
  [deleted]

brainzap 1y ago

I feel the samw, happy that Python is improving and getting more good tooling

IshKebab 1y 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).

benrutter 1y ago

I'm a python developer, and a big fan of the features with gradual typing etc. This article really highlights for me though, how python has very much changed from the language it was even 5 years ago. Initially, the celebrated feature of python was that it allowed easy and fast development for newcomers. There was a joke a long the lines, "I learned python, it was a great weekend". As much as I like python's type system (and wouldn't want to see them ever go way!), part of me wonders if moving into a world where hello-world can look like this, is a world where python is no longer the "lean in a weekend" language: from typing import Annotated import typer app = typer.Typer() @app.command() def main( name: Annotated[str, typer.Option("--name", "-n")], ) -> None: """Prints out 'HELLO {name}!!' (name upper cased) to the console""" print(f"HELLO {name:upper}!!") if __name__ == "__name__": app() (obviously the example is silly, and I know this is a lot more than you need to do, hopefully you get my point though!)

pinoy420 1y ago
[dead]
Daishiman 1y ago
All due respect but Typer looks like the kind of library that you want to use after your CLI has enough args that you wouldn't be able to get away with the sort of "Hello World" simplicity that you pine for. Nobody's stopping you from manually parsing a couple of arguments. I still do it all the time and it's OK. If anything the magic of gradual typing is that you get to use it as necessity arises.
- maleldil 1y ago
  Typer is very convenient. I don't believe anyone manually parses arguments manually in Python where we have argparse in the standard library, and Typer is a step forward from that.
  - Gethsemane 1y ago
    I really want to like typer, and frequently go down the rabbit hole of rewriting all my argparse into typer, but I keep getting put off by it's high import cost and that development seems to be a bit up in the air (see https://github.com/fastapi/typer/issues/678#issuecomment-3191908435 https://github.com/fastapi/typer/issues/678#issuecomment-319...). A shame because otherwise it's a really nice library!

ZephyrBlu 1y ago

I'm confused by this post because I think Sorbet satisfies basically all the things the author wants, and my experience with Sorbet has been really good!

deleted 1y ago
[deleted]
adamors 1y ago
It pales in comparison to what the author is talking about, editor support for instance is not good, it took them an awful lot of time to add support for linux-aarch64, it's in general rough around the edges (having to maintain various custom type files for some gems it cannot auto-generate type info for) and in general feels like a chore to use.

ckdot 1y ago

Typescript is a workaround. It exists because web apps got more complex and browsers only support JavaScript. So developers need to stick to JavaScript, but they need typing, therefore TypeScript has been implemented. It’s an exception where it made sense to do so. For all other languages: if you use some dynamic language and you need typing, either wait until the language supports types natively (PHP‘s approach) or „just“ change the language. The additional complexity of an additional typing layer is huge. The complexity of TypeScript - and in general JavaScript‘s ecosystem - is incredibly huge. The biggest issue we have in software development is not that a language isn’t elegant, or you can’t write some some in 3 instead of 15 lines… the biggest problem is complexity. Developers too often forget about that. They focus on things that don’t matter. Ruby vs Python? It doesn’t make a real difference for web apps. If you want a language and ecosystem with low complexity try Go. It’s not perfect. It’s not elegant. Or PHP, which has a lot of drawbacks, but overall less complexity. I don’t say Go or PHP are the best languages out there, but you should try them to get a picture - to decide for yourself what’s important and what not.

nurettin 1y ago

Ruby has a unified interface for select/map/reduce over all containers. They do lazy calculations if specified. You can chain expressions simply by appending them at the end without scrolling to the back of the expression. That is objectively better than lisp and python. Sure, you can always rewrite to match that style with macros in lisp and generators in python, but they weren't meant to be used that way. Sad thing about ruby is how they failed to do typing. I love python's typing module. I think it is the single best thing about python and I wouldn't touch python with a pole if it didn't have that module.

wild_egg 1y ago
Lisp was absolutely meant to be used that way.
- nurettin 1y ago
  What I meant was how (op modifier *params) "homomorphism" is praised by literally everyone and their dog and it is simply worse than params.op1(modifier).op2(modifier)
  - klibertp 1y ago
    What GP (probably) meant is that in Lisp you're supposed to write macros, and when you do, this "is simply not worse" than the dotted message sends: (-> params (op1 mod2) (op2 mod2)) params .op1(mod2) .op2(mod2) There's a reason why just about every Lisp currently in use[1] has `->`/`->>`[2] macros: they're just so easy to write that not having them would be strange. Same with |> in OCaml - with currying, it's literally just `let (|>) x f = f x;;`. So, while it's true that Lisp (or OCaml) base language doesn't have the particular convenience, it's also true that in Lisp (and, in this case, in OCaml) you are meant to extend the language to allow such conveniences. [1] With a glorious exception of PicoLisp, because quote is all you'll ever need. [2] And more! With `doto` you have Smalltalk/Dart cascades, with `nest` (https://github.com/ruricolist/serapeum/blob/master/REFERENCE.md#nest-rest-things https://github.com/ruricolist/serapeum/blob/master/REFERENCE...) you have decorators, etc.

postexitus 1y ago

Ruby is a joy to program in. But Python is a workhorse. Ruby is Miata MX-5. Python is Toyota Corolla.

futurecat 1y ago

I find that Python is a very sad experience to read/write. I find the same for modern PHP. In contrast, Ruby's a joyful experience.

TiredOfLife 1y ago
PHP is art. Ruby is outsider art.

nromiun 1y ago

> Python is not my favorite programming language. In fact, allow me to drop the euphemism and express my pure, unadulterated thoughts about it: I never liked Python, I see it as a huge red flag and I think the world would be a better place if we all decided to finally move on from it. Why do people make hating a tool their entire personality? I have noticed this same thing with languages like Go ("oh no Go still bad") and C++. I don't like C++ myself but I don't hate it. It would be like hating a screwdriver. If you don't like a language simply don't use it, there are hundreds of alternatives. If your employer is making you write in that language you should hate your employer, not the language.

hecturchi 1y ago
For internet points!
k__ 1y ago
Especially strong from someone using Ruby, which is basically Hipster-Python. /s
- fknorangesite 1y ago
  > Hipster Is it 2007 again already?
mcdonje 1y ago
You left out this part: > The reasons behind this choice of employment are very much unrelated to the technology stack. Programming language isn't the only factor for employment. People don't always get to just change jobs when an aspect isn't ideal for them. On top of that, python is ubiquitous in some sectors. It's not as easy to avoid as a lot of other languages.
frumiousirc 1y ago
> It would be like hating a screwdriver. I hate Philips screwdrivers (but love JIS).
- 1y ago

RobinL 1y ago

There's a good interview with DHH, who is the creator of Ruby in Rails here: https://lexfridman.com/dhh-david-heinemeier-hansson-transcript https://lexfridman.com/dhh-david-heinemeier-hansson-transcri... I have no skin in the game having never used Ruby, but I found his arguments interesting

troad 1y ago

Ruby is such an elegant language, but the strong and ongoing hostility to any sort of sensible gradual typing is a real mistake. I know that the Ruby community loves its clever runtime metaprogramming, but even the most metaprogrammed codebase is still going to consist mostly of plain old in-out methods. And as anyone who's ever typed a dynamic codebase knows, you pick up so much low-hanging fruit, in terms of edge cases and errors, when you slap some types on those. You don't need to type everything, but there is real hostility in Ruby circles to gradual typing, even where it would make sense and wouldn't impose any major costs. Personally, I've stopped writing Ruby. Short of any pathway to sensible gradual typing, I just can't shake the feeling that every new line of Ruby is instant tech debt. Which is such a shame, since I find real beauty in the language.

schappim 1y ago
Have you given RBS/Sorbet etc a go?
- troad 1y ago
  I gave Sorbet a red hot go on a decently-sized codebase maybe a year ago. I stopped writing Ruby not long after coming to the conclusion that Sorbet is a dead end. I never seriously considered RBS; the idea of maintaining C-style header files always struck me a kind of nuts from a DRY perspective, and very antithetical to the elegance of Ruby. I ended up rewriting my Ruby codebase in Elixir (with thanks to some kind pointers here on HN). Elixir has perfectly satisfactory gradual typing via Erlang's dialyzer, which will happily power an LSP right now, and work is underway on a handmade gradual set-theoretic type system. It's a direction of travel I feel more confident in than Ruby's.
Lio 1y ago
> Ruby is such an elegant language, but the strong and ongoing hostility to any sort of sensible gradual typing I'm not sure what you're basing that on, gradual typing has been built into Ruby since 3.0 (2020). Sorbet can around a bit earlier in 2019. There is on going work to improve both with RBS-Inline support now in Sorbet with runtime support hopefully on the way. IRB uses RBS for autocompletion and Solargraph and Ruby-LSP both support it. I would say there is no hostility to gradual typing in the Ruby community. Quite the opposite, people are being paid to work on it.

jemiluv8 1y ago

This reads like a love letter to programming languages. You can never truly talk about the quirks of a language without dabbling in it. And without experience with other languages - I doubt some of these quirks might even be seen as such. Error handling for instance has always been my pet peeve. With dynamic languages like python, errors were all "exceptions". But then golang came along and decided they'd be values and that only the truly exceptional errors should be "panicked". But the if err != nil syntax became super verbose only after I learned about the Result<Ok, Err> from Rust and the matching syntax associated with it. A lot of people are shocked when they learn about ruby's monkey patching. I for one never truly groked the packaging of python applications until uv came along to deliver an experience similar to npm. And I agree, Typescript is the state of the art as far as static typing on top of a dynamic language is concerned. But I never considered it a programming language. More like a tool to assist developers write/manage large javascript code. In the end, I think the true reason for returning to pythong probably had more to do with getting a python gig. I live in the part of the world where my tech stack ended up being influenced early on by the places I worked. I didn't mind learning Typescript for my first gig or improving my skills with nodejs. In the end, every language can really get things done. And Typescript helps me pay my bills and I couldn't be more grateful. Learn to love the quirks of your language and stop comparing it unfavorably with others. To date, I've never seen a language as elegant as ruby. Nor do I find an ecosystem better than python's at data science.

adamors 1y ago

I'm going through the same processes as the author, after about a decade of Ruby I'm writing Typescript, Go and type-hinted Python, and I don't think I want to go back to the lack of namespaces/packages and the lack of typing. And I've actually used Sorbet with Ruby for 2 years, but that seems like a really bad solution to this problem.

Alifatisk 1y ago
What do you think of rbs-inline?
- adamors 1y ago
  Haven't tried that, but I think adding this from tooling will always lead to friction: "smart comments" are annoying to write.
  - Alifatisk 1y ago
    I understand your point and it's valid. I think RBS is an interesting attempt at typed Ruby while also keeping it backwards compatible. I do however believe that having it as an separate file is not the right solution, it adds more load to the developer and ruins the joy of Ruby RBS-inline is an interesting attempt at solving it!

sriku 1y ago

"I consider TypeScript to be the gold standard when it comes to type systems on top of dynamic languages." Doubly weird, considering that TypeScript work was inspired by typed/racket, and TypeScript doesn't have a sound type system afaik and the OP's first love was Scheme.

iainctduncan 1y ago

As someone who loves Scheme (author of a Scheme exenstion for computer music, Scheme for Max), and who has done lots of Python and little Ruby, I find this odd. To me, Ruby is a much further departure from Scheme. At least in Python I can do something close to functional programming with primitives, though I don't get symbols. Ruby's "everything is an object" has always seemed to me to be even a further departure. But then I really don't know Ruby, so happy to be told why this is wrong...

hk1337 1y ago

Sinatra helped me fall in love with Ruby. I work in Python and PHP every day though.

DonnyV 1y ago

I started my programming journey with VB6. Ruby reminds me of Visual Basic. But its never evolved past that. Python became popular because it was a scripting language that had classes and a nice built out framework of features. But it has a god awful syntax and should never be used for a large project. Also their package management is a dumpster fire. This brings me to C#. At .NET 10 there will be another option then python. .NET 10 brings the ability to run C# script files without the need for a proj file or a main method. This will bring the full .NET Framework and NUGET eco system with it. I can't wait to replace all my python scripts with this.

jbrisson 1y ago

Languages come and go. There was a time when there was a huge momentum behind Ruby (and Rails). It is not (sadly) the case anymore. It is a matter of traction. C'est la vie. I remember back in the 90s there was great interest in Delphi (Borland OO language) but then came Java. I don't even know if someone is still coding in Delphi. I guess Ruby will eventually go the same way.

boombapoom 1y ago

I'm seeing an uptick in RoR gigs within the past week