The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out. As I said, the team was fully functional, in production, low bug rate, generally happy.
Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).
The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.
So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.
> The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out.
Yeah, but if the stack was something common then it still wouldn't be as big a problem.
I think you're missing my main point which is that it didn't happen. The project was successful and chugging along.
It was only when a drive-by principal engineer got wind of it that there were problems. "We don't use Haskell here" was literally the only argument for rewriting it. Nobody left before then. We were hiring people fine. The problems you are FUDing around didn't exist.
In fact, the rewrite was so slow and off-target that I had to maintain the Haskell project through a peak season with a skeleton crew of two other people who didn't leave. And we didn't even have an outage - I didn't even get paged! The project got to make the company millions of dollars yet again.
When the rewrite finally started to form, it actually had significantly less functionality than the Haskell implementation. The internal users complained so much about that. And it took just as long to create. What a failure that rewrite was.
In the end, it was the attitude you are espousing that killed the project, not anything technical or hiring-/team-building-wise. It was literally just an opinion not to use Haskell by a guy who couldn't be bothered for the life of him to try to understand it.
Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer.
I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.
Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.
I guess the problem with Haskell is not really hiring, but it is simply a very hard sell to people without academic background. Haskell is for sure elegant, and has some cool features, but this is too little to get wide adoption.
Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).
So "bug rate" is not a real hard metric anyways. And I only have my experience to go on.
But I will say that bugs in Haskell tend to be easier to diagnose (helpful at 2am) and aren't usually bad (although they can be). I have debugged Other People's Code while on-call in Haskell way easier than any other language.
And finally, the vast majority of bugs can be prevented or curbed by the type system. I find every time a Haskell company runs into a nasty bug or annoying issue, libraries that make use of the type system are made that reduce or remove that class of bug entirely. This sounds like you can do it in every language, but really what can be made a "library" in Haskell dwarfs what you can reasonably library-ify in most other languages.
Now, I can't give quantitative evidence of this because I don't even know how I would begin to measure it. But these qualities are definitely a big reason why I don't even listen to job offers that aren't Haskell anymore (going on 10 years of that soon) and I have and will promptly quit a job if the company moves off Haskell.
> I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.
And then you lose 50k whenever the app crashes in production because someone forgot a nil/err check and your tests didn't catch it. Or you pay extra 50k whenever the whole team needs to spend a week on finding a race condition caused by someone accidentally mutating a shared slice, 20 layers below the place the corruption was seen for the first time. Or you spend extra 50k over the year for fixing all the resource leaks caused by missing defers. Or you spend 50x50k to rewrite everything in a more performant stack because of GC pauses (Discord) ;).
There are multiple ways a project can fail or add unexpected costs, and likely there's no silver bullet. There are trade-offs.
And, btw, as for simplicity, there are dozens of languages easier to learn than Go. E.g. scratch, basic, brainfuck. Why not use them? ;)
Simplicity of a language has it costs. Programs written in simpler languages tend to be more complex to compensate for lower expressive power.
Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).
The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.
So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.