21–30 of 233 posts
er, they left a couple things out of the family tree (page xii). Like C++, Java, C#, ...
To those in the Go community: - What is Go well suited for other than network programming? - Why might one decide to write the backend API of their web app in Go, compared to say Grails, Python etc.
This, barely, outweighs the massive amount of boilerplate that permeates a golang repository over time.
Overall it was a net positive choice.
From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."
Sort of the anti-Perl? I say this as someone who likes both Perl and Go.
Go is very contrarian, and I applaud this.
To those in the Go community: - What is Go well suited for other than network programming? - Why might one decide to write the backend API of their web app in Go, compared to say Grails, Python etc.
Other than some quite significant performance gains, I'd say the main upside for the case of a backend API would be channels. Concurrency is dead simple in Go - and if you want to do 5 different requests to ElasticSearch in parallel and merge the results when all of them are finished (like we do for Universal Search), that's just a few lines of very readable Go. Try that with a GIL, sure, multithreaded Python and Rub…
This example is terrible. Waiting for DB responses, ElasticSearch queries, and long running IO is one place where Python and Ruby multi-threading with a GIL works great. A GIL means multiple threads can't execute Python code at the same time. All of those tasks are by definition NOT running Python code, they're sitting around blocked waiting for responses.
A better example would be something like image processing, where an image is loaded into memory, broken into multiple independent chunks, and each chunk is processed at the same time in multiple threads. In Go that should work just fine, but in Python and Ruby each thread will spend a lot of time waiting for the GIL.
The K&R for Go, sounds great!
Question for the Go experts out there: does it make sense to buy this book to learn Go or are there better tutorials/books?
It will probably end up being the definitive reference.
To those in the Go community: - What is Go well suited for other than network programming? - Why might one decide to write the backend API of their web app in Go, compared to say Grails, Python etc.
> What is Go well suited for other than network programming? Why might one decide to write the backend API of their web app in Go, compared to say Grails, Python etc. You'll get a lot of different opinions on this. I'll just speak based on my experience, since Python was my primary language before coming to Go. Everything I used to use Python for, I can do faster in Go. The notable exception to this is statistical an…
I have no idea what they will specifically say regarding calling C from Go, but the table of contents says that part is only going to be about five pages. I really wish they would beef up this portion of the book.
Interesting to see that the direct lineage from Pike's prior languages and CSP experiments is reaffirmed. I wrote about this here earlier, with some notable disagreements in response: https://news.ycombinator.com/item?id=9711639
Earlier quoted context omitted.
> What is Go well suited for other than network programming? Why might one decide to write the backend API of their web app in Go, compared to say Grails, Python etc. You'll get a lot of different opinions on this. I'll just speak based on my experience, since Python was my primary language before coming to Go. Everything I used to use Python for, I can do faster in Go. The notable exception to this is statistical an…
100x? Even 10x is very significant. Why is it that you feel so much more productive in Go? Is it ease of refactoring? Lack of frustrating bindings bugs? Something else?
There are a number of reasons. I find refactoring is way, way simpler. Refactoring in Python feels painful enough that I always put it off until it gets absolutely necessary. With Go, I find it takes way less time, and also less mental energy.
The static typing and strict compiler (enforcement of imports and lvalues, etc.) works well for my writing style. I write what's in my head, without worrying about the small details (only the high level logic), and I can be confident that it'll be easy to fix the small details (syntax, typos) afterwards.
It's kind of like how writers often work - they dump words on a page, focusing on getting the main points across, and it's the editor's job to make sure they fix the grammar and style. I end up having a conversation with the compiler and when it stops telling me anything, the code usually does what I want it to.
YMMV.