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

101–110 of 233 posts

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

#101

Post by xrstf »

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.

Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/

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

#102

Post by rudolf0 »

seiji wrote: post #75
Isamu wrote: post #23

Earlier quoted context omitted.

From the preface: "achieving maximum effect with minimum means." Sort of the anti-Perl? I say this as someone who likes both Perl and Go. Go is very contrarian, and I applaud this.

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.

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

#103

Post by flexd »

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.io/article/http-handler-error-handlin...) talks a bit about how you can use some of Go's strengths to create a web services without any frameworks or packages that aren't built-in. Go and net/http is very powerful and allows you to do very much without needing any external packages.

If it was up to me, I would write the service in Go and run it in a container somewhere. But the container is not required :)

Go has been a bit lacking in debugging options previously as you said, but lately cool projects like godebug https://github.com/mailgun/godebug and Delve https://github.com/derekparker/delve have been released, making it possible to debug programs better.

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

#104

Post by dougbarrett »

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've been partial to Go for the past few years. My toolkit is mainly comprised of martini for the web framework, gorm for the database handling (also includes auto migrations which is awesome!) and heroku for hosting (they have native Go support now) or even dokku on your own VPS

The software I write is primarily used in advertising, and Go allows me to write the software quickly and is able to handle a large load as you can see here: http://imgur.com/zpkjwlh

There is some overhead with Martini and Gorm, but the ease and speed of development more than make up for the performance loss

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

#105

Post by MCRed »

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 it's not a problem, but you couldn't do thousands of them. Meanwhile elixir processes can handle millions of processes without blocking like that, and that plus the ... strength... of immutable memory (vs. shared in go) makes me like elixir, especially when concurrency is important. (I don't consider go to be a concurrent language in this regard.)

Good tooling and debug support: I can't compare the two languages in this regard, go seems to have good library support. Elixir has excellent tooling and debug support (REPL mainly, and really nice error messages), and I think Elixir has good library support too.

Fun to write: So far for me, Elixir wins this hands down. Go is running neck and neck with Erlang in the "not very fun to write" range for me.

Of course this is all personal opinion.

The only objective thing is- if you need real concurrency and to build a distributed system (go doesn't even have the concept of language support for Nodes) then Elixir is the way to go.

If on the other hand you need max compiled speed on a single node, the Go wins hands down.

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

#106

Post by jgalt212 »

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.

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

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

#107

Post by Jabbles »

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

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

#108

Post by MichaelGG »

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.

C# compiles and JITs incredibly fast and has generics. F# has the same generics and compiles far slower. The reason isn't compile times. (Especially since one impl of generics is just generating code, which is cheap.)

IIRC the reasons on the list were the standard tradeoffs of memory space and so on. Do they emit specialized versions for each function, or not, and so on. Again, stuff that's working fine in other platforms.

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

#109

Post by AnimalMuppet »

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.

> 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 time you pay every time you compile - year after year, for some projects.

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

#110

Post by nimrody »

"Typeset by the authors in Minion Pro, Lato, and Consolas, using Go, groff, ghostscript, and a host of other open-source Unix tools. Figures were created in Google Drawings."

groff still going strong... although it seems like Kernighan got tired of drawing using the 'pic' language...

Post reply on HN