5 ms·

> Ruby isn’t designed for a team of 200 programmers where you don’t trust some of them. Never mind a team of 200, even on a team of one person I don't trust my

> Ruby isn’t designed for a team of 200 programmers where you don’t trust some of them. Never mind a team of 200, even on a team of one person I don't trust myself! That's why I'm using typed FP. I don't trust myself not to make clumsy errors. I don't trust myself to be disciplined and write all the tests. I don't trust myself to not design a naïve architecture which I'll have to do a huge — and dangerous — refactoring on later. This is why I'm not using Ruby/Rails any longer.

aliante 6y ago
“I can’t be bothered to do anything properly. It must be a problem with Rails.”
- AndrewDucker 6y ago
  "I recognize that no human is fallible, so I use tools that don't assume infallibility"
  - tluyben2 6y ago
    I think that's really the answer. We all mess up and using tools that make it easy to mess up is a problem... It will happen and it can happen in very bizarre ways.
  - spanhandler 6y ago
    Safety aside, I find going back to “guess the source of the meta magical pattern-named method” intolerable these days. Onboarding to, taking over, or pinch-hitting in a Rails codebase is miserable unless it’s tiny and perfectly maintained by developers with excellent judgement and taste—and of course this is almost never the case.
- yakshaving_jgt 6y ago
  What does "properly" mean in this context? All of my income is from my own software businesses. I used to try to do this with Ruby, and there were lots of problems. Now I do it with Haskell, and there are fewer problems. This ended up being a very good business decision for me. What is the return on investment for me as a businessman on bothering to "do anything properly" when the resulting product is both cheaper to write and is more stable if I just use a better tool? What do I actually gain? Some kind of nerd-honour?
rgoulter 6y ago
I think "refactoring is much safer in strongly-typed languages" is a point against using Ruby. It's my understanding that some of what counts as "writing tests" in Ruby would be covered by static types in other languages. -- But it's also not the case that that having types excuses the developer from having tests. (Maybe with dependent types?). This point reminds me of some essays from Steve Yegge where he argued that one way of categorising programmers was into two groups: 'conservatives' who liked languages like Haskell where you could have confidence the code worked if it compiled, etc. and 'liberals' who liked languages like Ruby, where if you notice something breaks you just fix it; just write some feature to see if it works or not. -- I'd think for prototyping it's nicer to have the latter attitude, and it's more reasonable you'll have an understanding of the system since it's so fresh. For long term maintenance, the former is surely better
- yakshaving_jgt 6y ago
  I think you're right, and it was more Ruby (and other similar languages) that I was abandoning rather than Rails specifically. I like Rails. I can't speak for everyone, but my perspective comes from a place of practicality as opposed to philosophy. I (and also my team) try to push the domain we're modelling into the types, but we also write a whole bunch of tests (which includes isolated, integrated, and property-based tests). I've never understood the argument of one vs the other — it's great to have both. Programming is tough so I'll take all the help I can get.
- jmchuster 6y ago
  The Rails/Ruby community has probably the most developed testing culture out of all the programming communities out there, because tests are so critical when you're writing in a dynamic backend language. You don't have the built-in "tests" from a compiler that check every argument and method reference. And then you don't have as fast and obvious a feedback loop as you do with frontend languages.
brazzy 6y ago
It's not really about trust, not even about skill. I submit that this sentence: > Ruby allows for a lot of non-local effects. Whether that’s monkeypatching, writing to a database or creating new types at runtime, Ruby isn’t designed for a team of 200 programmers can and should end there, full stop. The bigger your team, no matter how skilled, the more often someone somewhere will make a mistake and cause side effects they didn't intend. And when these side effects can manifest in unfathomable and hard-to-analyze errors in a completely different part of the codebase, you're in trouble. Obviously, this can happen in any language, but some enable it a lot more than others, and some make analyzing weird behaviour a lot easier than others.
csharptwdec19 6y ago
> That's why I'm using typed FP. Typed FP for Webdev is surprisingly enjoyable. Working with Frameworks/Stacks that translate FP code to HTML/JS is an absolute joy.
- greymalik 6y ago
  Do you have any favorites to recommend?
  - yakshaving_jgt 6y ago
    I know you weren’t asking me, but you didn’t get an answer so I’ll chime in. At work we use Yesod, and it’s been working great for us. A more detailed explanation of what we use can be found here[0]. [0]: https://serokell.io/blog/haskell-in-industry-riskbook https://serokell.io/blog/haskell-in-industry-riskbook
