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

51–60 of 233 posts

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

#51

Post by microtonal »

chimeracoder wrote: post #14
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.

> 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…

Everything I used to use Python for, I can do faster in Go. The notable exception to this is statistical analysis, as Go does not have any FORTRAN bindings, whereas Python does (through Numpy & co.).

golang does have BLAS bindings through gonum:

https://godoc.org/github.com/gonum/blas/cgo

Coming back to the main question. I use Go as my primary language these days. E.g., my dependency parser and neural net dependency parser (which uses the aforementioned BLAS binding) are written in Go:

https://github.com/danieldk/dpar https://github.com/danieldk/dparnn

What I like about Go: it's C-like without the unsafety of C nor the complexity of C++. Moreover, I've found that working in Go is generally as productive as Python (short compile times, good tooling, completion in vim, lightweight package system), while being much faster and better-fit for large projects.

What I dislike about Go: it's a cliché, but the lack of parametric polymorphism is jarring.

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

#52

Post by low_battery »

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…

"Concurrency is dead simple in Go" In my experience, concurrency is not dead simple in Go, not even close.

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

#53

Post by JustSomeNobody »

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…

Concurrency is never dead simple.

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

#54

Post by peter303 »

I still prefer forced data abstraction, i.e. classes as a core construct. GO does not force that. Data abstraction, when properly done maps the code more closely into the problem domain to be solved. In the long run that makes the code more maintainable and extensible.

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

#55

Post by agentultra »

muraiki wrote: post #32
endymi0n wrote: post #15

Earlier quoted context omitted.

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…

Python has good co-routine support. In Python 3.5 we have async/await and the concurrent.futures module. For I/O bound tasks like running REST APIs or MapReduce jobs I don't see the GIL being much of a problem; you spend eons waiting to do a few milliseconds of work then wait some more.

> While Go does provide channels, I'd argue that they are not dead simple.

I'd agree.

In my experience it's easier to explain a solution to a fundamental problem than to an abstract one. Channels, futures, promises... all very abstract concepts; useful to the cognoscenti but none are satisfactory at solving the fundamental problem of parallel execution. Hence everyone in their camps about which is right for which tasks.

So even with channels parallel programming is still difficult. You just have the added burden of a different, unique abstraction. Every language ecosystem either has their own community-adopted one or a plethora of them.

I think I'll reserve, "dead simple," for when we have a universal language of parallel execution. Until then... we don't know how to compute!

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

#56

Post by ianamartin »

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…

>Other than some quite significant performance gains

I am aware that other languages perform better in benchmarks than, say, Python does. But in my experience, I've not ever found the speed of the language to be a bottleneck when I'm benchmarking and optimizing for scalability in a web app.

It's always something else. The database interface, the network, a crappy web framework, whatever. It always seems to be something other than the fundamental language that bogs things down.

I'll openly admit I might be missing something or that perhaps I haven't tried to scale high enough. I just don't get how it's relevant that x language is y times faster than Python when Python hasn't ever been the problem. There's always just so much more low-hanging fruit than the language.

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

#57

Post by mseepgood »

seiji wrote: post #41
bdamm wrote: post #27

Earlier quoted context omitted.

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?

Most talented people can write 200 "productive" lines of code per day (not copy/paste java boilerplate). So, 100x would mean you are now writing 20,000 lines of code per day.

"One of my most productive days was throwing away 1000 lines of code." — Ken Thompson, Go designer

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

#58

Post by thibaut_barrere »

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.

FWIW, you can use a ruby gem like typhoeus specifically for this:

    hydra = Typhoeus::Hydra.new
    requests = (0..9).map{ Typhoeus::Request.new("www.example.com") }
    requests.each{ |request| hydra.queue(request) }
    # blocks until all requests are complete
    hydra.run

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

#59

Post by why-el »

peter303 wrote: post #54

I still prefer forced data abstraction, i.e. classes as a core construct. GO does not force that. Data abstraction, when properly done maps the code more closely into the problem domain to be solved. In the long run that makes the code more maintainable and extensible.

I am really not sure this is true. In my opinion classes force an premature taxonomy almost all the time. I like that you can simply attach methods to structs when you decide you want object like behavior.

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

#60

Post by shawnps »

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.

Brad Fitzpatrick, a prominent Go developer and Google engineer actually gave a talk covering some of this at GoCon Tokyo last year: http://talks.golang.org/2014/gocon-tokyo.slide

Skip to slide 32 for examples of different tasks for which Go is proving to be efficient.

Post reply on HN