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

111–120 of 233 posts

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

#111

Post by masklinn »

rudolf0 wrote: post #84
masklinn wrote: post #43

Earlier quoted context omitted.

> From the preface: "achieving maximum effect with minimum means." Wouldn't be out of place at a marketing agency, with about the same level of truth too. > Sort of the anti-Perl? In what sense? The one thing you can say about Perl is that it's a huge language, so the anti-perl would be a very small language. Go isn't a very small language (like Forth), it isn't even a small one (like Smalltalk or Self) it's about th…

I think it's fair to call Go an anti-Perl. Perl is very liberal. There's always more than one way to do things. Go is very conservative, in comparison. I'd agree that both are contrarian, but for very different reasons.

> I think it's fair to call Go an anti-Perl.

Then again, pretty much anything can fairly be called an anti-Perl, possibly even Perl.

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

#112

Post by rudolf0 »

muraiki wrote: post #32
endymi0n wrote: post #15

Earlier quoted context omitted.

Other than some quite significant performance gains, I'd say the main upside for the case of a backend API would be channels. Concurrency is dead simple in Go - and if you want to do 5 different requests to ElasticSearch in parallel and merge the results when all of them are finished (like we do for Universal Search), that's just a few lines of very readable Go. Try that with a GIL, sure, multithreaded Python and Rub…

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.

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

#113

Post by sinatra »

MCRed wrote: post #105
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…

Elixir is what I would choose. I think of deployment as a one time cost. So, the cost of exrm+docker solves your build problem and then your deployment is like a "single binary". (except its a single docker container which is sufficient for me, maybe not for you.) As I understand it the go runtime must pause to resolve atomic locks for all the goroutines running. So, when you're doing a dozen goroutines in your app i…

Thanks! The point about immutability is important. Based on the comments I've been seeing on HN, I had a feeling that Docker brings its own set of problems. But, it may be worth checking it out.

> I think Elixir has good library support too.

I guess the support will be even better if you consider using Erlang libraries.

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

#114

Post by vezzy-fnord »

MCRed wrote: post #105
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…

Elixir is what I would choose. I think of deployment as a one time cost. So, the cost of exrm+docker solves your build problem and then your deployment is like a "single binary". (except its a single docker container which is sufficient for me, maybe not for you.) As I understand it the go runtime must pause to resolve atomic locks for all the goroutines running. So, when you're doing a dozen goroutines in your app i…

No such thing as Elixir processes. They're Erlang processes because they're constructs of the EVM. Whether or not you consider the latter fun to write is irrelevant.

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

#115

Post by Vendan »

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

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

#116

Post by Animats »

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

See the very first example of "channels" in that 2009 version:

"In the previous section we launched a sort in the background. A channel can allow the launching goroutine to wait for the sort to complete." ...

    c
That's using a channel as a lock on shared data. Not seeing that in the new book. This is a step forward.

(What Go really needs is Rust's borrow checker and move semantics, so that when you communicate on a channel, the compiler checks that you're not sharing too much.)

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

#117

Post by sinatra »

flexd wrote: post #103
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…

I would choose Go. It comes with an excellent built-in package net/http ( https://godoc.org/net/http ) that quickly allows you to setup a web service. An Go's mechanic (?) of implicit satisfaction of interfaces allows you to do some really cool things. One of the gripes about Go seems to be error handling, and your code ends up with a whole bunch of 'if err != nil { stuff }'. Matt Silverlock ( http://elithrar.github.…

Yes, just using built-in packages, and not depending on too many third-party packages is definitely attractive to me. The code full of "if err != nil" is an issue that I've also noticed. However, I'm hopeful that this may actually remind me to be more exhaustive in error handling.

Why did you mention the container? How kind of benefits would you be getting from a container for Go?

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

#118

Post by twic »

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…

Java. Static types (less sophisticated than state of the art, more sophisticated than Go), fairly easy deployment (you can easily make a package with everything except the JVM, so it's your one binary + /usr/bin/java + libjli + lib{c,dl,pthread,z}), concurrency is state of the art (whether old-school threads-and-locks with java.util.concurrent, actors with Akka, fibres with Quasar, whatever you like), is a quite small and simple language with a standard library that admittedly rivals any European capital for size, complexity, fascinating details, layers of history, and alleyways that stink of piss, tooling and debugging is state of the art, and fun, well, Java's really more golf than base jumping.

Documentation, performance, and community are varied but often excellent.

Libraries and frameworks abound (some are even quite good). Perhaps surprisingly, everyone seems to have settled on JAX-RS/Jersey as the way to write REST APIs. It's what's in the EE spec, so it's what guys in polyester suits in banks are writing, and it's what's in Dropwizard, so it's what gals with bright blue hair in startups are writing. The only real alternative is Spring MVC, which is really very similar, but requires that you buy into Spring.

Probably not the answer you wanted. But not bad for a language that's a day older than Braveheart.

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

#119

Post by masklinn »

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.

> 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 (if the editor allows tab-indent+space-align at all), when the code is being hard-reformatted it's not an issue.

> Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4.

8 is the historical/default tabwidth on Unices (unconfigurable environments generally have a tabwidth of 8), using hard tabs but defaulting to anything else would be odd. And since it's tabs, you can configure your environment to whichever tabwidth you prefer (like 3 or 6, I've not seen editors with support for tabwidths in half-spaces or pixels but in theory that's also an option) (well technically the CSS tab-size property supports arbitrary tabsizes but only Chrome >= 42 supports that, the rest only supports spaces, except for IE which has no support whatsoever).

A claimed benefit of 8 tabwidth is also that rightsward drift becomes a problem extremely early, the tabwidth thus acts as a check against over-nesting. Now that's inconvenient in languages with significant "natural drift" like C# (where your code lives in a method in a class in a namespace so you're already 3 indents deep before you've writing anything, class-in-files languages tend to have a tabwidth of 4 or even 2 probably for that reason), but IIRC Go only has a single "natural ident" the rest is all yours, so a tabwidth of 8 serves as a check against nesting code too much.

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

#120

Post by to3m »

hactually wrote: post #100
bradtgmurray wrote: post #91

Earlier quoted context omitted.

That looks a lot like C to me, which I wouldn't call a dynamic language. typedef struct Foo { int a; int b; } Foo; Foo f = (Foo) { .a = 1 }; // This will initialize b to zero.

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

Post reply on HN