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

121–130 of 233 posts

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

#121

Post by masklinn »

to3m wrote: post #120
hactually wrote: post #100

Earlier quoted context omitted.

Isn't it funny how C has so many ways to accomplish the same thing. Why did you use a typedef with a tag? typedef struct { int a; int b; } Foo; Foo f = { .a = 1 };

Tagless structs can't be forward-declared. (Obviously, this looks like a local struct, so there's possibly no need for forward declaration. But you might have a snippet to generate this sort of thing for you. Or maybe it's just force of habit. And so on.)

> Or maybe it's just force of habit.

Or cargo-culting.

edit: wow somebody felt threatened. I have no shame stating that I cargo-culted exactly that for a while before I actually wondered what I was doing.

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

#122

Post by staticint »

15155 wrote: post #95
AnimalMuppet wrote: post #93

Earlier quoted context omitted.

> Basically they dismissed every implemented approach, despite generics obviously working in other systems. But working at a price. And Go isn't willing to pay the price (especially in terms of compile time). If Go ever adds generics, it will be with a new approach that doesn't blow up compile times.

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly.

The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with.

While that is less than ideal, I cannot see that increasing developer time by a significant margin.

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

#124

Post by masklinn »

xrstf wrote: post #101
15155 wrote: post #95

Earlier quoted context omitted.

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/

A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.

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

#125

Post by lmm »

sinatra wrote: post #90

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

Scala/Spray. Wonderful full-fledged type system, complete with a strongly typed model of HTTP (so that e.g. ContentType is well-typed, and takes a well-typed model of a MIME type, not just a String). Excellent concurrency support, very fun, all the JVM tooling/debug support. Deployment needs a tiny bit of fiddling - I recommend building with maven and using the maven shade plugin, then you get a standalone jar that you just need a JVM to run.

The unique selling point is that your routing is defined in a DSL that's almost as nice as the config file most systems would use - but it's ordinary Scala, well-typed and refactorable in the normal way because everything's just code. And because the type system has higher-kinded types you can use typed wrappers to represent cross-cutting concerns, with the lovely for/yield sugar for composing them. E.g. you can have database-session-in-view but in a principled way: you have a wrapper type that represents an operation that needs to happen in a database transaction, and if you want to compose two or more such operations you use the for/yield sugar, and it's all refactor-safe and you can tell which unit tests need a database (fake or real) because it's right there in the type. And at the route level you either have a marshaller that handles your wrapper completely transparently, or your own directive that works exactly like the built in ones because again, it's all just code. You can click through to the source of the directives and see how they're implemented, not just magic annotations like with JAX-RS. If you want to get super mind blowing you can even use for/yield to compose together directives to make a custom directive.

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

#126

Post by rmcpherson »

LVB wrote: post #98
rmcpherson wrote: post #82

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?

You're correct, but in the interest of: We’ll discuss these topics only briefly here, pushing most details off to later chapters, since the primary goal right now is to give you an idea of what Go looks like... it's probably clearer to use the default random source.

Good point, but I also think it will be confusing to beginners who compile and run the program only to find that it always generates the same figure without any explanation as to why. Both the package documentation and text say that the generated figures will be random.

The fix is just a couple lines and, I would argue, should be included in the source to eliminate the surprising behavior. http://play.golang.org/p/1WlhOdJ1pk

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

#127

Post by seiji »

masklinn wrote: post #119
rudolf0 wrote: post #102

Earlier quoted context omitted.

While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. The 2 spaces (of soft or hard tabs) favored by some Ruby and CoffeeScript programmers is too little, but 8 spaces is way too much.

> While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Since you're using goftm which imposes a strict discipline, tab-indents and space-align allows configuring tabwidth however you want locally without imposing that on other collaborators. The issue with the idea is usually doing it consistently and people properly configuring their editor (…

people properly configuring their editor

A lot of coding is reading examples online these days. Trying to read Go code on GitHub is awful since three forced tab indents feels like you're 50% across the screen already (and forget trying to read it on mobile).

Browsers don't really have a "set tab width" option that I've found (and forget trying to set user options on mobile browsers).

a check against nesting code too much.

For expert programmers coding for long-term correctness, then yes. But beginners and lean "we just gotta ship this shit" startups will just create 9 levels of unreadable cruft.

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

#128

Post by aikah »

dekhn wrote: post #61
norswap wrote: post #45

Earlier quoted context omitted.

Are they actually proud of having no generics? :o

No, the authors specifically said that they would like to have generic features but couldn't figure out a way to implement it without unacceptable performance problems. I'm pretty sure the feature will show up in the next few minor version increments.

> I'm pretty sure the feature will show up in the next few minor version increments.

No it won't. People need to stop expecting generics because it will never happen. Not that agree with this but it was made pretty clear in the go-nuts mailing list that the Go team wants to keep Go type system "simple".

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

#129

Post by seiji »

Vendan wrote: post #115
rudolf0 wrote: post #102

Earlier quoted context omitted.

While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. The 2 spaces (of soft or hard tabs) favored by some Ruby and CoffeeScript programmers is too little, but 8 spaces is way too much.

I am vastly in favor of hard tabs, as it doesn't enforce tab size. Question, why do you say that the standardize on tabs as 8 spaces? I've done all my golang programming with 4 tab spaces.

Hard tabs make "pretty/readable indent" formatting difficult too.

If you want to line up certain arguments across lines, you just can't because you're forced to an unknown width of alignment chosen by the reader. So, all your code will just be indents that ignore the specific visual alignment intentions of the author, and that reduces readability and understandability in multi-person teams (and programming is a team sport, not a one-person-does-it-all game).

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

#130

Post by masklinn »

seiji wrote: post #127
masklinn wrote: post #119

Earlier quoted context omitted.

> While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Since you're using goftm which imposes a strict discipline, tab-indents and space-align allows configuring tabwidth however you want locally without imposing that on other collaborators. The issue with the idea is usually doing it consistently and people properly configuring their editor (…

people properly configuring their editor A lot of coding is reading examples online these days. Trying to read Go code on GitHub is awful since three forced tab indents feels like you're 50% across the screen already (and forget trying to read it on mobile). Browsers don't really have a "set tab width" option that I've found (and forget trying to set user options on mobile browsers). a check against nesting code too…

> Browsers don't really have a "set tab width" option that I've found.

The `tab-width` CSS property is supported by all browsers except MSIE, though only for integer amount of spaces (aside from Chrome 42 which supports arbitrary widths). In most desktop browsers can setup a "user css" to set it.

> For expert programmers coding for long-term correctness, then yes. But beginners and lean "we just gotta ship this shit" startups will just create 9 levels of unreadable cruft.

Would their unreadable cruft be any more readable with a tabwidth of 4 or (god forbid) 2?

Post reply on HN