6 ms·

> Ruby is an absolute joy to program in. Really? At my company it seems like 90% of the tests are catching things that would be caught automatically if we had

by zionic 5y ago

> Ruby is an absolute joy to program in. Really? At my company it seems like 90% of the tests are catching things that would be caught automatically if we had used a proper language with strong types/compiler. IMO Ruby is slow, not particularly beautiful (yes, this is subjective), and seems optimized for shoving crappy REST endpoints out the door as quickly as possible.

pmontra 5y ago
Do you really need those tests? We are testing validations, CRUD operations, states, border conditions. Sometimes an integration test is enough to validate at least the happy path and catch any mismatch between passed and expected arguments: if we are passing a string instead of an array of strings somewhere, the test will fail.
- smt88 5y ago
  If the tests are catching bugs, obviously they need them. And if those bugs would be prohibited by static typing, then it sounds like Ruby is creating work. > if we are passing a string instead of an array of strings somewhere, the test will fail Is this an example of a real bug? It's mind boggling that anyone would use a language that allows them to type that bug into existence without an immediate error. I know we used to be forced to use JS, but not we even have TS so that we don't have to catch extremely machine-catchable errors in tests or, worse, production.
  - closeparen 5y ago
    You're going to write the tests anyway. Static typing doesn't free you from that responsibility. The question is whether any type errors would make it past a unit test suite focused on other kinds of correctness. In practice they usually don't.
carlivar 5y ago
Have you tried Crystal to get static typing?
- akudha 5y ago
  Crystal seems very interesting, but how is the ecosystem like? How hard/easy is it to find libraries? Also, it seems like a very small team behind the language. Is longevity an issue?
  - speg 5y ago
    I have been infatuated with Crystal since I first saw the 1.0 release posted here in the spring. Your questions point out the obvious shortcomings of Crystal currently. While it is easy to find libraries, they are few and their support is questionable. Not to do anything with the language itself or the ability of community, just the nature of a new and small ecosystem. The team is small but I take solace in the fact that they have been at this for a very long time now (2011). Once nicety that helps the ecosystem is the easy of interoperability with C-libraries. Many shards are simple wrappers around an already established C library.
    - akudha 5y ago
      I just started learning Elixir, Crystal is another language that I want to try at some point. From the first looks of it, it is not going to be that hard to learn (like Haskell or Rust). Lucky framework also seems interesting. I don't think I'd need some niche library for my personal projects at least, but it would be nice to know what one is getting into. I haven't looked at other languages seriously - at the moment Elixir and Crystal seem to be the most interesting to me
- FigurativeVoid 5y ago
  I have been more interested in Sorbet.
CTmystery 5y ago
> like 90% of the tests are catching things that would be caught automatically if we had used a proper language with strong types/compiler It sounds like the tests are testing the wrong thing > seems optimized for shoving crappy REST endpoints out the door as quickly as possible Ruby is a general purpose language. Perhaps it is Rails that you have gripes with? I'd also like to hear what you are doing that leads you to the conclusion that 'ruby is slow'. For most domains I would say ruby is fast enough to solve the problem in a way that customers are perfectly happy with.
mbesto 5y ago
> shoving crappy REST endpoints out the door as quickly as possible. I would argue 90% of the software businesses I've seen are simply CRUD REST endpoints. If that means you can get those out the door as quickly as possible, why on earth would you want to use anything else? It's almost like you're actually advocating for it...
41209 5y ago
You have to use the right tool for the job. If you have a very big project, with a requirement for strong types then you should probably use C# or Java. If I'm in a situation where I need to throw up a rest server as soon as possible, I'm probably using NodeJS. It's dirty but it works ( except when you have the wrong Babel compiler installed and lose 3 days of your life trying to fix it)
handrous 5y ago
Agreed. I've done a lot of Rails over the years, and concluded that, except in the hands of a stable and incredibly disciplined, talented, and knowledgable-about-Rails team, it borders on being write-only. Ruby's fun to write but I hope never to onboard to a Rails codebase again. I think the vast majority of the ones in the wild are... not great, to put it mildly.
- FigurativeVoid 5y ago
  This is probably closer to the real reason that we have had so much fun. I am not particularly senior, and I was wholly new to ruby, but the senior engineers that joined are the "incredibly disciplined, talented, and knowledgable-about-Rails team." It's not just the framework, but the fact that have proper tests, architecture, and CI/CD.
