I've just recently started playing with go and I think the most impressive part is how close you can get to a dynamic language development feel without sacrificing the benefits of static compilation, speed, binary distribution, etc.<p>There is a lot to love about go and it is very quickly starting to look a lot more interesting than other languages like ruby for future projects.
And for people who want to "level up" their programming skills and get an excellent language for writing servers in with a great faculty for safely concurrent semantics:<p><a href="http://clojure-doc.org/articles/content.html#clojure_tutorials" rel="nofollow">http://clojure-doc.org/articles/content.html#clojure_tutoria...</a>
Tried the language recently. Wanted a in-memory data structure that could represent a filesystem-like graph. Ran away when I understood (please correct me if I got that wrong, but I wasted a whole weekend and found nothing) that it's either totally type-unsafe void*^H^W interface{} all the way or I have to write my own separate implementation for every and each type of graph I'll use, without any significant way to reuse code.
<a href="http://i.lvme.me/4gl8uip.jpg" rel="nofollow">http://i.lvme.me/4gl8uip.jpg</a><p>The up-to-date Go Users page is at <a href="http://code.google.com/p/go-wiki/wiki/GoUsers" rel="nofollow">http://code.google.com/p/go-wiki/wiki/GoUsers</a>
Taken from the article:<p>> "Strongly typed (with dyamic casting)"
> "while Go is statically typed, it has a strong system for dynamic casting and reflection".<p>This is not even wrong. The <i>whole</i> point to using types is to make strong <i>guarantees</i> about the meaning of programs without even having to run them. Dynamic casting and reflection <i>destroy</i> the usefulness of these guarantees, by virtue of their semantics depending on information only avaluable at runtime. Strong typing with dynamic casting and reflection is like a safe knife whose handle is a blade!<p>> "Really good at concurrent stuff, pretty fast"<p>Give me a break. Concurrency support is all about compartmentalizing the use of resources as much as possible, reducing sharing between the concurrent units of computation (processes, tasks, goroutines, whatever you want to call them) to the bare minimum required for the program as a whole to serve its goal. How does Go's shared memory model help in this regard? This fundamental inadequacy has negative consequences both for correctness (synchronization is a convention, it is not actually enforced) and for performance (Go needs a stop-the-world garbage collector).<p>===<p>Go might have been barely interesting ten or fifteen years ago, but in 2013, this kind of design has to be rejected as mediocre.
For people who use go in production; what do you use for database abstraction and mapping ? I found several "ORM" but either they throw static typing out the window, or they seem to be way overblown in what they try to do (ending up dictating how some of the data has to look in the database), I look only for a database abstraction (which db/sql doesn't provide), does a good one exists ?
"This isn’t a language for use in UIs or game clients, but it is an extremely competent language for making servers, infrastructure or parallel/distributed processing systems."<p>Golang has a GUI tool kit: the "net/http" and "html/template" packages. While I personally hate EcmaScript with a passion, I have to admit every single GUI tool kit or windowing system I've worked with had serious fundamental design flaws not unlike JavaScript and the DOM.
The entire scenario is not unlike the Tcl\Tk days. People will bitch and whine but will do so while using it until something better comes up.
There sure has been a ton of Golang hype lately. At the risk of being downvoted, just wanted to add my 2 cents: seems obvious to me that Google's PR team has been in full motion on Go lately. At the very least, there are quite a few Google fans active on HN routinely pushing Go. Which is no problem of course.<p>I just find this somewhat frustrating given that we also have the massive NSA surveillance scandal unfolding. Because I'd like to think that intelligent, free-thinking hackers would opt for using products & technologies from companies & organizations not so directly, deeply, and intricately involved in said scandal.<p>Anyway, kudos to Dan for his detailed article - I'm sure he could care less about the political alignment of the corporation he is getting his tools from - and really it should be about technology first; so if Golang fits his needs most optimally then by all means that's what he should be using. Just saying, don't forget about the alternatives ;)