Good news! I think Go is the best alternative between C speed and simplicity of Python!
The Go Programming Language by Brian W. Kernighan, Alan Donovan
51–60 of 264 posts
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#52Go, 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.
You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens wit…
In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed.
Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors).
This is not a critique of Go, just to point out that it is a trade-off, and there isn't necessarily one right answer.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#53Does anyone know if they are selling a digital version?
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#54Go, 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.
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…
You might find this interesting: http://www.reddit.com/r/programming/comments/2wy2qe/gos_comp... , my reply to someone's question about what is interesting and/or unique about Go. A bit much to just copy & paste in here, probably.
While so many people are complaining about what it doesn't have, there are things it does have that, while not individually unique, are actually packaged into a unique bundle. Particularly the fact that it is a traditional imperative language. If you (like me!) don't mind picking up Haskell or O'Caml or Erlang to get weird features, it might be hard to understand the appeal, but for many people Go is the first time they've seen these features without having to drop almost everything they know about programming on the floor in the process. This probably explains some of the breathless excitement it sometimes engenders... it's the same breathless excitement that people will sometimes have when first using those other languages.
(And, yeah, the traditional imperativeness does bite a bit. I'd love to be able to assert that a goroutine is fully isolated from everybody else's memory. In practice, I'm not having any trouble with that, but, then, I've got 7 years or so of Erlang under my belt so designing isolated processes that work together via clean interfaces is something I've got a ton of experience with from the most rigid language on this topic there is. YMMV, and I really mean that... you certainly can blow your foot off in Go, isolation is only convention, not enforced.)
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#55Awesome. For those who don't know, Kernighan is the "k" in "awk" :)
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#56Go, 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.
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 it the way he did, I'd probably just assume he knows WTF he's doing.
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.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#57Earlier quoted context omitted.
Two words: error handling and generics.
Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
No garbage collector so I can actually use it in embedded situations.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#58Earlier 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…
You might find this interesting: http://www.reddit.com/r/programming/comments/2wy2qe/gos_comp... , my reply to someone's question about what is interesting and/or unique about Go. A bit much to just copy & paste in here, probably. While so many people are complaining about what it doesn't have, there are things it does have that, while not individually unique, are actually packaged into a unique bundle. Particularly…
While so many people are complaining about what it doesn't have,
The problem is not really what Go does not have, it's that often fallacies are used to react to critique on Go. Another one that pops up very often is 'you just have to use it for some time to understand why Go does not need it'.
This is of course nonsense. Anyone who has programmed C and C++ knows the advantages and disadvantages of generics. And despite the disadvantages of a particular implementation, most people want still want generics for good reasons.
Even if you like Go (and I do mostly), it's ok to say 'sure, that is a weakness in the current version of Go'.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#59In 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…
I think this comment is awesome and makes total sense if you read it in Comic Book Guy voice. Actually, I think Comic Book Guy voice works for so many of the comments that get downvoted on HN. There should be set of tags that mods can put around a comment to signify "relevant and humorous if read with Comic Book Guy voice", so that the community doesn't miss out on comedy gold.
OMG, I can't upvote this enough :)
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#60Earlier quoted context omitted.
You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens wit…
In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors). This…
But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly if I'd known Go better).