6 ms·
The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what
by zeeboo 13y ago
The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.
- Arnor 13y agoThat's what's awesome about it! Everybody who uses it gets the same impressions of it (EDIT: and those impressions are 95% good). What other language has that going for it?
- asdasf 13y agoWhat? Everyone coming from python/ruby/javascript maybe, but there's also a heck of a lot of us who wanted to like go but find it too primitive and inexpressive. I tried go while I was still a confused haskell noob, and I still had to go back to haskell. I can't imagine how bad go must feel to an experienced haskell dev.
- Peaker 13y agoI 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).
- cgag 13y agoI think Peaker is right, I think a lot of us who are coming from Clojure/Scala/Haskell/Ocaml/etc don't bother writing blog posts that we're unimpressed.
- adw 13y agoI'm a Python guy, and there's something in this, I think. One of Python's underrated virtues is how uncontroversial a lot of Python idioms are. The "only one way to do it" attitude helps there. In my (limited, biased) experience, there's three camps among the Python community: 1. people who want principle-of-least-surprise: there's a lot to be said for boring languages (if the language is the most interesting thing about your product...). Often the systems engineering/service engineering crowd. 2. people who want it to be more functional – the Haskell/Scala/ML crowd. (I guess the overlap between camp 1 and camp 2 is Erlang...) 3. people who want access to the library ecosystem, particularly the Numpy/Scipy/Pandas/Theano stack (the scientific community, latterly data scientists). This is my tribe. So you've got three crowds here, at least, unified by a language. Where are they going to head? Go has nothing for the second crowd; they're all going to go to a purer FP language sooner or later. It doesn't have much for the third (no IPython, LAPACK bindings, Fortran bindings, stats libraries, machine learning, etc...); we all have an eye on Julia. But for the first: great deployment story, small language, decent standard libraries, markedly better performance than Python, much better parallelism story...
- stcredzero 13y agoAs someone else noted below, it's also like "static typing lite." It has most of the advantages of static typing with much less of the bookkeeping involved.
- Peaker 13y agoML-style languages go much further with this, while also having richer type systems that both let you write code more easily and do more compile-time safety verifications.
- biinui 13y agomay i know what other languages interests you?