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.
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.
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.
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
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.
Typed FP for Webdev is surprisingly enjoyable. Working with Frameworks/Stacks that translate FP code to HTML/JS is an absolute joy.
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].
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?