> it's worth mentioning that Semantic, as a rule, does not encounter runtime crashes: null pointer exceptions, missing-method exceptions, and invalid casts are entirely obviated, as Haskell makes it nigh-impossible to build programs that contain such bugs.
This I think is the real drug of Haskell.
There are lots of challenges involved with moving to Haskell for production software, and the article notes some of them. But once your code builds and you ship -- man, there is nothing remotely like it. v1.0 software running for weeks in prod without a bug.
Then, the super-sauce is: maintainers don't break your already-working code. Sure new code might have bugs, and deep semantic changes to code can break anything, but workaday fixes to one corner of the codebase simply can't break all the other corners. v2, v3, v4 all migrate to production with none of the working stuff falling over.
PS I don't buy that the "control flow" feature couldn't have been done in Java -- however I would bet huge dollars that you couldn't do it in a way that wouldn't require massive investment in maintainers understanding a complex and subtle data-driven control flow pattern that any single dev could easily subvert, intentionally or not. I was a huge fan of FP-style coding in Java, but it required buy-in from all maintainers; as soon as somebody got lazy and went back to mutability etc there was nothing to stop them.
There's another "real drug" hidden in the subtext of your post and Semantic's post, right in between
"Sure new code might have bugs, and deep semantic changes to code can break anything..."
and
"Its language features allow concise, correct, and elegant expression of the data structures and algorithms we work with."
- the notion that fundamental abstractions (not just the ones someboy thought up like the Gang of Four) compose well. This is something that we've seen the industry slowly migrating towards in the form of functional JS flavors like typescript and purescript, Java's lambdas, Scala's Cats and so on.
The ability to refactor and as importantly be confident that your refactor is not messing with the semantics of anything upstream is a hidden feature of static types applied to expressive abstractions.
So far, I have only seen this achieved with Haskell's libraries, type system, and reliance on fundamental mathematical concepts while also being able to avoid any "there's something rotten in Denmark" moments. The content in the Hackage ecosystem is a wonder of the modern programming world, warts and all.
There are many rough edges to the development process, as always, but at least in Haskell you can limit the language's contributions to that edgeset. It actually makes you want to produce good code and be a better developer as a result!
This I think is the real drug of Haskell.
There are lots of challenges involved with moving to Haskell for production software, and the article notes some of them. But once your code builds and you ship -- man, there is nothing remotely like it. v1.0 software running for weeks in prod without a bug.
Then, the super-sauce is: maintainers don't break your already-working code. Sure new code might have bugs, and deep semantic changes to code can break anything, but workaday fixes to one corner of the codebase simply can't break all the other corners. v2, v3, v4 all migrate to production with none of the working stuff falling over.
PS I don't buy that the "control flow" feature couldn't have been done in Java -- however I would bet huge dollars that you couldn't do it in a way that wouldn't require massive investment in maintainers understanding a complex and subtle data-driven control flow pattern that any single dev could easily subvert, intentionally or not. I was a huge fan of FP-style coding in Java, but it required buy-in from all maintainers; as soon as somebody got lazy and went back to mutability etc there was nothing to stop them.