- jrochkind1 5y ago
  I am curious what codebases you have encountered in the wild (with similar age and turnover to those ruby ones) that are great and easy to work with! Have you found this correlates to other platforms better? I feel like in my career, across many different languages and platforms, "legacy" codebases (ie, any codebase that pre-dates me and is a non-trivial amount of code) are uniformly "not great to put it mildly".
  - handrous 5y ago
    Of course most codebases are shit, but it matters a lot more when a Rails codebase is shit than in many other languages/frameworks. The reasons are mainly: 1) The amount of "magic" available and how much it's used—in low-magic scripting languages or frameworks, you can at least grep to find definitions, even if better code navigation tools aren't available. The more often the answer the "wtf is this?" can't be known for-sure until runtime, the harder it is to find your way around, and the more memorization you have to do. Rails and its ecosystem are very high-magic, even more so than something like the roughly-comparable Django. It can be annoying to even figure out which gem defines a given symbol, in a given context. 2) The level of reliance on tests to keep things from falling completely apart. Tests are generally good things, of course, regardless of language, but a poorly-maintained test suite in a Rails codebase is a far more grave problem than it would be in, say, a Go or Typescript codebase (yes, it's mainly the static typing that makes the difference). That is, keeping the codebase viable requires more active attention and work. This is exacerbated by Rails being a common choice for bootstrapping startups (the library ecosystem, especially Devise, which might be single-handedly the main reason Rails wins as many "what should we use?" discussions as it still does, is a pretty damn strong argument in its favor) and bootstrapping startups having a tendency to go through multiple teams in short order (contractors and external dev teams being common, both in the early days and in the somewhat-later, very common, "oh god the cut-rate shop we got to build this fucked it up, please save us" phase) means that a whole lot of live Rails codebases have been treated very poorly, and that, for the above reasons, a Rails codebase that's been treated very poorly is a special kind of hell.

by zionic 5y ago

pmontra 5y ago

Do you really need those tests? We are testing validations, CRUD operations, states, border conditions. Sometimes an integration test is enough to validate at least the happy path and catch any mismatch between passed and expected arguments: if we are passing a string instead of an array of strings somewhere, the test will fail.

smt88 5y ago
If the tests are catching bugs, obviously they need them. And if those bugs would be prohibited by static typing, then it sounds like Ruby is creating work. > if we are passing a string instead of an array of strings somewhere, the test will fail Is this an example of a real bug? It's mind boggling that anyone would use a language that allows them to type that bug into existence without an immediate error. I know we used to be forced to use JS, but not we even have TS so that we don't have to catch extremely machine-catchable errors in tests or, worse, production.
- closeparen 5y ago
  You're going to write the tests anyway. Static typing doesn't free you from that responsibility. The question is whether any type errors would make it past a unit test suite focused on other kinds of correctness. In practice they usually don't.

carlivar 5y ago

Have you tried Crystal to get static typing?

akudha 5y ago
Crystal seems very interesting, but how is the ecosystem like? How hard/easy is it to find libraries? Also, it seems like a very small team behind the language. Is longevity an issue?
- speg 5y ago
  I have been infatuated with Crystal since I first saw the 1.0 release posted here in the spring. Your questions point out the obvious shortcomings of Crystal currently. While it is easy to find libraries, they are few and their support is questionable. Not to do anything with the language itself or the ability of community, just the nature of a new and small ecosystem. The team is small but I take solace in the fact that they have been at this for a very long time now (2011). Once nicety that helps the ecosystem is the easy of interoperability with C-libraries. Many shards are simple wrappers around an already established C library.
  - akudha 5y ago
    I just started learning Elixir, Crystal is another language that I want to try at some point. From the first looks of it, it is not going to be that hard to learn (like Haskell or Rust). Lucky framework also seems interesting. I don't think I'd need some niche library for my personal projects at least, but it would be nice to know what one is getting into. I haven't looked at other languages seriously - at the moment Elixir and Crystal seem to be the most interesting to me