- c17r 6y ago
  Commenting so hopefully you'll get notified as I too would like more information. Based on your username, I'm guessing you are referring to F#.
simplify 6y ago
I generally feel the same way, but I've found Rails's testing setup is convenient enough to mitigate that uncertainty with relative ease. Writing some 3-5 line tests for each feature you write (which is necessary regardless of static testing) accomplishes a lot.
randomdata 6y ago
In the age of structured web APIs, the lack of types also makes generating those API services needlessly complicated. Rails was pretty nice in the days we were dumping out simple HTML pages on the fly, but those days are gone for most projects. While it has certainly tried, Rails has not done a good job keeping up with the times. A lot of that falls on the limitations of Ruby.
hardwaregeek 6y ago
While I agree that types are a great tool and ensure a level of robustness in your code, I do think there's tradeoffs. Rails offers a ease of use and robustness in infrastructure that is very compelling. I could write a web server in OCaml or Rust and it'd be wonderful code that has a lower rate of failure per line. But it may not have the same depth of logging, connection pooling, configuration, etc. I may have to write some of my own auth logic, as I had to do when dealing with JWTs in Rust. Do I trust myself to write auth logic? Even with types it's quite easy to write a logic error that leads to a vulnerability. Meanwhile I'm pretty certain Devise is rock solid. Also things just take longer in less mature stacks. I had a wonderful time writing a web server in Rust but I'll probably never do it again unless I need serious performance and Rust's libraries mature a little. And Rust's library ecosystem is a lot better than say, OCaml's or Haskell's. Robust code is great, but it's meaningless if you can't get stuff done.
- yakshaving_jgt 6y ago
  I've been getting stuff done in Haskell for several years now. The ecosystem is certainly mature enough for me.

aliante 6y ago

“I can’t be bothered to do anything properly. It must be a problem with Rails.”

AndrewDucker 6y ago
"I recognize that no human is fallible, so I use tools that don't assume infallibility"
- tluyben2 6y ago
  I think that's really the answer. We all mess up and using tools that make it easy to mess up is a problem... It will happen and it can happen in very bizarre ways.
- spanhandler 6y ago
  Safety aside, I find going back to “guess the source of the meta magical pattern-named method” intolerable these days. Onboarding to, taking over, or pinch-hitting in a Rails codebase is miserable unless it’s tiny and perfectly maintained by developers with excellent judgement and taste—and of course this is almost never the case.
yakshaving_jgt 6y ago
What does "properly" mean in this context? All of my income is from my own software businesses. I used to try to do this with Ruby, and there were lots of problems. Now I do it with Haskell, and there are fewer problems. This ended up being a very good business decision for me. What is the return on investment for me as a businessman on bothering to "do anything properly" when the resulting product is both cheaper to write and is more stable if I just use a better tool? What do I actually gain? Some kind of nerd-honour?

rgoulter 6y ago

I think "refactoring is much safer in strongly-typed languages" is a point against using Ruby. It's my understanding that some of what counts as "writing tests" in Ruby would be covered by static types in other languages. -- But it's also not the case that that having types excuses the developer from having tests. (Maybe with dependent types?). This point reminds me of some essays from Steve Yegge where he argued that one way of categorising programmers was into two groups: 'conservatives' who liked languages like Haskell where you could have confidence the code worked if it compiled, etc. and 'liberals' who liked languages like Ruby, where if you notice something breaks you just fix it; just write some feature to see if it works or not. -- I'd think for prototyping it's nicer to have the latter attitude, and it's more reasonable you'll have an understanding of the system since it's so fresh. For long term maintenance, the former is surely better

