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

131–140 of 233 posts

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

#131

Post by muraiki »

rudolf0 wrote: post #112
muraiki wrote: post #32

Earlier quoted context omitted.

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…

>This article goes into more detail on the weaknesses of pipelining in Go: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 This write-up provides some great arguments for why generics could be very useful for abstracting away some of the details of concurrency management. I find it odd how so many Go developers insist generics are totally unnecessary.

Even if generics never come to Go, my hope is that at least common pipelining tasks like merge() will become part of the stdlib and have magical generic support... but I haven't heard anything to indicate that such a thing will happen. :(

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

#132

Post by lmm »

AnimalMuppet wrote: post #109
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.

> Developer time costs more than compiler time. I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler ti…

> I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time.

If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the computers get faster and the developers stay the same.

> Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.

No, the cost of being unable to abstract increases exponentially as your system grows. If using language X lets you cut 500 lines from a 1000-line Go project, then when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X. And you pay the cost of extra lines every time you read or debug, year after year.

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

#133

Post by masklinn »

seiji wrote: post #129
Vendan wrote: post #115

Earlier quoted context omitted.

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…

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

That's alignment not indentation. AFAIK gofmt uses spaces for vertical alignment

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

#134

Post by TillE »

masklinn wrote: post #121
to3m wrote: post #120

Earlier quoted context omitted.

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.

I'm guilty of this when writing C. I really have no desire to learn the language properly (it's hard enough to fit C++ in my brain), so I'll just follow the patterns others have set.

Microsoft does stuff like:

    typedef struct _FOO {
        ...
    } FOO, *PFOO;
Yeah ok fine, I'll do that.

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

#135

Post by seiji »

masklinn wrote: post #133
seiji wrote: post #129

Earlier quoted context omitted.

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…

> Hard tabs make "pretty/readable indent" formatting difficult too. That's alignment not indentation. AFAIK gofmt uses spaces for vertical alignment

But, that's arguing two points, right? That's like saying ASCII has 8 built in non-visual field separators, so people should use those instead of CSV/TSV for text tables.

Sure, it's technically the right distinction, but it's not practical in any reality in which we live.

Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk.

The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand.

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

#136

Post by TillE »

bkeroack wrote: post #99
jgalt212 wrote: post #97

Earlier quoted context omitted.

> no default parameter values This would seriously bum me out as I find the easiest to extend the functionality of an existing Python function is to add a new parameter with a default value. This way, regardless of whether the existing code base the calls the new or old version of the function, it performs the same way as it always has.

Since Go is statically-typed and compiled, it's much easier to refactor a function compared to Python. Change it and fix everywhere the compiler complains.

That's fine for internal functions, but a big problem when publishing any kind of interface. It's really nice to be able to extend an interface without breaking stuff or adding cruft.

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

#137

Post by to3m »

TillE wrote: post #134
masklinn wrote: post #121

Earlier quoted context omitted.

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

I'm guilty of this when writing C. I really have no desire to learn the language properly (it's hard enough to fit C++ in my brain), so I'll just follow the patterns others have set. Microsoft does stuff like: typedef struct _FOO { ... } FOO, *PFOO; Yeah ok fine, I'll do that.

When doing this in your own libraries, be sure to document how to generate the struct tag name from the typedef name. (MS don't do this - but they're not consistent about it anyway.) Then when people see a typedef'd struct used somewhere in a header, they'll know how to forward declare it in their own headers.

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

#138

Post by masklinn »

seiji wrote: post #135
masklinn wrote: post #133

Earlier quoted context omitted.

> Hard tabs make "pretty/readable indent" formatting difficult too. That's alignment not indentation. AFAIK gofmt uses spaces for vertical alignment

But, that's arguing two points, right? That's like saying ASCII has 8 built in non-visual field separators, so people should use those instead of CSV/TSV for text tables. Sure, it's technically the right distinction, but it's not practical in any reality in which we live. Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk. The only…

> But, that's arguing two points, right?

No?

> Sure, it's technically the right distinction, but it's not practical in any reality in which we live.

It's not practical to do by hand (because most people can't be arsed to configure their editor to do it, or their editor is incapable of it in the first place), why would it not be practical when a tool takes care of it for you and everybody uses that tool?

> Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk.

And yet gofmt seems to work.

> The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand.

Why? If the distinction between indentation and alignment can be made and can be made correctly, it means anyone can pick the tabwidth they prefer and things will just look right for everybody, that's strictly superior to either tabs or spaces. That's been advocated for decades, it just doesn't work when you leave it to people, which gofmt doesn't.

I'm quite far from a go fan, but achieving the ideal of "tabs for indentation, spaces for alignment" is definitely praiseworthy, whatever you think of other formatting rules.

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

#139

Post by LBarret »

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

compare this with python, which has carefully evolved into a better language.

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

#140

Post by logic »

jgalt212 wrote: post #106
bkeroack wrote: post #99

Earlier quoted context omitted.

Since Go is statically-typed and compiled, it's much easier to refactor a function compared to Python. Change it and fix everywhere the compiler complains.

true, forgot to think about that. But still potentially a lot of changes to fix, even if you are explicitly told what needs adjusting.

And this is where Go's tooling shines: https://golang.org/cmd/gofmt/

(Refactor automatically, not by hand.)

Post reply on HN