First chapter of Kernighan and Donovan's new Go book [pdf] • Hacker News Board

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

#161

Post by nosequel » Mon, Oct 19, 2015, 10:24 PM UTC

Jabbles wrote: post #107

Animats wrote: post #94

This is much better than the previous Go documentation, particularly in the concurrency area. The previous Go documentation introduced goroutines and channels, stated the mantra "share by communicating, not by sharing", and then gave examples with variables shared between goroutines. It now seems to be recognized that, in Go, if you want to lock shared data, use the lock primitives. Don't try to construct locking pri…

You've been misinformed. The 2009 version of Effective Go stated, as it does now: "This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance." https://web.archive.org/web/20091113154825/http://golang.org...

Of course if you care about speed at all, you will stay away from Go's mutex's. Time your own code, it is shocking how slow they are. I haven't published my own test times, but with a quick search here's an example of a 10ms loop taking 2s with mutex's. http://www.arkxu.com/post/58998283664/performance-benchmark-...

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

#162

Post by Artemis2 » Mon, Oct 19, 2015, 10:26 PM UTC

LBarret wrote: post #139

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.

More like into two languages that will keep on existing for the next decade.

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

#163

Post by Artemis2 » Mon, Oct 19, 2015, 10:29 PM UTC

bdamm wrote: post #27

chimeracoder wrote: post #14

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?

A very significant reason why I love Go is that it fits in my head. I can use all the keywords, constructs, all the builtin functions effortlessly, while the standard library is a breeze to work with.

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

#164

Post by nsajko » Mon, Oct 19, 2015, 10:31 PM UTC

aikah wrote: post #128

dekhn wrote: post #61

Earlier quoted context omitted.

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

Maybe in Go 2? ;)

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

#165

Post by andreaferretti » Mon, Oct 19, 2015, 10:36 PM UTC

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.

Also, Nim would be a good fit for those domains. Macros and custom operators allow one to write dsl for numeric and scientific programming, and you have complete control over memory layout. There is a gc, but you can tune it very precisely

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

#166

Post by Vendan » Mon, Oct 19, 2015, 10:37 PM UTC

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…

gofmt works freaking beautifully for this though. Sure, if I tried to do it myself, I'd screw it up. That's why I don't do things that the computer can do better, easier, faster then I can. I just hit save, and my editor routes it through gofmt and refreshes file. It's to the point where I'll hit ctrl-s after moving a brace just to have gofmt reformat, CAUSE IT DOES IT FASTER THEN I COULD.

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

#167

Post by skywhopper » Mon, Oct 19, 2015, 10:38 PM UTC

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.

Generics can be nice, but they're clearly not "necessary" to any of the languages that don't support them. Besides, the cost that generics would exact in terms of syntax complexity, compile time, and startup time is something that many Go-detractors dismiss as irrelevant.

Myself, I think enforced tab-based formatting is utterly insane, but ultimately it doesn't matter. Part of the philosophy behind Go is to keep certain things very simple, and leaving generics out is a big part of that. I don't think that they're going to change their mind because non-Go programmers advocate for them. If that makes it the wrong language for your project, then there are so many others to consider.

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

#168

Post by AnimalMuppet » Mon, Oct 19, 2015, 10:54 PM UTC

masklinn wrote: post #124

xrstf wrote: post #101

Earlier quoted context omitted.

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.

Slower to compile, but starting from a much faster starting point.

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

#169

Post by trevorstrohman » Mon, Oct 19, 2015, 10:58 PM UTC

rudolf0 wrote: post #102

seiji wrote: post #75

Earlier quoted context omitted.

Go is very contrarian, and I applaud this. It takes more than reversing the order of parameters and using known-braindead ideas like codified tabs-are-good syntax to make contrarian ideas valuable. Just because you change green lights to mean stop and red lights to mean continue doesn't make contrarian suddenly better than the way things were.

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.

A significant fraction of the Go core engineers use proportional fonts when programming. On their screens, hard tabs are the only tabs that work. Spaces on proportional fonts are too tiny to be useful for moving code around.

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

#170

Post by MichaelGG » Mon, Oct 19, 2015, 11:06 PM UTC

tracker1 wrote: post #156

lmm wrote: post #132

Earlier quoted context omitted.

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

It depends on the use case... C# is a wonderful language, since the addition of generics and lambdas, it's downright beautiful to work with. But this does come with a cost... Even a simple hello world console app has a pretty significant spin up time compared to go, or anything that is truly compiled. In some cases, if you have long-lived services, then Java and .Net make sense... You can get farther with the code in…

I cannot find any reason to believe that lambdas have anything, at all, to do with sin-up time. A hello world console app wouldn't even be using them much (closures are just objects so...).

And I doubt generics make a significant difference in runtime but I don't have a CLR v1.1 around to test it out. For comparison, a C# hello world takes about 10ms longer than a C one (both compiled with optimizations; .NET 4.6 C# 6 / MSVC 19) on my i5 Broadwell laptop. Timing as measured by "time" in bash (~25ms vs ~35ms).

I'm guessing you're talking about JIT in general and of course have a point there. I doubt it's significant for any significant values of significant.