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

191–200 of 233 posts

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

#191

Post by gnuvince »

AnimalMuppet wrote: post #93
MichaelGG wrote: post #76

Earlier quoted context omitted.

Basically they dismissed every implemented approach, despite generics obviously working in other systems. (And it's hardly a "new" feature unless we're counting in multiples of decades.)

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

A few years ago, Andrei Alexandrescu showed that the dmd compiler was actually faster than the gc compiler, and D supports templates. Recently, with 1.5, Go has shown that it is ready to take a hit on compile-time speeds. I don't think the argument of compilation speed holds for generics. To me it sounds much more like a culture thing: generics, for better of for worse, add an extra thing to think about and I think that the Go authors and many Go developers are just not interested.

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

#192

Post by jschwartzi »

zeckalpha wrote: post #186
api wrote: post #178

Earlier quoted context omitted.

This is one of the things I like about Go: it's "done." In exchange for passing on extensions that might make certain use cases easier, we'll avoid the bloat and have decades of backward compatibility. We just came out of a decade of nifty language mania. What I learned is that languages are boring but problems are interesting. Algorithms and solutions are interesting. A great solution to a challenging problem is rea…

What C compiler do you use to compile that 70s code? I find modern compilers usually choke on the "done" C code from then.

You have to feed it a switch or two, but gcc will do it.

Of course, we're talking about pre-ANSI C where any function prototype without a void argument implicitly accepts any and all arguments.

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

#193

Post by voltagex_ »

to3m wrote: post #137
TillE wrote: post #134

Earlier quoted context omitted.

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.

What's forward declaring mean?

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

#194

Post by kid0m4n »

FraaJad wrote: post #88
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.

Yes. Its always good to read the D success stories.

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

#195

Post by kid0m4n »

linuxfan wrote: post #78

Can people post their opinions on static linking of go binaries? Doesn't it result in increased size of runtime binaries when compared to those generated by C/C++?

Yep. It does; but then again my entire static binary (no dependency on libc even) is around 10 MB in size...

I love being able to pull down a docker container that fast!

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

#196

Post by copsarebastards »

jerf wrote: post #141
yokohummer7 wrote: post #64

Earlier quoted context omitted.

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

I should explicitly state I seem to be in the minority in the Go community here, but: You don't get a compiler error if you initialize by name. You do get a compiler error when you initialize by position. In my minority opinion, you can and should use that to your advantage whenever possible. Some structs are clearly "configuration-like", for instance, and you don't want an error if a new option shows up, which will…

So I get to go back and look at the struct to see the order every time I initialize an instance? Or watch everything break when the noob on the team alphabetizes the struct fields? Yeah, that's a great solution.

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

#197

Post by copsarebastards »

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…

> I came to Go for the static typing

Well, you came to the wrong place...

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

#198

Post by zmyrgel »

andmarios wrote: post #66
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.

Apart from the already mentioned reasons, another one would be maintainability. Go was designed with this in mind and some of its shortcomings come from this approach. It is a relatively small language, with one way of doing a certain thing and a mandate of using standard libraries and strict code formatting. It sounds limiting but it is productive and makes every Go developer write in the same style. So whether it i…

This is one of the reasons I'm pushing Go at work. I've had to maintain our current apps which have received very little maintenance work during the years and I wish Go would have been present when they were made.

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

#199

Post by geon »

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.

Slow compilers waste developer time.

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

#200

Post by 15155 »

geon wrote: post #199
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.

Slow compilers waste developer time.

Incremental compiles have existed for quite some time.

Go is only unique in that it can do a complete recompile in very attractive times. The only hitch, of course, is that you sacrifice features known and loved in other languages for over a decade.

Post reply on HN