Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Go Programming Language by Brian W. Kernighan, Alan Donovan

amazon.com

Post reply on HN
Print view View original

251–260 of 264 posts

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#251

Post by tempodox »

kibwen wrote: post #158
tempodox wrote: post #25

In my personal view, I find it disappointing that someone like Brian Kernighan, as a co-author of C, only got as far as Go. I would have loved it much more to see him working on a language like Rust, that actually seems to point to the future of programming languages (or does its best at it), while Go looks like a stopgap and a dead end right from the beginning. Go seems a fine piece of engineering in so far as it di…

Go and Rust are allies, not enemies. Rust is a language driven by a goal, not by blind ideology, and that goal is to make the world a safer place by leveraging memory safety in a low-level context. Given that Go is also memory safe in its default configuration, any C or C++ service that is rewritten in Go still has the effect of making the world a safer place. Programming languages are a means, not the end!

That's certainly true. I was remiss in not qualifying my statement better

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#252

Post by Dewie »

NateDad wrote: post #56
Dewie wrote: post #39

Earlier quoted context omitted.

Maybe part of the problem is that people that promote Go in some capacity will at times make good arguments for certain things, but when they find something that they can't really explain, or that might seem subpar, they devolve their argument into some kind of appeal to authority - 'who am I to question their decisions. These are experienced, respected programmers with a lot of accomplishments. Who are anyone born a…

While I do agree that just saying "Well, Rob Pike and Ken Thompson must know what they're doing" is not a valid argument. I actually don't see many people making that argument. However.... There's authority, and then there's deep domain knowledge. If I was in the market for a bicycle, and Lance Armstrong had built one, you better believe I'd at least try it out. And even if I didn't entirely understand why he built i…

> Note that the whole reason this HN thread exists is not because some random book on Go is being published, but because Brian Kernighan's name is on the cover.

Fame is a good enough reason to give things priority when it comes to checking it out. But it is not a valid reason for saying why it is good to begin with. There's a difference between saying "I might buy this book because it is written by X", and "This book is good since it is written by X".

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#253

Post by sctechie »

codygman wrote: post #211
sctechie wrote: post #205

Earlier quoted context omitted.

For various meanings of 'learn'. My point is that you can be writing useful programs in c in a weekend. Obviously said person would not be an expert, but I've watched competent programmers try to learn complex languages like Haskell and Scala; there is a far more complex mental model that one needs to build before they can use those languages specifically because of all the automagic that happens in the background.

> My point is that you can be writing useful programs in c in a weekend. We'll need to define criteria for "useful program" but I believe most people could write useful programs in most languages in a weekend. > I've watched competent programmers try to learn complex languages like Haskell and Scala > far more complex mental model I think its more that those languages are different, not that they require a more compl…

Can we at least agree here that complexity implies a larger cognitive burden? I think that's a pretty benign statement to begin from regardless of the domain (programming, cooking, games, etc).

A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower chance to mess up.

I think the concept generalizes here.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#254

Post by bsg75 »

CatDevURandom wrote: post #218
rubiquity wrote: post #206

Earlier quoted context omitted.

> Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Would you mind sharing your top 5 wants? I'm interested.

Sure! In order: A Debugger. Better IDE options. Binary sizes small enough to use for embedded programming. Pauseless Garbage Collector. Less awkward variable declaration.

> A Debugger

https://golang.org/doc/gdb (some limitations IIRC)

https://github.com/derekparker/delve (a work in progress, but promising)

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#255

Post by tome »

tuxychandru wrote: post #235
tome wrote: post #129

Earlier quoted context omitted.

What about sum types (discriminated unions)? Sounds like that would help make error handling a lot safer and easier.

How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)? The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.

The problem with omitting language features like this is that the programmer is then forced to implement them by hand in an error-prone way. It's the same issue with Python and tail call optimization. Guido refuses to implement tail call optimization, so the programmer has to implement it herself in terms of a loop. Go refuses to implement sum types, so programmers code them up by hand. In neither case is the code actually clearer.

