What made Go click for me is a simple realization: it's a language made by systems people, not by PL researchers.
Everything makes sense after that. The language in isolation is boring and perhaps even anachronistic: a modern ALGOL dialect with first-class green threads.
But as many people have said, the tooling and the libraries are simply top-notch. This is unsurprising: the people behind Go all have experience with things such as Research Unix, Plan 9 and just infrastructure in general. They've been instrumental in shaping up the lower level workings of our present systems, so they're intimately aware of those aspects. 9P, Acme, rio, the Acid debugger, the Plan 9 compiler collection... among other tools, reflect that their brilliance is in engineering rather than science.
But more importantly: these people are experts in managing complexity and integrating things. Thus, in isolation, Go's components look bland and uninteresting. Cumulatively, they form a unique experience. Hence why Go has such a strong culture of "pragmatism" that a lot of PL geeks scoff at.
So I've pretty much stopped thinking of Go the language, but rather Go the toolchain.
I've not been a huge fan of Go (more of a Rust person). However, seeing these authors, I'm now itching to get my hands on a copy of this book and give Go another shot.
I wish I didn't have to wait until the summer for it!
Edit: Also, I realize it's unfair to compare Rust to Go, since they really fill two different PL niches. I actually think there is plenty of room for both languages. By my statement above, I just meant that I'm more drawn to Rust's functionally-influenced approach than Go's modern take on the imperative paradigm.
Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.
I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool.
Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitives, decent stdlib and tooling make Go pretty great to use in some respects. It's likely to be well-supported for a long time and is a suitable tool for many tasks.
On the flipside, using it often feels like a bit of a slog. Error handling is simple (good) but repetitive (bad). Keeping generics out of the language avoids complexity (good) but results in repetitive and awkward code (bad). Lack of features like pattern matching and higher-order functions makes some code irritatingly tedious to read and write. And so on.
Point is, it's perfectly valid to look at these decisions and say "I don't like Go because it is missing these features", as much as it's valid to say "The simplicity of Go is a useful feature". Ignorance is not a prerequisite for disagreement.
So please have some respect for opinions which differ from your own, and think about offering something a little more constructive than insults.
I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+).
Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not to say Go is a perfect (e.g. a 'real' debugger option), and it doesn't have to be. If you love Rust, or Ruby, or whatever, great. The programming language landscape is not a zero sum game.
tl;dr Go's a fine tool to get stuff done for a large set of problem domains.
I can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."
You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens with Haskell and at some point with Rust. In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed.
Note: Rust actually has a chance because it's simple compared to its competition: modern C++.
This is the first time I've seen the Blub Paradox [1] portrayed as ignorance from the other direction!
OK, not a big believer of the "Blub" theory, personally - every language has its place in a continuum of dimensions that are more than just technical, and I actually like Go overall. But "lack of generics" is definitely not the same as "simplicity. Not in the decade we live in.
I've been coding Go professionally now for about 8 months. Interestingly, it has made me appreciate C++. The reason is while the Go compiler is fast, it is mostly because it doesn't do very much work. By contrast, a C++ program takes a long time to compile because the compiler does a lot. It's obviously not as black/white as I've portrayed it here for brevity, but it is nevertheless an apparent trade off.
I like Go overall, but on balance I would prefer a slower compile-test cycle to have more language feature support.
My only real issue with it is that I really with it had algebraic types. That would save me a tonne of faffing about and help make code safer to boot. Type switches are a clumsy alternative that only cover some of the cases.
Simple languages are good, but we should be careful to understand why they are simpler: in many cases, the complexity is simply shifted from the language onto the programmer.
Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.
but I don't even pay attention to the negative comments anymore
The "not quite a field" of programming, has a famous history of being full of smarmy naysayers being spectacularly wrong. It's no wonder that the few of us who aren't bratty and quickly judgemental tend to become famous and successful. (Nor that a famous blogger once said that everything he needed to know about managing programmers, he learned from the book, "How to Talk to Your Five Year Old.")
Maybe part of the problem is that people that promote Go in some capacity will at times make good arguments for certain things, but when they find something that they can't really explain, or that might seem subpar, they devolve their argument into some kind of appeal to authority - 'who am I to question their decisions. These are experienced, respected programmers with a lot of accomplishments. Who are anyone born after 1985 to judge them, really?'
So maybe you'll excuse some people for not simply assuming that the masters are right just by virtue of who they are.
Regardless of how I feel about Go as a language... I don't trust Google to perform well as the steward. It may be open source, but that means nothing if people stop working on it.
If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only time will tell.
>Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language.
It's mostly the wisdom of the eighties. Today's professionals have better options.
Now I can resist every publisher that wants me to write a book on Go, and tell myself that was OK to do because I'd never write as good a book as those two.
For those who didn't try it yet here are the biggest advantages of Go:
- it's totally easy to learn and can be mastered in a day
- it's fast and typesafe
- the concurrency model is great,no question
- I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types
- it has, in my opinion a comprehensive standard library,you can even do websockets and image compression with it.
The draw backs :
- no generics clearly the biggest drawback, which means a lot of copy and paste
- the lack of idiomatic way to deal with dependencies(no defacto package manager)
I think the ease of use justifies Go adoption in any team. It doesn't replace ruby or python for web programming ( little value in coding a CMS in Go , rails makes more sense),but when it comes to backend or webservices, it's a killer tool.
compared to java, it's as fast and consumes WAY less memory.
Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about.
> the lack of idiomatic way to deal with dependencies(no defacto package manager
Again, is this really a big deal? There's plenty of options, and if you are shipping any-type of commercial product you are going to want to be vendoring your dependencies in-house anyway. In which case, depending on something like NPM/remote maven repos is not a viable options anyway.
I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual.
For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust.
Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for.
I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least.
I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.
Don't forget about the tooling: unit testing, benchmarking, generated documentation, code formatting, and emacs+vim plugins are included in the official package. I think these are often overlooked when describing its benefits. You can jump in and start working right away.
In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors:
func PublicEntryPoint(input string) (output []byte, err error) {
defer func() {
if e := recover(); e != nil {
output = nil
err = e
}
}()
err = nil
output = privateFunc(input) // no need to check for error here
return
}
func privateFunc(input string) []byte {
foo := otherPrivateFunc(...) // no need to check for error here
// ...
}
func otherPrivateFunc() int {
// ...
panic(fmt.Errorf("Something is wrong"))
}
I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.
I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version) They all have their ups/downs and mostly it has to do with the language they are supporting.
Nodejs:
+ transparent code on download
- virtually impossible to mirror
- executes arbitrary 'script' blocks that install stuff on your system
- subpar transitive dependency management scheme
Java:
+ great transitive dependency management
+ private repos/mirrors are easy with well supported tools
- black box byte code with no licenses
- overly complicated software (ivy/maven)
Python (pip):
+ simple and easy
- virtual environment hell
There are things that i like and don't like with go get:
+ dirt simple and used from the command line
+ code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap.
+ I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people).
- code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled.
Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.
The lack of a package manager is a good thing, since this is the job of the operating system. That Windows and OSX have crappy/nonexisting package managers does not mean every language should roll its own.
If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.
I was a bit surprised by the length. Not a huge difference, but one of the best things about the K&R book was how short it was. But, I too have been been curious to look into Go. This might be the excuse I needed.
YES. I read and re-read the original K&R (The C Programming Language) book many times as a child. It's one of my favorite tech books ever written: clear, concise, challenging, useful.
I've recently started writing more and more code in Go, for simple performance reasons, and it'd be amazingly great to relive the K&R wonders of my childhood with a new language =)
I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.
I actually have to say I wasn't familiar with this author having never spent time in C. After some Googling I'm excited to see he's fellow Canadian and looks to be a pioneer in computing as well. It also seems he's worked with Rob Pike, another fellow Canadian :)
"Good Programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of common sense and good programming practices. Careful study and imitation of good programs leads to better writing." - [1]
I'm a huge fan, have nearly everything Kernighan's been involved with, and have profited greatly from his writing. I look forward to picking up the Go book, and modernizing a bit.
[1] 'Software Tools', Brian Kernighan, P.J. Plauger, 1976
In my personal view, I find it disappointing that someone like Brian Kernighan, as a co-author of C, only got as far as Go. I would have loved it much more to see him working on a language like Rust, that actually seems to point to the future of programming languages (or does its best at it), while Go looks like a stopgap and a dead end right from the beginning.
Go seems a fine piece of engineering in so far as it directly implements Google politics & some of their technical interests, but it's of little use outside of that, despite all the hype. A pity, really.
It has been a long time since I bought a hardcopy programming book. Alternate forms of documentation and a Safari subscription have replaced these semi-frequent purchases. And although I can't argue against the practicality and economics of this new way, it certainly evokes none of the excitement of getting the new language book home, cracking the binding, and spending the rest of the evening curled up on the couch.
Go has been my most used new language and the timing of this book is good. I'm looking forward to adding it to my (real) bookshelf.
The book is the #1 Best Seller in Computer Programming Languages and it's not even been released yet.. wow! I'm studying their C book right now for a university class, probably going to pick this one up right after.
[+] [-] vezzy-fnord|11 years ago|reply
Everything makes sense after that. The language in isolation is boring and perhaps even anachronistic: a modern ALGOL dialect with first-class green threads.
But as many people have said, the tooling and the libraries are simply top-notch. This is unsurprising: the people behind Go all have experience with things such as Research Unix, Plan 9 and just infrastructure in general. They've been instrumental in shaping up the lower level workings of our present systems, so they're intimately aware of those aspects. 9P, Acme, rio, the Acid debugger, the Plan 9 compiler collection... among other tools, reflect that their brilliance is in engineering rather than science.
But more importantly: these people are experts in managing complexity and integrating things. Thus, in isolation, Go's components look bland and uninteresting. Cumulatively, they form a unique experience. Hence why Go has such a strong culture of "pragmatism" that a lot of PL geeks scoff at.
So I've pretty much stopped thinking of Go the language, but rather Go the toolchain.
[+] [-] eric_bullington|11 years ago|reply
I wish I didn't have to wait until the summer for it!
Edit: Also, I realize it's unfair to compare Rust to Go, since they really fill two different PL niches. I actually think there is plenty of room for both languages. By my statement above, I just meant that I'm more drawn to Rust's functionally-influenced approach than Go's modern take on the imperative paradigm.
[+] [-] latch|11 years ago|reply
That said, maybe The Little Go Book (http://openmymind.net/The-Little-Go-Book/) can tide you over until summer.
[+] [-] TazeTSchnitzel|11 years ago|reply
Edit: Hmm, perhaps I should dust off that copy of K&R and continue from where I left off? :D
[+] [-] pjmlp|11 years ago|reply
Just have to think if I still want the classic hardcover version or go for the Kindle version when available.
[+] [-] higherpurpose|11 years ago|reply
[+] [-] sesteel|11 years ago|reply
[+] [-] matthewmacleod|11 years ago|reply
Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitives, decent stdlib and tooling make Go pretty great to use in some respects. It's likely to be well-supported for a long time and is a suitable tool for many tasks.
On the flipside, using it often feels like a bit of a slog. Error handling is simple (good) but repetitive (bad). Keeping generics out of the language avoids complexity (good) but results in repetitive and awkward code (bad). Lack of features like pattern matching and higher-order functions makes some code irritatingly tedious to read and write. And so on.
Point is, it's perfectly valid to look at these decisions and say "I don't like Go because it is missing these features", as much as it's valid to say "The simplicity of Go is a useful feature". Ignorance is not a prerequisite for disagreement.
So please have some respect for opinions which differ from your own, and think about offering something a little more constructive than insults.
[+] [-] CatDevURandom|11 years ago|reply
Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not to say Go is a perfect (e.g. a 'real' debugger option), and it doesn't have to be. If you love Rust, or Ruby, or whatever, great. The programming language landscape is not a zero sum game.
tl;dr Go's a fine tool to get stuff done for a large set of problem domains.
[+] [-] theseoafs|11 years ago|reply
[+] [-] ceronman|11 years ago|reply
Note: Rust actually has a chance because it's simple compared to its competition: modern C++.
[+] [-] throwawaykf05|11 years ago|reply
OK, not a big believer of the "Blub" theory, personally - every language has its place in a continuum of dimensions that are more than just technical, and I actually like Go overall. But "lack of generics" is definitely not the same as "simplicity. Not in the decade we live in.
1. http://c2.com/cgi/wiki?BlubParadox
[+] [-] sbt|11 years ago|reply
I like Go overall, but on balance I would prefer a slower compile-test cycle to have more language feature support.
[+] [-] talideon|11 years ago|reply
[+] [-] mateuszf|11 years ago|reply
[+] [-] gnuvince|11 years ago|reply
Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.
[+] [-] stcredzero|11 years ago|reply
The "not quite a field" of programming, has a famous history of being full of smarmy naysayers being spectacularly wrong. It's no wonder that the few of us who aren't bratty and quickly judgemental tend to become famous and successful. (Nor that a famous blogger once said that everything he needed to know about managing programmers, he learned from the book, "How to Talk to Your Five Year Old.")
[+] [-] Dewie|11 years ago|reply
So maybe you'll excuse some people for not simply assuming that the masters are right just by virtue of who they are.
[+] [-] aros|11 years ago|reply
[+] [-] GFK_of_xmaspast|11 years ago|reply
[+] [-] WorldWideWayne|11 years ago|reply
If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only time will tell.
[+] [-] meddlepal|11 years ago|reply
[+] [-] coldtea|11 years ago|reply
It's mostly the wisdom of the eighties. Today's professionals have better options.
[+] [-] jgrahamc|11 years ago|reply
Now I can resist every publisher that wants me to write a book on Go, and tell myself that was OK to do because I'd never write as good a book as those two.
[+] [-] vixen99|11 years ago|reply
[+] [-] sgt|11 years ago|reply
[+] [-] aikah|11 years ago|reply
For those who didn't try it yet here are the biggest advantages of Go:
- it's totally easy to learn and can be mastered in a day
- it's fast and typesafe
- the concurrency model is great,no question
- I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types
- it has, in my opinion a comprehensive standard library,you can even do websockets and image compression with it.
The draw backs :
- no generics clearly the biggest drawback, which means a lot of copy and paste
- the lack of idiomatic way to deal with dependencies(no defacto package manager)
I think the ease of use justifies Go adoption in any team. It doesn't replace ruby or python for web programming ( little value in coding a CMS in Go , rails makes more sense),but when it comes to backend or webservices, it's a killer tool.
compared to java, it's as fast and consumes WAY less memory.
[+] [-] CatDevURandom|11 years ago|reply
Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about.
> the lack of idiomatic way to deal with dependencies(no defacto package manager
Again, is this really a big deal? There's plenty of options, and if you are shipping any-type of commercial product you are going to want to be vendoring your dependencies in-house anyway. In which case, depending on something like NPM/remote maven repos is not a viable options anyway.
[+] [-] BuckRogers|11 years ago|reply
For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust.
Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for. I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least.
I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.
[+] [-] wallyhs|11 years ago|reply
In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors:
I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.[+] [-] ascotan|11 years ago|reply
Nodejs:
+ transparent code on download
- virtually impossible to mirror
- executes arbitrary 'script' blocks that install stuff on your system
- subpar transitive dependency management scheme
Java:
+ great transitive dependency management
+ private repos/mirrors are easy with well supported tools
- black box byte code with no licenses
- overly complicated software (ivy/maven)
Python (pip):
+ simple and easy
- virtual environment hell
There are things that i like and don't like with go get:
+ dirt simple and used from the command line
+ code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap.
+ I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people).
- code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled.
Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.
[+] [-] doomrobo|11 years ago|reply
[+] [-] semi-extrinsic|11 years ago|reply
If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.
[+] [-] chrisallick|11 years ago|reply
[+] [-] rdegges|11 years ago|reply
I've recently started writing more and more code in Go, for simple performance reasons, and it'd be amazingly great to relive the K&R wonders of my childhood with a new language =)
Just pre-ordered a copy, can't wait.
[+] [-] meddlepal|11 years ago|reply
[+] [-] kylek|11 years ago|reply
[+] [-] wsloth514|11 years ago|reply
[+] [-] cdnsteve|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] cyber1|11 years ago|reply
[+] [-] chiph|11 years ago|reply
[+] [-] frou_dh|11 years ago|reply
(There's the Bell Labs connection of course)
[+] [-] beisner|11 years ago|reply
[+] [-] waitingkuo|11 years ago|reply
[+] [-] pjmorris|11 years ago|reply
I'm a huge fan, have nearly everything Kernighan's been involved with, and have profited greatly from his writing. I look forward to picking up the Go book, and modernizing a bit.
[1] 'Software Tools', Brian Kernighan, P.J. Plauger, 1976
[+] [-] tempodox|11 years ago|reply
Go seems a fine piece of engineering in so far as it directly implements Google politics & some of their technical interests, but it's of little use outside of that, despite all the hype. A pity, really.
[+] [-] LVB|11 years ago|reply
Go has been my most used new language and the timing of this book is good. I'm looking forward to adding it to my (real) bookshelf.
[+] [-] crncosta|11 years ago|reply
[+] [-] FanaHOVA|11 years ago|reply