FigurativeVoid 5y ago
I have been more interested in Sorbet.

CTmystery 5y ago

> like 90% of the tests are catching things that would be caught automatically if we had used a proper language with strong types/compiler It sounds like the tests are testing the wrong thing > seems optimized for shoving crappy REST endpoints out the door as quickly as possible Ruby is a general purpose language. Perhaps it is Rails that you have gripes with? I'd also like to hear what you are doing that leads you to the conclusion that 'ruby is slow'. For most domains I would say ruby is fast enough to solve the problem in a way that customers are perfectly happy with.

mbesto 5y ago

> shoving crappy REST endpoints out the door as quickly as possible. I would argue 90% of the software businesses I've seen are simply CRUD REST endpoints. If that means you can get those out the door as quickly as possible, why on earth would you want to use anything else? It's almost like you're actually advocating for it...

41209 5y ago

You have to use the right tool for the job. If you have a very big project, with a requirement for strong types then you should probably use C# or Java. If I'm in a situation where I need to throw up a rest server as soon as possible, I'm probably using NodeJS. It's dirty but it works ( except when you have the wrong Babel compiler installed and lose 3 days of your life trying to fix it)

handrous 5y ago

Agreed. I've done a lot of Rails over the years, and concluded that, except in the hands of a stable and incredibly disciplined, talented, and knowledgable-about-Rails team, it borders on being write-only. Ruby's fun to write but I hope never to onboard to a Rails codebase again. I think the vast majority of the ones in the wild are... not great, to put it mildly.

FigurativeVoid 5y ago
This is probably closer to the real reason that we have had so much fun. I am not particularly senior, and I was wholly new to ruby, but the senior engineers that joined are the "incredibly disciplined, talented, and knowledgable-about-Rails team." It's not just the framework, but the fact that have proper tests, architecture, and CI/CD.
jrochkind1 5y ago
I am curious what codebases you have encountered in the wild (with similar age and turnover to those ruby ones) that are great and easy to work with! Have you found this correlates to other platforms better? I feel like in my career, across many different languages and platforms, "legacy" codebases (ie, any codebase that pre-dates me and is a non-trivial amount of code) are uniformly "not great to put it mildly".
- handrous 5y ago
  Of course most codebases are shit, but it matters a lot more when a Rails codebase is shit than in many other languages/frameworks. The reasons are mainly: 1) The amount of "magic" available and how much it's used—in low-magic scripting languages or frameworks, you can at least grep to find definitions, even if better code navigation tools aren't available. The more often the answer the "wtf is this?" can't be known for-sure until runtime, the harder it is to find your way around, and the more memorization you have to do. Rails and its ecosystem are very high-magic, even more so than something like the roughly-comparable Django. It can be annoying to even figure out which gem defines a given symbol, in a given context. 2) The level of reliance on tests to keep things from falling completely apart. Tests are generally good things, of course, regardless of language, but a poorly-maintained test suite in a Rails codebase is a far more grave problem than it would be in, say, a Go or Typescript codebase (yes, it's mainly the static typing that makes the difference). That is, keeping the codebase viable requires more active attention and work. This is exacerbated by Rails being a common choice for bootstrapping startups (the library ecosystem, especially Devise, which might be single-handedly the main reason Rails wins as many "what should we use?" discussions as it still does, is a pretty damn strong argument in its favor) and bootstrapping startups having a tendency to go through multiple teams in short order (contractors and external dev teams being common, both in the early days and in the somewhat-later, very common, "oh god the cut-rate shop we got to build this fucked it up, please save us" phase) means that a whole lot of live Rails codebases have been treated very poorly, and that, for the above reasons, a Rails codebase that's been treated very poorly is a special kind of hell.