Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First chapter of Kernighan and Donovan's new Go book [pdf]

gopl.io

Post reply on HN
Print view View original

31–40 of 233 posts

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#31

Post by lentil »

endymi0n wrote: post #15
Omnipresent wrote: post #9

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…

> Try that with a GIL, sure, multithreaded Python and Ruby is possible, but it's not for the faint hearted and not as easy to read

Actually that example does tend to be simple and readable in Python and Ruby. I've used a pattern similar to this to parallelize calls to a few back-end services from a Ruby app and it worked out great. The code I used looked something like this: https://gist.github.com/kevinmcconnell/8365521, which I think is quire readable.

I've definitely found Go's approach to concurrency to be very helpful in other situations; I just think that example could be a bit misleading.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#32

Post by muraiki »

endymi0n wrote: post #15
Omnipresent wrote: post #9

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…

While Go does provide channels, I'd argue that they are not dead simple. I'm not saying this to bash Go, and I have willingly used it to solve problems. But I think it needs to be made more clear that this often-praised aspect of Go may disappoint those who are familiar with alternative techniques available in mainstream (read: not Haskell) languages.

For instance, look at the "Go Concurrency Patterns: Pipelines and cancellation" article: https://blog.golang.org/pipelines You'll notice the line "We introduce a new function, merge, to fan in the results" and after that, you will see how you have to write merge() yourself for every different data type that you use. Yes, you will have to repeat this same type of code, over and over, any time you want to pipeline, fanout, or merge, a new data type (unless you resort to interface{}). Furthermore, you will have to use the Go race detector to make sure you didn't actually mess something up.

I can't speak for Python or Ruby, but if you are using Node.js you can use a library like Bluebird which provides promise combinators. Then it's very easy to perform 5 requests and to handle errors and cancellation on one or more requests. You can do this and more on any arbitrary data type without writing merge() and nesting coroutine returning functions repeatedly.

So for handling async operations like dealing with APIs, I personally prefer tools like promise combinators or reactive programming (see Reactive Extensions for Javascript, also available in many other languages, or supplies in Perl 6 if you're crazy like me) over the significantly more manual approach of using typed channels in Go. I'm sure there are tasks where tight manual control of channels is important, but for the type of work I've been doing Go is simply too low level.

This article goes into more detail on the weaknesses of pipelining in Go: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#33

Post by boulos »

Omnipresent wrote: post #9

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.

I'm confused: a backend for a web app's API is a "networked" program.

With Go (as compared to Python), it's super easy to define some structs, serialize and deserialize them as JSON that you check, and send them to the client quickly and efficiently.

The more annoying question for web apps (and productivity in general) is the static (+-strong) vs dynamic (+-weak) typing. Go, like Scala, does a great job inferring types (IMO) letting you feel fairly productive, but some people will always yearn for the "anything goes" dynamism (sadly combined with the lack of compile-time checking that would save you on larger projects).

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#34

Post by dragonwriter »

endymi0n wrote: post #15
Omnipresent wrote: post #9

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…

> Try that with a GIL, sure, multithreaded Python and Ruby is possible, but it's not for the faint hearted and not as easy to read.

As others have noted, the example use case is one where multithreading with a GIL/GVL isn't particularly problematic. Moreover, both Python and Ruby have GIL/GVL-free implementations (in Python's case, Python 2 only in Jython/IronPython; in Ruby's case, much more current in the language level supported, since current JRuby is Ruby 2.2-compatible.)

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#35

Post by hellofunk »

Omnipresent wrote: post #9

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.

If you are interested in an approachable API for CSP, Go is good, along with Clojure's core.async. If you want to write asynchronous code, they are both great leaders in that area right now. If you don't need that API, I personally find the reasons harder to find in favor of Go.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#37

Post by claystu »

harikb wrote: post #28
claystu wrote: post #8

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.

The fact that it is a bit non-intuitive to call C from Go is exactly where there are so many 'Pure Go' libraries. I consider this as a short-term hurdle with long-term benefit.

It would be nice if all C libraries get rewritten in Go, but realistically, there are way too many for that to ever happen.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#38

Post by vvanders »

fsloth wrote: post #36

Would Go provide a viable alternative to C++ for numeric and computer graphics 'kind of stuff'? I have no problem with C++ but the better-than-python proclamations got me intrigued.

Given that there's a GC and from what I understand(I'm no go expert) limited ways to specify memory layout I'd say no.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#39

Post by fiatmoney »

Omnipresent wrote: post #9

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.

Situations where you want a modern, strongly-typed language with easy C bindings.

IO-heavy operations, especially where it's primarily IO bound but there is a decent computational aspect (eg, working with an embedded database or doing lots of flatfile munging).

I've found the place where Go crashes and burns is if you're trying to implement / use lots of sophisticated custom data structures. It really really wants you to use the builtins, and the lack of generics is irksome.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#40

Post by seiji »

boulos wrote: post #33
Omnipresent wrote: post #9

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.

I'm confused: a backend for a web app's API is a "networked" program. With Go (as compared to Python), it's super easy to define some structs, serialize and deserialize them as JSON that you check , and send them to the client quickly and efficiently. The more annoying question for web apps (and productivity in general) is the static (+-strong) vs dynamic (+-weak) typing. Go, like Scala, does a great job inferring ty…

So, SOAP and CORBA just with a 2015 flavor?
Post reply on HN