8 ms·

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a compl

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me

tluyben2 6y ago
Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone some time ago'; I go check it and it's almost always something php/RoR/(and lately node) built by someone that left years ago and no-one touched it since because it works. When you actually do touch it, ofcourse, it is completely out of date, nothing current works and because of the flexibility of these languages and systems things change way too fast (really unneeded API breaks in packages is something crazy to me; coming from Java, I expect people to keep things backward compatible, but nope; just toss it out!) (especially node npm and least of all PHP which is actually a joy to work with in this kind of spelonking as it is remarkably stable including it's (older) libraries) (and no, not everyone uses a framework with php 'nowadays'; I run into many PHP projects a few years old that are just plain php, more so than frameworks used and that actually does make it easier to jump as plain php still works from a decade ago after update). And then when you have it running on your laptop, it usually is full of these 'corner cases' (lazy programmer input/output handling I would call it) which don't age well (and often hides bugs). On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.
- The_rationalist 6y ago
  The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!
  - zaphar 6y ago
    The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.
    - ed25519FUUU 6y ago
      Don’t get me wrong. I use java every day and quite enjoy it, but when I compare it to writing in Go or Kotlin, java does sometimes feel a little like meta programming. Especially if it’s a spring app, which is quite common.
      - eitland 6y ago
        This is obviously a matter of taste but I enjoy Java more when I stay away from Spring.
    - The_rationalist 6y ago
      No it is not as capable. The cultural verbosity is only a subset of the verbosity in java. The cultural one is great as those long API names allows for standardized and maximal clarity. The one induced by language syntax is accidental. https://www.mediaan.com/mediaan-blog/kotlin-vs-java https://www.mediaan.com/mediaan-blog/kotlin-vs-java Things like state of the art type inference, data classes and lambda syntax, no semi colon and ton of other things allow for reduced syntactic noise.
    - mumblemumble 6y ago
      So, technically, you can get rid of a lot of the more egregious clutter with things like Project Lombok. But I'd argue that, if you need to lean on compiler plugins to do it, it's sort of a rhetorical Pyrrhic victory.
DevoidSimo 6y ago
Agree here, admittedly I have no prior Ruby experience, but I've inherited a code base in Rails. There is so much magic that goes on implicitly. I end up jumping around everywhere to see why something unexpected is happening.
thepratt 6y ago
Have you used sorbet on these codebases? I'd be curious if there'd be a benefit here in terms of maintainability.
- zrail 6y ago
  Sorbet is the only way I can function in anything larger than a 10 line script these days. I’ve started adding it to personal projects because it makes revisiting them later so much easier.
  - square_usual 6y ago
    Without the LSP implementation out in the open, though, sorbet is just a type checker. It's not made much for sense for me to start integrating it into my personal projects just yet, since I only get the benefits when I run tc manually. Once Stripe opens up the LSP, however, I can see it gaining widespread adoption.
    - zrail 6y ago
      I haven’t tried the open source release lately but it looks like master has the lsp option.
- jes5199 6y ago
  sorbet is relatively new and I've been avoiding ruby for the last two years
mumblemumble 6y ago
I've discovered in large, long-lived Java codebases that it's common to Greenspun expressiveness and malleability back into the language through heavy reliance on things like Spring, stringly typed mechanisms, and dynamic code generation. The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language brings its own maintenance challenges. I can't speak to Ruby specifically, but, in practice, I haven't found that I'm all that much more afraid to change things in a large Python codebase than a large Java one. I'm now coming to think that the real challenge is dynamicism in general, regardless of whether it's built into the language or implemented as a library solution. So, if Java has an advantage here, it's simply that it tends to discourage people from overdoing it by making it awkward to do.
- milesvp 6y ago
  What I find interesting about dynamism, is that every templating library I’ve ever used has a tendency to become php over time. Even templating libs in php! It’s fascinating to watch, since each new feature really makes sense because certain logic is trivial in the template, that would be way more complicated elsewhere, and so the template lib has pressure to add little things. Next thing you know the complexity and feature set of the lib is it’s own beast to deal with.
victor106 6y ago
Exactly this. I was involved in developing large PHP and Rubby codebases and its so hard to maintain. These days I just use SpringBoot. It strikes a good balance between providing speed to market (PHP/Ruby), maintainability and performance (the next version should support GraalVM). Cant complaint so far.
wahern 6y ago
> Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me Sure, but if you don't reach market fast enough you'll have no reason to slog through anything, period. Can you imagine writing something like Facebook using Rust? It's an almost ludicrous proposition. Static typing requires that you know what you're building at a relatively fine-grained level--how the pieces will fit together at the source code level, at least roughly. No amount of automated refactoring could ever match the flexibility of dynamic typing when you're just trying to bang out features, let alone explore the feature space, which almost by definition is what any novel solution is doing--exploring. That's why I love using embedded scripting, particularly Lua. You can gradually move components outside the dynamic environment as their place in the architecture becomes fixed and well understood.[1] So-called gradual typing doesn't really permit the same kind of flexibility because it's not the static typing, per se, that burdens development, but rather that static typing has the effect of forcing a more rigid hierarchy of higher-order abstractions and interface boundaries. What you want is the ability to slowly solidify the architecture from the outside to the inside, not the inside to the outside. Microservices is another way to address the problem, at least in theory, but in practice doesn't actually directly resolve the real dilemmas. At best it just multiplies the number of environments in which you're faced with the problem, which can both help and hurt. [1] Statically typed scripting languages seem rather pointless to me, and more a reflection of a fleeting fascination with REPL.
- iopq 6y ago
  After working with a 300,000 LoC code base of PHP I would gladly rewrite Facebook in Rust. It allows effortless atomic commits. When I build something I make an MVP of a first version, refactor, make an MVP of the next version, refactor, and so on. Rust lets me make sure my code still works through refactors and code changes. With PHP I could easily break something that would only cause an error when that code actually runs. That's right, there is no sanity check at all until the parser reads that code.
- steveklabnik 6y ago
  Facebook uses a bunch of a Rust, incidentally. They also use a lot of statically typed languages, and have made some of their own, even.

tluyben2 6y ago

Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone some time ago'; I go check it and it's almost always something php/RoR/(and lately node) built by someone that left years ago and no-one touched it since because it works. When you actually do touch it, ofcourse, it is completely out of date, nothing current works and because of the flexibility of these languages and systems things change way too fast (really unneeded API breaks in packages is something crazy to me; coming from Java, I expect people to keep things backward compatible, but nope; just toss it out!) (especially node npm and least of all PHP which is actually a joy to work with in this kind of spelonking as it is remarkably stable including it's (older) libraries) (and no, not everyone uses a framework with php 'nowadays'; I run into many PHP projects a few years old that are just plain php, more so than frameworks used and that actually does make it easier to jump as plain php still works from a decade ago after update). And then when you have it running on your laptop, it usually is full of these 'corner cases' (lazy programmer input/output handling I would call it) which don't age well (and often hides bugs). On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.

The_rationalist 6y ago
The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!
- zaphar 6y ago
  The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.
  - ed25519FUUU 6y ago
    Don’t get me wrong. I use java every day and quite enjoy it, but when I compare it to writing in Go or Kotlin, java does sometimes feel a little like meta programming. Especially if it’s a spring app, which is quite common.
    - eitland 6y ago
      This is obviously a matter of taste but I enjoy Java more when I stay away from Spring.
  - The_rationalist 6y ago
    No it is not as capable. The cultural verbosity is only a subset of the verbosity in java. The cultural one is great as those long API names allows for standardized and maximal clarity. The one induced by language syntax is accidental. https://www.mediaan.com/mediaan-blog/kotlin-vs-java https://www.mediaan.com/mediaan-blog/kotlin-vs-java Things like state of the art type inference, data classes and lambda syntax, no semi colon and ton of other things allow for reduced syntactic noise.
  - mumblemumble 6y ago
    So, technically, you can get rid of a lot of the more egregious clutter with things like Project Lombok. But I'd argue that, if you need to lean on compiler plugins to do it, it's sort of a rhetorical Pyrrhic victory.

DevoidSimo 6y ago

Agree here, admittedly I have no prior Ruby experience, but I've inherited a code base in Rails. There is so much magic that goes on implicitly. I end up jumping around everywhere to see why something unexpected is happening.

thepratt 6y ago

Have you used sorbet on these codebases? I'd be curious if there'd be a benefit here in terms of maintainability.

zrail 6y ago
Sorbet is the only way I can function in anything larger than a 10 line script these days. I’ve started adding it to personal projects because it makes revisiting them later so much easier.
- square_usual 6y ago
  Without the LSP implementation out in the open, though, sorbet is just a type checker. It's not made much for sense for me to start integrating it into my personal projects just yet, since I only get the benefits when I run tc manually. Once Stripe opens up the LSP, however, I can see it gaining widespread adoption.
  - zrail 6y ago
    I haven’t tried the open source release lately but it looks like master has the lsp option.
jes5199 6y ago
sorbet is relatively new and I've been avoiding ruby for the last two years

mumblemumble 6y ago

I've discovered in large, long-lived Java codebases that it's common to Greenspun expressiveness and malleability back into the language through heavy reliance on things like Spring, stringly typed mechanisms, and dynamic code generation. The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language brings its own maintenance challenges. I can't speak to Ruby specifically, but, in practice, I haven't found that I'm all that much more afraid to change things in a large Python codebase than a large Java one. I'm now coming to think that the real challenge is dynamicism in general, regardless of whether it's built into the language or implemented as a library solution. So, if Java has an advantage here, it's simply that it tends to discourage people from overdoing it by making it awkward to do.

milesvp 6y ago
What I find interesting about dynamism, is that every templating library I’ve ever used has a tendency to become php over time. Even templating libs in php! It’s fascinating to watch, since each new feature really makes sense because certain logic is trivial in the template, that would be way more complicated elsewhere, and so the template lib has pressure to add little things. Next thing you know the complexity and feature set of the lib is it’s own beast to deal with.

victor106 6y ago

Exactly this. I was involved in developing large PHP and Rubby codebases and its so hard to maintain. These days I just use SpringBoot. It strikes a good balance between providing speed to market (PHP/Ruby), maintainability and performance (the next version should support GraalVM). Cant complaint so far.

wahern 6y ago

> Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me Sure, but if you don't reach market fast enough you'll have no reason to slog through anything, period. Can you imagine writing something like Facebook using Rust? It's an almost ludicrous proposition. Static typing requires that you know what you're building at a relatively fine-grained level--how the pieces will fit together at the source code level, at least roughly. No amount of automated refactoring could ever match the flexibility of dynamic typing when you're just trying to bang out features, let alone explore the feature space, which almost by definition is what any novel solution is doing--exploring. That's why I love using embedded scripting, particularly Lua. You can gradually move components outside the dynamic environment as their place in the architecture becomes fixed and well understood.[1] So-called gradual typing doesn't really permit the same kind of flexibility because it's not the static typing, per se, that burdens development, but rather that static typing has the effect of forcing a more rigid hierarchy of higher-order abstractions and interface boundaries. What you want is the ability to slowly solidify the architecture from the outside to the inside, not the inside to the outside. Microservices is another way to address the problem, at least in theory, but in practice doesn't actually directly resolve the real dilemmas. At best it just multiplies the number of environments in which you're faced with the problem, which can both help and hurt. [1] Statically typed scripting languages seem rather pointless to me, and more a reflection of a fleeting fascination with REPL.

iopq 6y ago
After working with a 300,000 LoC code base of PHP I would gladly rewrite Facebook in Rust. It allows effortless atomic commits. When I build something I make an MVP of a first version, refactor, make an MVP of the next version, refactor, and so on. Rust lets me make sure my code still works through refactors and code changes. With PHP I could easily break something that would only cause an error when that code actually runs. That's right, there is no sanity check at all until the parser reads that code.
steveklabnik 6y ago
Facebook uses a bunch of a Rust, incidentally. They also use a lot of statically typed languages, and have made some of their own, even.