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

191–200 of 264 posts

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

#191

Post by Retra »

dragonwriter wrote: post #187
Retra wrote: post #164

Earlier quoted context omitted.

Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.

> Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. This is only true with identical utility functions for all participants. Rational decision making means each actor acts with perfect information about expected utilities of all options and chooses the option that maximizes their own realized utility. Rational actors can easily disagree without ignorance, since rational act…

Only if they are ignorant of each others' utility functions.

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

#192

Post by enneff »

mike_hearn wrote: post #170
gknoy wrote: post #128

Earlier quoted context omitted.

It doesn't make it better, but it's a __very strong hint__ that perhaps I should look more closely at Go. Experts matter, and it would be foolish of me as a developer to discount the experience of these guys -- they've literally been programming for longer than I have been alive. I respect the creators of Go deeply, because they have been so formative of the industry. It's like being an electrical Engineer, and havin…

I think this can be misleading. The guys who designed Go have not designed any other popular languages in the decades between C and Go. They have not produced any modern developer tools or toolchains. Rob Pike's last language before Go was a quasi-DSL called Sawzall, which is a Google internal language for logs processing. I had to use it when I was at Google and frankly, I would have preferred other languages to hav…

> Both things that Go has a notable poverty of.

It surprises me that you say this, since we (the Go team) spend a huge amount of time and energy talking about our design decisions. But you must have missed it, because the examples you give are wrong.

> For example Google's C++ style guide bans exceptions, partly because writing exception safe code in the absence of garbage collection is very hard. So not having them in Go won't seem like a big deal to many Googlers. But Go is GCd so that rationale doesn't apply, and the others offered are weak.

The rationale for not having exceptions in Go is not about safety, but rather readability. When you're programming with exceptions you need to keep in mind a second hidden path of control flow.

I think you similarly mischaracterise the argument against assertions. In essence, the real reason is that failed assertions produce terrible error messages (that's why Go's testing framework doesn't have them either).

While you're talking to Odersky, ask him about Go. (He said: "I like a lot of the design decisions they made in the language. Basically, I like all of them.")

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

#193

Post by dragonwriter »

Retra wrote: post #191
dragonwriter wrote: post #187

Earlier quoted context omitted.

> Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. This is only true with identical utility functions for all participants. Rational decision making means each actor acts with perfect information about expected utilities of all options and chooses the option that maximizes their own realized utility. Rational actors can easily disagree without ignorance, since rational act…

Only if they are ignorant of each others' utility functions.

They can disagree in which programming language each prefers without ignorance of each others utility functions, or on questions such as "which programming language is best for X purpose?".

While there are some questions where ignorance of each others utility functions could produce disagreement, I can't think of any where it is necessary for disagreement.

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

#195

Post by aikah »

I have mixed feelings about Go.

For those who didn't try it yet here are the biggest advantages of Go:

- it's totally easy to learn and can be mastered in a day

- it's fast and typesafe

- the concurrency model is great,no question

- I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types

- it has, in my opinion a comprehensive standard library,you can even do websockets and image compression with it.

The draw backs :

- no generics clearly the biggest drawback, which means a lot of copy and paste

- the lack of idiomatic way to deal with dependencies(no defacto package manager)

I think the ease of use justifies Go adoption in any team. It doesn't replace ruby or python for web programming ( little value in coding a CMS in Go , rails makes more sense),but when it comes to backend or webservices, it's a killer tool.

compared to java, it's as fast and consumes WAY less memory.

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

#196

Post by seanmcdirmid »

WalterBright wrote: post #135
bbradley406 wrote: post #95

Earlier quoted context omitted.

in addition to what logicallee said, it's common for inexperienced programmers to (poorly) "re-invent" concepts that were discovered in the past by those "smart old people". This is caused by a combination of factors, and one of them is the belief that one can solve a problem single-handedly without studying the fundamentals and previous strategies. Ignoring the work of the masters is a good way to start from scratch…

Sometimes, it's also a way to invent things that were considered impossible.

Yep! Also, reinventing what existed before (intentionally or by accident) can give you a better appreciation for what was invented in the oast and might be the best way of finding out about it (if you don't know the name, for example).

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

#197

Post by threeseed »

sctechie wrote: post #162
throwawaykf05 wrote: post #91

Earlier quoted context omitted.

>... it's small enough to keep in your head... While I mostly agree, the flip side of this statement is, the language then does not automatically take care of things that then you have to keep in your head while you're solving the problem. I guess this is the underlying trade-off people make when using "higher-level" or "lower-level" languages. More "powerful" languages do more for you automatically, but you need mor…

The 'magic' that you seem to pine for like is found in lets say Ruby, places a far larger mental burden on the programmer than a language like c or go. Sure, language like Haskell or Rust have a ton of great features and automagical things but I disagree that they are easier to use. One has to keep far more in your head writing Haskell than Go, a clear indicator of this is the difficulty in learning the language. Lik…

I strongly disagree that features don't lower mental load. For example:

Go's error handling is to put it nicely a joke and requires a lot of effort to manually check every single error condition that may arise. Exception handling makes life exponentially simpler. You can ignore, group and delegate errors at any point which is hard if not impossible to do with Go.

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

#198

Post by CatDevURandom »

danesparza wrote: post #160
CatDevURandom wrote: post #46

Earlier quoted context omitted.

I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+). Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not…

"That's not to say Go is perfect (e.g. a 'real' debugger option)" As a fellow Go coder, I'm actually stunned how much I can get done without a debugger nowadays.

You know, I've heard this a few times recently and it strikes me as motivated reasoning. Yes, built in unit testing and tooling is great. Vet and fmt are helpful. Static typing rocks. But... I would definitely welcome a proper debugger.

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

#199

Post by threeseed »

jksmith wrote: post #83
CatDevURandom wrote: post #46

Earlier quoted context omitted.

I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+). Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not…

>>it's small enough to keep in your head This. And the additional effect is that you can keep more of the problem domain in your head as well. I've been in this game a long time, and my experience has been that the simpler the dev tools, the more likely the programmers working on a particular domain will be SME's in that domain.

My experience is that being a domain expert and simplicity of dev tools has absolutely nothing to do with each other. At the end of the day you have to understand the problem in order to implement it.

Whether you write it in Ruby, Java, Go, Assembler really doesn't change this. It just means you may take longer to do it.

And your logic falls apart. If simple dev tools translate to greater productivity then how do you explain the proven benefits of IDEs with all of their "complex" features.

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

#200

Post by semi-extrinsic »

aikah wrote: post #195

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do…

The lack of a package manager is a good thing, since this is the job of the operating system. That Windows and OSX have crappy/nonexisting package managers does not mean every language should roll its own.

If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.

Post reply on HN