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

221–230 of 264 posts

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

#221

Post by nothrabannosir »

ascotan wrote: post #219
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…

I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version ) They all have their ups/downs and mostly it has to do with the language they are supporting. Nodejs: + transparent code on download - virtually impossible to mirror - executes arbitrary 'script' blocks that install stuff on your system - subpar transitive depend…

go get first searches for a go1 branch or tag and pulls from that, if present. master branch is only a fallback.

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

#222

Post by cgag »

CatDevURandom wrote: post #201
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…

> which means a lot of copy and paste Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about. > the lack of idiomatic way to deal with dependencies(no defacto package manager Again, is this really…

All the for loops and array indexing you do in place of simple map / filter / reduce calls would count in my definition of copy and pasted code.

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

#223

Post by nemo »

Retra wrote: post #164
daviddaviddavid wrote: post #154

Earlier quoted context omitted.

"Ignorance is not a prerequisite for disagreement." This is a very memorable and useful quote. Thanks for saying it. It deserves to be a classic, in my opinion.

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

You'd also have to be profoundly naive to ever assume entirely rational decision-making out of humans, though I get the sense that a number of those words must mean very different things to you than they do to most.

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

#225

Post by threeseed »

donatj wrote: post #78
mateuszf wrote: post #30

Earlier quoted context omitted.

Two words: error handling and generics.

Go's error handling is honestly the best I've ever used. No errors go unhandled. Period. get an error? Return it or deal with it. Makes much more sense than exceptions suddenly breaking the behaviour of the language.

I think you have a misunderstanding of exceptions. In JVM languages for example you have two types: checked and unchecked. Checked exceptions force you to handle errors immediately just like Go. Unchecked doesn't.

There are many situations in which you want errors to go unhandled and bubbled up to some common error handling logic.

Exceptions IMHO are vital. They standardise error handling behaviour across your application and provide flexibility in when, where, and how you handle groups of errors.

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

#226

Post by arthurtw »

unoti wrote: post #217
BuckRogers wrote: post #209

Earlier quoted context omitted.

I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual. For backend/webservices, I initially tended t…

> For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? Two big things here, for my applications. 1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the mu…

> 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.

Correct. When comparing a static programming language to a dynamic one such as Go vs Python, this is a critical difference. It impacts system stability (production outage rate) and code maintainability a lot, the two characteristics a long-running product desperately needs.

But Go is not comparable to C. Go is garbage-collected, so unlike Rust, it is not a true system programming language (i.e. not low-level enough). On the other hand, it is not high-level enough. It lacks many advanced language constructs, and its type system is rather limited. Simplicity is a big merit of Go, but it's too limited IMO.

Go solves many software development problems for large engineering teams, so I think its ecosystem will keep growing for a while.

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

#227

Post by doomrobo »

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…

Is it truly typesafe if the interface{} idiom is commonly used in lieu of real generics?

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

#228

Post by GFK_of_xmaspast »

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.

Aerosmith was hot in the 1970s too.

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

#229

Post by marvy »

dilap wrote: post #102
meddlepal wrote: post #63

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

Here's rsc (one of the core Go dev's page) on generics. http://research.swtch.com/generic They do believe it's a useful feature, they just don't think the tradeoffs justify it yet. (People who loudly clamor for generics tend to ignore these tradeoffs.)

Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.

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

#230

Post by garfij »

talideon wrote: post #97
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.

My only real issue with it is that I really with it had algebraic types. That would save me a tonne of faffing about and help make code safer to boot. Type switches are a clumsy alternative that only cover some of the cases.

Specifically to be utterly pedantic: Go has algebraic types. It has both Product types (structs) and unbounded Sum types (interfaces). What you're looking for is bounded Sum types with extra language support such that when you use them, it checks that you've covered all cases.
Post reply on HN