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

241–250 of 264 posts

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

#241

Post by sigmaml »

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…

I documented a real-life experience here: http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-....

Read the requirement, elaborate a little more by me in some of the comments, and see how the combinations I had to deal with quickly multiplied to cause high tedium.

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

#242

Post by sigmaml »

dilap wrote: post #236
marvy wrote: post #229

Earlier quoted context omitted.

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.

Definitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy. With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sa…

You should, however, note that Go does not have inheritance. That single difference reduces the `crazy stuff' by an order of magnitude. In addition, not having inheritance also means that you do not need to take variance into account, which further reduces the complexity significantly.

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

#243

Post by pjmlp »

semi-extrinsic wrote: post #200
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.

Are you aware how many OSs are out there?

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

#244

Post by enneff »

threeseed wrote: post #238
enneff wrote: post #192

Earlier quoted context omitted.

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

> When you're programming with exceptions you need to keep in mind a second hidden path of control flow So ? Developers are completely used to it. Every time there is a conditional statement e.g. if/else we have to think about the other control flow. Likewise every time a method calls another method. And if that method is in a different class then you again have completely lost visibility. Developers are constantly d…

> Every time there is a conditional statement e.g. if/else we have to think about the other control flow. Likewise every time a method calls another method. And if that method is in a different class then you again have completely lost visibility.

None of that is what I'm talking about. In each case you mention here, it is possible to trace execution by following the code. Each statement passes to the next statement in the block, or—in the case of a branch—very obviously skips to another block or function.

Exceptions provide a second parallel path of execution that may or may not be followed, depending on decisions made in places you know nothing about.

> Java is the 2nd most popular language in the world so pretty sure developers have managed to cope with exceptions just fine.

Arguing "it's popular therefore its good," is a waste of time. Some people obviously like exceptions. I'm just stating the reason Go's designers decided against them.

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

#246

Post by GFK_of_xmaspast »

WaltPurvis wrote: post #89
microtonal wrote: post #71

Earlier quoted context omitted.

But that is so rarely an issue... For you... It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats. Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner. So, yes, the lack of generics is a frequent issue…

Yes, and that does not conflict with what I was saying. There are specific problem domains where generics would simplify matters, but in the overall universe of problems those domains are rare, i.e., most of the code that most programmers will write in Go will not involve duplicating code because of the absence of generics.

I can't remember the last non-trivial c++ program I wrote that I didn't use generic containers like std::vector or std::unordered_set, or the last java program where I didn't use List.

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

#247

Post by tempodox »

dagw wrote: post #41
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…

C wasn't a particularly groundbreaking or future building language either. It basically just took a bunch of well known features from some popular languages at the time and packaged them together in a way that directly made it easier for Ritchie to solve the problem he was working on at the time (developing and porting Unix). So as such Go and C have much in common. edit: Originally wrote Kernighan instead of Ritchie…

FWIW, I love C for what it is. When I learned C, I came from Assembler so C felt like a perfect fit; its thin layer of abstraction wasn't too much of a learning curve and a very welcome addition to the tool chest. I just would have hoped for Go to make a “bigger” jump than C did at its time.

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

#248

Post by dagw »

sctechie wrote: post #205
pcwalton wrote: post #185

Earlier quoted context omitted.

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.

Having watched both complete beginners and competent programmers try to learn Haskell my observation is that hard part initially for the competent programmer is not building the necessary mental model, but tearing down their existing mental model. People with no mental model going in tend to just look at Haskell, go "I guess that's the way things work", and get on with it. Their real problems first arrive when they then go on to try to learn for example Java which has an entirely different model.

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

#249

Post by pjmlp »

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

Regardless of I and others might think about Go's design, every user application that gets written in Go instead of C or C++ (assuming C like code instead of proper safe C++14), is an improvement on the current torrent of CVE exploits.

Post reply on HN