Since proper error-checking in Go actually requires doing by hand what a pattern match would have done anyway you're not simplifying anything for anyone by omitting them; you're just making it harder for the compiler to provide compile-time checks.

A pattern match is basically a switch statement. Go already provides the latter so the language would not need to become more complicated.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#256

Post by twic »

sbt wrote: post #79
sesteel wrote: post #26

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

I've been coding Go professionally now for about 8 months. Interestingly, it has made me appreciate C++. The reason is while the Go compiler is fast, it is mostly because it doesn't do very much work. By contrast, a C++ program takes a long time to compile because the compiler does a lot. It's obviously not as black/white as I've portrayed it here for brevity, but it is nevertheless an apparent trade off. I like Go o…

> on balance I would prefer a slower compile-test cycle to have more language feature support

So, are you sbt as in:

http://www.scala-sbt.org/

? I don't think i've seen a build tool posting on HN before, but now i have, i'm not surprised it's a Scala one.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#257

Post by codygman »

sctechie wrote: post #253
codygman wrote: post #211

Earlier quoted context omitted.

> My point is that you can be writing useful programs in c in a weekend. We'll need to define criteria for "useful program" but I believe most people could write useful programs in most languages in a weekend. > I've watched competent programmers try to learn complex languages like Haskell and Scala > far more complex mental model I think its more that those languages are different, not that they require a more compl…

Can we at least agree here that complexity implies a larger cognitive burden? I think that's a pretty benign statement to begin from regardless of the domain (programming, cooking, games, etc). A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower ch…

> Can we at least agree here that complexity implies a larger cognitive burden?

Right, but remember simple doesn't necessarily mean easy. The reason I use functional languages is because in my experience they handle complexity better.

> A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower chance to mess up.

> I think the concept generalizes here

I of course mostly agree to both of the above, but I think you are mis-characterizing functional languages such as Haskell which are simple but quite different from languages most are used to.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#258

Post by tome »

sctechie wrote: post #253
codygman wrote: post #211

Earlier quoted context omitted.

> My point is that you can be writing useful programs in c in a weekend. We'll need to define criteria for "useful program" but I believe most people could write useful programs in most languages in a weekend. > I've watched competent programmers try to learn complex languages like Haskell and Scala > far more complex mental model I think its more that those languages are different, not that they require a more compl…

Can we at least agree here that complexity implies a larger cognitive burden? I think that's a pretty benign statement to begin from regardless of the domain (programming, cooking, games, etc). A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower ch…

> A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail.

Agreed, which is why I prefer to implement complex ideas in Haskell. It catches more potential errors than other languages.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#259

Post by 4ydx »

jerf wrote: post #123
Veedrac wrote: post #94

Earlier quoted context omitted.

The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true. > But "lack of generics" is definitely not the same as "simplicity. It's not literally the same thing, but it is an aspect that keeps Go simple.

"The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true." Yes, speaking for myself as someone often in the position of defending Go on HN (even though as a computer language polyglot it isn't part of my personal identity), I also speak several other languages that do have generics in them, along with substantial usage of the "dynami…

This might be the first to-the-point comment I have read on HN that gives a clear perspective on the differences without being arrogant. Needing or not needing a rich numeric hierarchy is a great way to summarize it, I think. All of the hate towards a lack of generics really makes me wonder what programs people are writing that they feel they really need them given the fact that go does have interfaces. Nice post!

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#260

Post by zenlot »

slowmovintarget wrote: post #214
higherpurpose wrote: post #29

Earlier quoted context omitted.

Hopefully they'll do one for Rust, too, next.

That's doubtful, as the likely reason that they've written this one is that they're the same group of people that created the C language, now having moved on to Go. Ken Thompson, one of the creators of Go, worked with Dennis Ritchie (the "R" of "K&R") at Bell Labs, and created B, the precursor to C. Rob Pike, one of the other creators of Go, worked with Brian Kernighan (the "K") on two programming books. These guys a…

Well, no. It was UNIX -> C.
Post reply on HN