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

81–90 of 233 posts

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

#81

Post by seiji »

stonogo wrote: post #48
seiji wrote: post #41

Earlier quoted context omitted.

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.

It's difficult to write a program without writing lines of code.

There are dumb measure, smart measures, and dumb ways of applying smart measures. We could consider a little intellectual generosity, that intentions were well-met, and not that a 50 year old used car salesperson turned programing manager was irrationally demanding X lines of code per day.

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

#82

Post by rmcpherson »

I noticed that the lissajous program in 1.4, as included, generates non-random lissajous figures since the random number generator is not seeded. I couldn't find any reference to this in the text and this could be confusing to beginning readers. Is there a recommended way to submit errata?

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

#83

Post by chimeracoder »

seiji wrote: post #79
chimeracoder wrote: post #62

Earlier quoted context omitted.

> It seems you more enjoy just "Not Python" than Go itself. No, I have experience with lots of languages. I'm comparing to Python here because that's what OP asked for. I don't think Go is "just designed for what the creators want", but even if it were, I don't care, because that's what I want as well. I'm talking about my personal experience of Go based on my own experience writing Go full-time for over three years,…

With all due respect, it's highly unlikely that a review from someone using it for four days But, the review goes into a rant about how the Go community just thinks it's the greatest and refuses to listen to outside opinions due to a sense of inbred and ungrounded superiority... kinda like what you just did there.

> the Go community just thinks it's the greatest and refuses to listen to outside opinions due to a sense of inbred and ungrounded superiority... kinda like what you just did there.

It's not 'inbred superiority' to think that my own experience is a better predictor of what works for me than what someone else thinks. I never said "Go is the greatest". I said that, based on my experience with a wide range of languages, Go is the best for me. OP asked "why might someone decide to use Go", and I answered by explaining why I decided to use Go.

From your comments throughout this thread, it seems that you really dislike Go. That's fine, don't use it. But why try and pick fights with those of us who do use it?

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

#84

Post by rudolf0 »

masklinn wrote: post #43
Isamu wrote: post #23

Earlier quoted context omitted.

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

I think it's fair to call Go an anti-Perl.

Perl is very liberal. There's always more than one way to do things.

Go is very conservative, in comparison.

I'd agree that both are contrarian, but for very different reasons.

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

#85

Post by seiji »

chimeracoder wrote: post #83
seiji wrote: post #79

Earlier quoted context omitted.

With all due respect, it's highly unlikely that a review from someone using it for four days But, the review goes into a rant about how the Go community just thinks it's the greatest and refuses to listen to outside opinions due to a sense of inbred and ungrounded superiority... kinda like what you just did there.

> the Go community just thinks it's the greatest and refuses to listen to outside opinions due to a sense of inbred and ungrounded superiority... kinda like what you just did there. It's not 'inbred superiority' to think that my own experience is a better predictor of what works for me than what someone else thinks. I never said "Go is the greatest". I said that, based on my experience with a wide range of languages,…

my own experience is a better predictor of what works for me

blub paradox. We only know what we know. Outside opinions are very valuable to show us better things exist.

But why try and pick fights with those of us who do use it?

Because the language is bad. It's not conducive to reading code or writing code. It's code for code's sake. It's a bad platform. The more it grows the more programmer minds it corrupts. The more it grows the less easy it becomes to avoid in general.

Programming is important. Our programs will outlive us. We can't afford to have the entire system run on what a small group of isolated people feel is right. Systems have to be powerfully expressive and powerfully legible without succumbing to failure-to-understand errors due to typography or mass indirection ("magic") in too many places.

Programming isn't H&M fast fashion. It's The Golden Gate Bridge. If you screw it up in 2015, you're at risk of killing people, ongoing, in the future, in perpetuity. (also see: flash, android, java, the unmaintained openssl debacle, ...)

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

#86

Post by bliti »

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.

Reasons why I've chosen Go for APIs:

- The language is simple. No need to lookup strange keywords or try and figure out too much cleverness in the language itself. It promotes readable code.

- A basic and good type system. I don't have to worry much about that int turning into a string.

- Strong default libraries. No need to rely on third party libraries to do a lot of the common API things.

- Low memory footprint.

- Its decently quick even without using channels.

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

#87

Post by fixermark »

yokohummer7 wrote: post #64
realrocker wrote: post #4

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

> no default parameter values Hearing this leaves a bad taste in my mouth, because one of the (mis)features I've found in Go is its implicit default value in struct initialization. In Go, you don't get a compile error when you miss some fields while initializing a struct. e.g. type T struct { a int b string c float64 } t := T{c: 1.5} will happily set `t.a` to 0 and `t.b` to an empty string. While this is useful for m…

It's one of those features that seems mad until and unless one runs into the situation that justifies it.

Go provides default values to avoid the C error-factory of random undefined behavior resulting from re-use of whatever is in a memory address; that much is clear. But the reason Go lets you partially instantiate an object (and separates out construction from state) is to make it easier to write unit tests, where the common case is that you want to circumvent the "main line" object construction pathways.

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

#88

Post by FraaJad »

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.

D is a viable alternative for C++; you still get to enjoy near native performance and cleaner FFI compared to Go, without giving up the features of a modern programming language.

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

#89

Post by hsitz »

stonogo wrote: post #48
seiji wrote: post #41

Earlier quoted context omitted.

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.

If you don't like LOC, then what sort of interpretation are you giving to "100x more productive"? I'm not so sure LOC is way off.

But in any case, if a person says he is "100x more productive" in one language than another, then I expect he can complete in 1 to 7 days what would take 100 to 700 days (i.e., 3 months to 2 years) in the other language.

Strange that I have to even highlight the obvious, but anyone who says they're 100x more productive in Go than Python is exaggerating to an extent that I find it hard to trust anything they say.

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

#90

Post by sinatra »

This is a good place to ask this (because Go posts attract a lot of commenters, even those who dislike Go and like some other language):

Which language/framework would you choose today for writing WebServices? Preferably with the following characteristics: static type (or at least static analysis), easy deployment (ex, generates a single binary like in Go), supports concurrency very well, is small/simple, has good tooling and debug support, and is fun to write. Go (except for good debug support)? Elixir (dunno how good it is with deployment and debugging)?

Post reply on HN