Live data from Hacker News

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

gopl.io

41–50 of 233 posts

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

#41
post #27

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?

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.

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

#43
post #23

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."

From the preface: "achieving maximum effect with minimum means." Sort of the anti-Perl? I say this as someone who likes both Perl and Go. Go is very contrarian, and I applaud this.

> From the preface: "achieving maximum effect with minimum means."

Wouldn't be out of place at a marketing agency, with about the same level of truth too.

> Sort of the anti-Perl?

In what sense? The one thing you can say about Perl is that it's a huge language, so the anti-perl would be a very small language. Go isn't a very small language (like Forth), it isn't even a small one (like Smalltalk or Self) it's about the same size/complexity as an early Java. Somewhat bigger in some ways (more magical builtins and constructs) somewhat smaller in others (simpler visibility rules, no synchronised methods/blocks), but in the best case it's a wash.

> Go is very contrarian, and I applaud this.

Perl is also very contrarian.

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

#44
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?

Yeah, I know 100x is a huge multiplier, but I've actually tracked myself to the extent possible, and that really is the right order of magnitude for me. 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 s…

The static typing and strict compiler (enforcement of imports and lvalues, etc.) works well for my writing style.

It seems you more enjoy just "Not Python" than Go itself.

Go is still pretty awful and designed without really consulting what would help users. It's just designed for what the creators want, but now millions of people are trying to use it—not just 8 people inside the Nation of Google. It's getting worse for the average developer as time goes on. But, one thing developers love doing is understanding broken things, so in a away, the more difficult a system, the more nerds like it because it gives them accomplishment and the ability to exclude non-understanders. (Plus, Tabs? Tabs? In 2015? Is the Go development process run by monkeys living in Antarctica?)

Good review: http://www.evanmiller.org/four-days-of-go.html

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

#45

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."

Are they actually proud of having no generics? :o

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

#48
post #41
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.

This is a painfully incorrect method of determining programmer productivity.

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

#49

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 should take you a grand total of 2 days. Just open up the spec in one tab, playground in another, and start playing.

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

#50

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.

POSIX-y low-level userspace stuff you'd normally write in C or perhaps C++.
Post reply on HN