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

171–180 of 233 posts

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

#171

Post by morsegeek »

ifross wrote: post #153
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?

In the preface it does state: To run the examples, you will need at least version 1.5 of Go. $ go version go version go1.5 linux/amd64 Follow the instructions at https://golang.org/doc/install if the go tool on your computer is older or missing.

The deterministic rand behavior is the same for all go versions: https://golang.org/pkg/math/rand/#pkg-overview

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

#172

Post by seiji »

trevorstrohman wrote: post #169
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.

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.

What? Really? Who in the world would do that?

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

#173

Post by trevorstrohman »

seiji wrote: post #172
trevorstrohman wrote: post #169

Earlier quoted context omitted.

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.

What? Really? Who in the world would do that?

Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/

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

#174

Post by zphds »

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.

We use golang for a lot of our ops stuff. Earlier it was a repo of a mash of different python/ruby scripts. The runtime dependencies were hard to keep track of and they had to be installed on all the machines depending on the script being run.

With golang it's just one static binary that is scp'ed across the nodes. This easy of deployment isn't talked about much.

We were also able to go further and put a RESTFUL API on top of these tools using negroni and gorillamux.

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

#175

Post by pconner »

trevorstrohman wrote: post #173
seiji wrote: post #172

Earlier quoted context omitted.

What? Really? Who in the world would do that?

Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/

Is there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.

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

#176

Post by MikeTaylor »

nsajko wrote: post #164
aikah wrote: post #128

Earlier quoted context omitted.

> 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? ;)

Never gonna happen, Go 2 is considered harmful.

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

#177

Post by trevorstrohman »

pconner wrote: post #175
trevorstrohman wrote: post #173

Earlier quoted context omitted.

Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/

Is there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.

In this message I'm trying to make the argument I think they would make (I personally use monospaced fonts).

It's not that Acme can't use monospaced fonts, it's that Rob/Russ/others don't want to use them. Proportional fonts are better fonts, so why not use them instead? One possible reason is that existing code formatting conventions assume that text is lined up in columns, but we have a tab key that magically lines things up: it's the whole job of the tab key. So, why not forget about space-based alignment, use the tab key for the job it was built to do, and get the advantage of using pretty fonts?

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

#178

Post by api »

MikeTaylor wrote: post #176
nsajko wrote: post #164

Earlier quoted context omitted.

Maybe in Go 2? ;)

Never gonna happen, Go 2 is considered harmful.

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 really interesting even if it's in the most boring language ever.

I have code on my machine written in C in the 70s because C is largely "done." People today continue to write interesting stuff in C. Neuromancer was written in the same language as Lord of the Rings and Moby Dick, too.

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

#179

Post by vectorpush »

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.

I love two spaces. I used to use four but switched a few years back and now anything more than two looks strange to me. It's just a preference, but it does keep your line length shorter, which is nice if you like to adhere to a maximum line length throughout your code.

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

#180

Post by staticint »

nosequel wrote: post #161
Jabbles wrote: post #107

Earlier quoted context omitted.

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

A mutex held for up to 10ms on each iteration, over 500 iterations, averaging out to 2s doesn't seem surprising at all. In fact, this is quite expected. It would take considerably longer if the random sleep hit 10ms every time.

If you modify the code to release the lock before sleeping...

    func (c *Counter) add(ch chan int) {
            c.Lock()
            tmp := c.Num
            c.Unlock()
            tmp += 1
            time.Sleep(time.Duration(rand.Intn(10)) * time.Millisecond)
            c.Lock()
            c.Num = tmp
            c.Unlock()
            ch
...and reacquiring it after, it still finishes in 10ms on my machine, as you'd expect. As you can see, the problem isn't so much that locks are inherently slow in Go, but rather the mutex, as the acqusition function name implies, is doing what it is supposed to do: Lock. What is true is that you have to be careful to use them properly.
Post reply on HN