Well, it's good to have a hard-compiled language that's (almost) memory safe. Three problems with Go:<p>- The Go mantra is "share by communicating, not by sharing". Then look at all the thread examples in "Effective Go". They all share memory, while trying to construct locks using message passing. Multi-threaded Go programs are not memory-safe. That's why Google won't let you use them on their AppEngine. Compare Erlang, which takes message passing seriously.<p>- The lack of exceptions is resulting in hacks using the "panic" mechanism to create an exception mechanism. This is where we were with "longjmp" in C. I know someone at Google who has constructed a language on top of Go mostly to deal with exceptions.<p>- The lack of generics is resulting in hacks using the reflection mechanism to create generics. This is painful and slow. Go has generics for built-in objects; channels and maps are parameterized types, so there's already syntax for instantiating a parameterized type. Extending that to user-defined types would not be too bad. Fear of the C++ template mess seems to have been the problem.
Reading this I feel Go is boring, and that's an asset. Let me explain.<p>Seeing [what's happening in Haskell (GHC)](<a href="https://www.haskell.org/pipermail/ghc-devs/2014-October/006518.html" rel="nofollow">https://www.haskell.org/pipermail/ghc-devs/2014-October/0065...</a>), which is soooo much more exciting; but then I totally understand that "exciting" is what you want to stay away from in some cases. In these cases a Go is a much better choice I guess.
Here's an interesting portion of a Q&A panel from the same dotGo 2014 conference (<a href="http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-management-design-philosophy" rel="nofollow">http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...</a>)<p>Q: There are several dependency management tools in the wild: godep, gpm, etc. Are there any plans to provide this functionality in the core?<p>Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community fights it out and a victor emerges. Then maybe we’ll bless that one. Then if everyone likes it and it has been stable for a couple of years, maybe we’ll add it to the core.<p>Brad Fitzpatrick: Part of the reason why we don’t care as much about dependency management inside Google is that we don’t use the go tool inside Google.<p>Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs.
This is a summary of a talk from the dotGo conference in Paris last week. Lots of good stuff was presented there. Recommend reading the other posts by sourcegraph on this and watching the videos when they come out.<p><a href="http://dotgo.sourcegraph.com/" rel="nofollow">http://dotgo.sourcegraph.com/</a>
How about a better optimizing compiler? I've been using Go and everything feels quite snappy. Justifying it use over Java on the server-side, for example, might require a little more supporting data.
Regarding the article's mention of GopherJS: The Google Dart project should adopt Go as its language and reboot. Dart hasn't gone anywhere. GopherJS is a great low-budget transpiler and its source could be incorporated into a Go-based Dart.<p>It would be great to see what could be accomplished with a big-budget GopherJS.
I've been writing Go for the past couple weeks and have really enjoyed it. My day jobs is in JavaScript land all day long, and while I really love JS I was looking for something more. Go has helped me think differently about how I approach my code in JS now and continues to be a great source of knowledge.
Anybody up for backporting Go's stdlib to C? Doing so in an automated way would be all the better.<p>There are just so many things in Go that feel like 80% solutions - they make great demos but in every day use you have to fight them (looking at you import system and the GOPATH, magical make() function, magical overloaded accessors, lack of expressions or at least ternary if, pre and post increment are hacks not expressions, lack of coercion to more precise types, no templating / generics / preprocessing, needs an equivalent to realloc, having to go through reflect / unsafe to get things done, lack of proper type resolution for complex types).<p>There are many things I do like about Go, but much of the time it feels like a very pretty prison compared to the (admittedly less pretty) freedom of C.
> GOTRACE: emits Chrome trace viewer and will allow for us to visualize scheduler actions and more in Chrome<p>I'm very excited about this, but I wonder if it will scale to visualize hundreds to thousands of goroutines in a useful way. That's where existing inspection tooling like logging and snapshotting goroutine dumps fall apart.
I see he mentions "beginnings of Android support". This is something I would love to see. Does anyone know if there is a product roadmap that provides a timeline on this?