3 ms·
I think there's a survival-bias/selection-bias here. Those who tried Go and came from a background of more advanced languages just threw it away quickly and wr
by Peaker 13y ago
I think there's a survival-bias/selection-bias here.
Those who tried Go and came from a background of more advanced languages just threw it away quickly and wrote nothing about Go.
- jzelinskie 13y agoI've seen a few Haskellers finding similarities and praising Go[1]. Go is just meant to be practical and familiar to most working engineers and all the articles are going to reflect that. Most of the people coming from "advanced languages" are looking for new paradigms to move forward. When it comes to Go, there really isn't much to talk about besides the maturation of the toolchain. [1] http://www.starling-software.com/en/blog/my-beautiful-code/2009/11/22.the-go-language.html http://www.starling-software.com/en/blog/my-beautiful-code/2...
- Peaker 13y agoThe plenty of Haskellers I know have all expressed disinterest in Go as a poorly designed language. The linked post seems to be a very superficial take of Go. I wonder if he'd keep his opinion of Go after learning about lack of generics, error product types, nulls, mutability of concurrent messages, and all the other show stopper design mistakes...
- jzelinskie 13y agoAs an aside, that article says that Haskell can't guarantee Monads to also be Functors. Is that a language problem or library problem?
- tikhonj 13y agoThat's purely a library oversight which has become mired in backwards compatibility (don't track any of that onto my carpet :P). It would be trivial to specify that all Monads are also Functors by changing the definition of the Monad class a little bit: class Functor m => Monad m where
- Peaker 13y agoIt's a library/compatibility problem, and it's (finally) being addressed now (will take years until the change takes place, need deprecation warnings for a loong time).