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

201–210 of 264 posts

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

#201

Post by CatDevURandom »

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 a big deal? There's plenty of options, and if you are shipping any-type of commercial product you are going to want to be vendoring your dependencies in-house anyway. In which case, depending on something like NPM/remote maven repos is not a viable options anyway.

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

#202

Post by lispm »

masklinn wrote: post #155
wbl wrote: post #104

Earlier quoted context omitted.

Are you talking about Common Lisp, or are you talking about Scheme? Common Lisp does provide primitives for just about everything, in ridiculously generic forms. Scheme forces you to code it yourself.

> Common Lisp does provide primitives for just about everything Most of it are not primitives though, Common Lisp only defines 25 special forms. Guess how many keywords Go has?

I would see more 'primitives' in a language than 'special forms'.

For example Common Lisp provides support for complex numbers and operations for them. These operations are 'primitives' in the language. This is unrelated to 'special forms'.

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

#203

Post by sampo »

gnuvince wrote: post #144
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.

Simple languages are good, but we should be careful to understand why they are simpler: in many cases, the complexity is simply shifted from the language onto the programmer. Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.

Maybe, if there were several official "levels" defined for complex languages (like Scala). So then a team that wants to keep codebases conceptually simple could decide that they are only using features up to e.g. level 3, anything above is forbidden. And the compiler would support this.

A bit like you can select different languages in Dr. Racket http://docs.racket-lang.org/drracket/choose-language.html

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

#204

Post by zik »

gnuvince wrote: post #144
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.

Simple languages are good, but we should be careful to understand why they are simpler: in many cases, the complexity is simply shifted from the language onto the programmer. Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.

> the complexity is simply shifted from the language onto the programmer.

That's not my experience with Go at all - it provides less resistance to getting code written than any other language I can think of offhand.

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

#205

Post by sctechie »

pcwalton wrote: post #185
sctechie wrote: post #162

Earlier quoted context omitted.

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 don't think you can really learn C in a weekend. Not with all the ins and outs of undefined behavior. And if you don't know your way around the undefined behavior in C, you're going to make dangerous mistakes.

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.

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

#206

Post by rubiquity »

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…

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

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

#207

Post by frowaway001 »

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

I'd love if people would stop linking to something which is so obviously wrong (or at least read it before linking).

Go devs made it clear that Go won't get Generics, and it's fine.

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

#208

Post by frowaway001 »

sangnoir wrote: post #107
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.

As far as I recall, the apologists don't say generics are bad - but rather, not necessary (at times conceding they are useful). Which sounds reasonable to me. Who needs generics? 'Need' in it's dictionary sense. i.e. is there an algorithm you can't write in a language because the language lacks generics? Great to have? Yes. Need? No.

Yet another Turing tarpit argument?

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

#209

Post by BuckRogers »

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'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 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? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust.

Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for. I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least.

I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.

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

#210

Post by kornish »

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.

Not quite: here's an example of code which returns an error but for which the return value is never even captured. http://play.golang.org/p/EL2-2gl7wh
Post reply on HN