5 ms·
I agree with the spirit of what you're saying. Too often I've seen folks on HN dismiss languages because they didn't have features X or Y, usually with a condes
by nindalf 8y ago
I agree with the spirit of what you're saying. Too often I've seen folks on HN dismiss languages because they didn't have features X or Y, usually with a condescending "maybe this language's creators should read some PL theory". I remember circa 2013 or 2014, it became impossible to read threads related to Go because the entire thread would always be "a Real Language(TM) needs Generics". Look at the success Go has seen in the last decade while doing the opposite of what HN thought was correct.
That said, there do exist useful products written in Haskell. For example, Facebook writes a lot of spam fighting code in Haskell. https://code.fb.com/security/fighting-spam-with-haskell/ https://code.fb.com/security/fighting-spam-with-haskell/
- willtim 8y agoThe lack of "generics" (parametric polymorphism) in Go has certainly made the incidental complexity in Kubenetes much higher: https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i... Go and Haskell are really at different ends of a spectrum. Haskell is a very high level language, which makes building and reasoning about very complex software much easier (at the expense of a learning curve and fine control of space usage). Go is a low-level language with no learning curve and a very limited facility to abstract (by design it seems). Personally I would have written something like Kubenetes in Haskell or OCaml, with perhaps the odd performance critical section in C or Rust.
- dsirola 8y agoIt's part of the Blub Paradox[1]. If you don't know about better things, you won't miss them. But once you do know about more powerful things, it's hard to go back to living without them. [1] http://paulgraham.com/avg.html http://paulgraham.com/avg.html