Live data from Hacker News

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

gopl.io

141–150 of 233 posts

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

#141

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

> 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 probably default to whatever you had before anyhow. Some structs are clearly data structures, and you'd really like to know if your two-dimensional point suddenly grew a third parameter. Of course it's not a bright shining line, but it's often pretty easy to tell which you have, or which thing you want, and use the correct initialization.

In this case, if you used:

    T{4, "hello", 3.5}}
most future type changes to the T struct will become compiler errors. (It won't be if the types are compatible, for instance, changing the first to a float would still result in a legal struct. If you have richer types in play that is less of an issue.)

golint will then complain at you, but you can pass a command-line switch to turn that off.

(This, amusingly, puts me in the rare position of siding against the Go community, on the side of the language designers. Bet you may not have known there is such a position to take. :) )

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

#142
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 think it is not so much about "good debug support", or "easy deployment". It is really about what YOU, as an individual, without any regard to who wrote what language reimplementing its slice of CLisp, can do with a given language.

You're a rockstar in C? go for it, and just dockerize the result. You're a Ruby ninja? fine, and Capistrano the result (or just dockerize it). You're a Go ninja? why not, and then scp the result + restart the process via ssh. You're a CLisp expert? fuck yeah, and then reinject the new code directly in the running process. Just because you can. Who will stop you?

Have fun, that is the real point.

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

#143

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

Yep, I was really curious to see if he had finally given up and gone to TeX, Indesign, or the like.

I guess that if one's not dealing with a lot of math, groff is enough for many typesetting jobs.

I'm curious as to which version of groff they used. Heirloom groff? GNU groff? hmm...

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

#144
post #105
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…

Plain Erlang is also nice.

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

#145

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

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

You can use variadic arguments with an interface type or a single struct parameter to get similar behavior.

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

#146
post #25
post #3

The K&R for Go, sounds great!

Sadly, there is no 'R' anymore :-/

It's a little odd, given that Kernighan and Pike have written a couple of excellent programming books together, and with Rob Pike's leadership in the Go project, that this one isn't K&P.

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

#147
post #144
post #105

Earlier quoted context omitted.

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…

Plain Erlang is also nice.

I learned erlang first, years ago. I absolutely fell in love with it. Somewhere when I wasn't writing a lot of erlang code, it crusted over and now the erlang syntax bothers me. While elixir is more than a syntax, yes, that is part of its value for me.

To me, in my head, symbolically Elixir and Erlang are the same language, the concepts I'm using most of the time are representable in both. I just find Elixir more fun and easier to write quickly.

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

#148
post #105

Earlier quoted context omitted.

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.

Of course. I don't think anyone is pretending like Elixir isn't built on top of erlang.

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

#149

Just as K&R introduced us to "Hello, World," I'm amused they adapted their first program to an Unicode world: "Hello, 世界." Seems like a great first chapter, covering computer graphics and web server/byte fetching to boot.

> they adapted their first program to an Unicode world: "Hello, 世界."

Would be nice if you could compose those complicated Unicode characters from simpler building blocks, e.g.

    fmt.Printf("Hello, %a", "→↘𠃊廿↓田介")

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

#150
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 might also want to take a look at Negroni since it's supposed to be more idiomatic. There's a blog post about this by the author himself.

http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini...

Post reply on HN