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

151–160 of 233 posts

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

#151

Post by TillE »

skybrian wrote: post #92
claystu wrote: post #37

Earlier quoted context omitted.

It would be nice if all C libraries get rewritten in Go, but realistically, there are way too many for that to ever happen.

There are lots of libraries in C (and Java) but the question is which ones are essential for whatever you're trying to do? There are lots of Go programs you can write just using the standard library. That appeals to me since I'm generally in favor of avoiding unnecessary dependencies. But if you need it, you need it.

It really depends on what you're doing, but even in common obvious stuff like networking, there can be functionality in libcurl or OpenSSL that you really need but isn't replicated in Go. Several years ago I remember trying to do SSL certificate verification with Python and finding the standard library lacking.

Also bear in mind that good compatibility with C also means good compatibility with just about every other compiled language, including Rust.

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

#152

Post by eric_the_read »

copperx wrote: post #143
nimrody wrote: post #110

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

groff == GNU roff by definition. I suspect by "Heirloom groff" you mean troff or nroff.

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

#153

Post by ifross »

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.

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

#154

Post by comex »

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…

I've worked on a (C++) codebase which mixes tabs and spaces for this reason. It works okay - in particular, since my editor is configured for 4-space tabs, while patches are reviewed in GitHub with an 8-space tabs, any mistakes are likely to be caught in review. But it's not that hard to avoid making them in the first place if you remember to use the space bar to line things up.

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

#155

Post by fmstephe »

vvanders wrote: post #38
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.

Given that there's a GC and from what I understand(I'm no go expert) limited ways to specify memory layout I'd say no.

I am curious about the limitations around memory layout. Go provides a fair amount of control to the programmer. Fields appear in the order declared in a struct (although potentially padded), structs declared as values, not pointers, are located in memory with the declaring struct and we can have arrays and slices of non-pointer structs they will all be arranged contiguously in memory.

I am not a C/C++ programmer are there more powerful facilities provided in these languages?

Real question, not trying to start a flame war :)

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

#156

Post by tracker1 »

lmm wrote: post #132
AnimalMuppet wrote: post #109

Earlier quoted context omitted.

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

> 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 place. If you are running one-off executable handlers, that need to start and finish quickly, then you probably would favor go.

It's entirely possible for different options to be part of a larger solution.. and while I agree, the lack of generics is truly painful... I remember C# before, and feel that Java's generics are a horrible implementation... I'd rather wait for a nice implementation just the same.

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

#157

Post by edsrzf »

jerf wrote: post #141
yokohummer7 wrote: post #64

Earlier quoted context omitted.

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

One non-obvious downside is that the Go 1 compatibility guarantee doesn't apply to struct literals that don't use field names. (I suspect you're aware of this, but other readers might not be.)

So it's possible that a future version of Go could add a field to some struct you're using and your code will stop compiling when you upgrade. It's an easy fix, of course, so it's not that big of a deal, but it's worth realizing.

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

#159

Post by dougbarrett »

zphds wrote: post #150
dougbarrett wrote: post #104

Earlier quoted context omitted.

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

I've used it with mux, and have detailed my experience here: https://www.dougcodes.com/go-lang/martini-to-gin-back-to-mar...

Negroni and Mux are great to use, and typically I will go back and refactor the code to squeeze out any extra performance if it's needed and the project has proven its worth, but Martini has middleware that is hard to beat and easy to set up to get proof of concepts out the door.

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

#160

Post by jerf »

edsrzf wrote: post #157
jerf wrote: post #141

Earlier quoted context omitted.

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…

One non-obvious downside is that the Go 1 compatibility guarantee doesn't apply to struct literals that don't use field names. (I suspect you're aware of this, but other readers might not be.) So it's possible that a future version of Go could add a field to some struct you're using and your code will stop compiling when you upgrade. It's an easy fix, of course, so it's not that big of a deal, but it's worth realizin…

The point is that if I'm using stuct literals, I want the compiler to stop me for those structs.

I'm explicitly rejecting the idea that all struct changes should be possible without producing compiler errors. Compilers errors when the guarantees your code is based on changes is a feature, not a bug.

Post reply on HN