Hacker News Reader

Comment by fingerprinter | Hacker News Reader

I guess I might be the only one to say this, but is this a joke? Some sort of prank? Not a single Go program is more readable, and I would argue that they are ALL less readable (and I like Go).

I honestly can't tell if he is trolling or if he is serious.

View on HN

He's picking a bunch of problems C is really good at and then roughly, fairly mechanically translating to Go.

I don't think he's trolling, but I do think he's playing to C's strengths and Go's weaknesses, possibly by accident.

I agree. I don't see anything wrong what he did, but somebody should offer to submit counterpoints that better emphasize what Go is able to do.

I think many counterpoints should be fairly obvious. Anything from "return a return value and an error code from a function" (trivial in both, way nicer in Go though) to "write a webserver from scratch. Which did you just schedule more time for?"

Or anything that needed to be run in parallel.

I think Go's strengths over C really start to shine when you're writing programs longer than 100 lines. Not having an exception mechanism, interfaces, single namespace, no attaching methods to structs etc are fine in a small program, but they make bigger programs harder to digest pretty quickly.

Calling Go's panic/recover system a proper exception mechanism is quite a stretch.

I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.

All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google):

It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.

I disagree that panic/recover is worse than exceptions, I find it a more pleasant and lightweight mechanism, but the big difference is that panic/recover are not used like exceptions at all in Go, they are basically used only for programmer errors.

They can be used for other things, but in those cases they never cross API-calls so you never have to worry about whatever a library you call might panic, you can basically ignore panic/recover exists completely, and do just fine, and that is what most people do most of the time.

Well, we can argue about whether or not an exception mechanism is the best way to deal with program error conditions, but my first point still stands, which is that Go does not have a proper exception mechanism. If defer/panic/recover were to be used as a true exception system you would run into all the issues Andreas details.

> It really looks like no one with an up-to-date PLT background was consulted in the design.

"Go is not meant to innovate programming theory. It's meant to innovate programming practice." I really like the out-of-band errors since they make control flow very explicit. With languages that rely on exceptions a lot (python, for example) I feel less in control of my program since 'anything can happen' remotely from my code.

Sorry, by "out-of-band errors" do you mean the error return value? This is not a terminology I'm familiar with.

For any function which produces values of the form (a -> (b,e)) I'd refer to that as a product type. If this is what you're referring to, this is just a return value. There isn't really an exception system here.

If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition. This is basically the same as (b,e), just worse type safety. Easy and efficient tuple constructions are hard to create in languages with manual memory management.

Edit: Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.

> If this is what you're referring to, this is just a return value. There isn't really an exception system here.

Yes, which is awesome.

> If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition.

This would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from communications theory. You also see it used to describe an 'out-of-band' console that is a secondary way to SSH into your machine if your network is hosed.

> Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.

I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on. Take garbage collection: this was technology that had been around for decades, but computers and garbage collection algorithms had to be sped up and tuned before general adoption. Large systems demand predictability and integrity on nearly every dimension. Luckily as time goes on, the experimental stuff becomes the expected; advanced programming language theory gets built into larger systems and we all benefit. Go is part of that evolution.

I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on.

No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT. As far as I can see, defer/panic/recover is objectively worse than an exception system for all of the goals which they lay out in their paper.

You like return values--ok, I can see that. I prefer that the type checker actually enforce error checking when using error return values, but fine.

Adding defer/panic/recover is an attempt to add a simpler and more constrained exception-like system to the language, but I think it is objectively (both from a PLT perspective and compiler-design perspective) worse than a more traditional exception system. Breaking beta-reduction is very unfortunate and I can't see a good reason to do it in this case.

> No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT.

Ken Thompson won a Turing award, dude.

In 1983, 24 years before starting work on Go. That's a lot of time to fall behind on new research.

http://en.wikipedia.org/wiki/Argument_from_authority

"Go is not meant to innovate programming theory. It's meant to innovate programming practice."

I don't think GP was saying that Go should have provided some advance to programming language research, but that it doesn't show much awareness of advances that have already been made.

    [Go] doesn't show much awareness of advances that have
    already been made.

Go's response would be to question that the things you're talking about are, in fact, unqualified advances. Especially in the context of large (ie. LOC) systems applications, maintained by large (ie. dozens to hundreds) of developers.

Java, C#, Python, Lisp, and Erlang would all criticize Go for an unqualified new exception system which has not proven that it can handle itself in the context of large systems applications, unlike all the previous languages.

    Java, C#, Python, Lisp, and Erlang would all criticize 
    Go for an unqualified new exception system

panic/recover is not an exception system in the sense that you mean. Nobody is writing large applications and using panic/recover for error handling. (At least, I hope not!) The idiomatic way of handling errors in Go is returning them explicitly, and checking for them at the call site.

    func canFail() (int, error) { ... }
    
    value, err := canFail()
    if err != nil {
        // handle
    }

Well, the operating system you used to write that comment was probably written in C, so apparently it does in fact work in large projects. It has weaknesses to be sure, but I don't think lack of OO (I.e., structs with functions) is one of them.

Particularly given that you can write OO code in C, and can decorate structs with functions, it's just messier.

"Object oriented programming with ANSI-C":

https://ritdml.rit.edu/handle/1850/8544

Duh. "Done" and "easily done" are different things.

Structs with functions isn't the biggest deal, and namespaces can be simulated with a couple underscores. But I have a hard time with error handling if you don't have exceptions, any time I have a call stack more than 3-4 deep I find myself confused about how to treat certain errors. Then there's concurrency.

It's worth noting that the bulk of the code in the kernel comes from 900 different network drivers, each of which could be considered a small program in its own right.

I disagree. After only a brief runthrough of Go, the different types of statements are very recognizable line by line. The sytax includes less obvious breaks and parens, but I think that makes the code a lot more readable because it eliminates the nastier paren nesting you often see in C. I think the first example in chapter 2 gives clear indication of the benefits of eliminating the features of C which are more compact but less readable.

I've gone ahead and reformatted his code using `indent -kr` and `gofmt`: https://gist.github.com/2932444

He is definitely serious.

I do think that all semicolons really shouldn't be used. The only time I ever use semicolons is for error checking in Go.

Judging by the similarity to his much large section on C (http://crypto.stanford.edu/~blynn/c/) I'd say serious.

Also, who cares what his style is?

If _you_ ever have to work on the code, run gofmt on it; if that's how he likes his go, good for him.

Also, who cares what his style is?

Me, because I found it unpleasant to read. Working on such code is beside the point.

He's not helping by explicitly stating that he's ignoring gofmt style. Those examples would look lengthier but cleaner if he would run gofmt on them.

Reply on news.ycombinator.com