yakshaving_jgt 6y ago
I think you're right, and it was more Ruby (and other similar languages) that I was abandoning rather than Rails specifically. I like Rails. I can't speak for everyone, but my perspective comes from a place of practicality as opposed to philosophy. I (and also my team) try to push the domain we're modelling into the types, but we also write a whole bunch of tests (which includes isolated, integrated, and property-based tests). I've never understood the argument of one vs the other — it's great to have both. Programming is tough so I'll take all the help I can get.
jmchuster 6y ago
The Rails/Ruby community has probably the most developed testing culture out of all the programming communities out there, because tests are so critical when you're writing in a dynamic backend language. You don't have the built-in "tests" from a compiler that check every argument and method reference. And then you don't have as fast and obvious a feedback loop as you do with frontend languages.

brazzy 6y ago

It's not really about trust, not even about skill. I submit that this sentence: > Ruby allows for a lot of non-local effects. Whether that’s monkeypatching, writing to a database or creating new types at runtime, Ruby isn’t designed for a team of 200 programmers can and should end there, full stop. The bigger your team, no matter how skilled, the more often someone somewhere will make a mistake and cause side effects they didn't intend. And when these side effects can manifest in unfathomable and hard-to-analyze errors in a completely different part of the codebase, you're in trouble. Obviously, this can happen in any language, but some enable it a lot more than others, and some make analyzing weird behaviour a lot easier than others.

csharptwdec19 6y ago

> That's why I'm using typed FP. Typed FP for Webdev is surprisingly enjoyable. Working with Frameworks/Stacks that translate FP code to HTML/JS is an absolute joy.

greymalik 6y ago
Do you have any favorites to recommend?
- yakshaving_jgt 6y ago
  I know you weren’t asking me, but you didn’t get an answer so I’ll chime in. At work we use Yesod, and it’s been working great for us. A more detailed explanation of what we use can be found here[0]. [0]: https://serokell.io/blog/haskell-in-industry-riskbook https://serokell.io/blog/haskell-in-industry-riskbook
c17r 6y ago
Commenting so hopefully you'll get notified as I too would like more information. Based on your username, I'm guessing you are referring to F#.

simplify 6y ago

I generally feel the same way, but I've found Rails's testing setup is convenient enough to mitigate that uncertainty with relative ease. Writing some 3-5 line tests for each feature you write (which is necessary regardless of static testing) accomplishes a lot.

randomdata 6y ago

In the age of structured web APIs, the lack of types also makes generating those API services needlessly complicated. Rails was pretty nice in the days we were dumping out simple HTML pages on the fly, but those days are gone for most projects. While it has certainly tried, Rails has not done a good job keeping up with the times. A lot of that falls on the limitations of Ruby.

hardwaregeek 6y ago

While I agree that types are a great tool and ensure a level of robustness in your code, I do think there's tradeoffs. Rails offers a ease of use and robustness in infrastructure that is very compelling. I could write a web server in OCaml or Rust and it'd be wonderful code that has a lower rate of failure per line. But it may not have the same depth of logging, connection pooling, configuration, etc. I may have to write some of my own auth logic, as I had to do when dealing with JWTs in Rust. Do I trust myself to write auth logic? Even with types it's quite easy to write a logic error that leads to a vulnerability. Meanwhile I'm pretty certain Devise is rock solid. Also things just take longer in less mature stacks. I had a wonderful time writing a web server in Rust but I'll probably never do it again unless I need serious performance and Rust's libraries mature a little. And Rust's library ecosystem is a lot better than say, OCaml's or Haskell's. Robust code is great, but it's meaningless if you can't get stuff done.

yakshaving_jgt 6y ago
I've been getting stuff done in Haskell for several years now. The ecosystem is certainly mature enough for me.