Comment by stcredzero | Hacker News Reader

Comment by stcredzero | Hacker News Reader

The first major mistake was using a C derived syntax

Personally, I'm not that interested in the particulars of indentation/block delimiting. I'm much more interested in what one can do with blocks. This has much more bearing on the power of a programming language. If this is the 1st issue discussed, it's a poor portent for the rest of the article.

The next mistake is having a separate declaration and assignment operator.

Is this really so different from having a separate comparison and assignment operator? Or having 2 or 3 flavors of comparison?

The final mistake was not providing generics.

This is a work in progress.

C++'s templates is one of the things that make the language head and shoulders more useful for me than C...One of the things I've found makes me most productive in Python is that any time I need to perform a task I simply pick the data structure that does what I want

I think you can have completely generic collections in Go if you give up type safety for it.

In terms of features which I believe are overhyped the most important one is the "goroutine".

It's my understanding that one can use "goroutines" to implement your own rather powerful control structures. I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels.

Further, the handling of interfaces, though interesting, appears to be an implementation of C++0x's proposed concepts...I view this feature as something that is most useful in the context of generics

Thsi makes it seem as if you view programming somewhat through the lens of generics. This treatment of Interfaces gives you one of the best things about "Duck Typing" languages, but in a statically typed language: "emergent" interfaces.

"I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels."

I continually find exception handling to be a huge source of frustration; especially Java's checked exceptions. If I explicitly test for something in my method before calling another method, should I still have to catch, rethrow or declare that I throw its exception? If I don't check for the exceptional case first, then aren't I now using exceptions for flow control?

Unchecked exceptions seem a little more logical to me, but they still seem to cause disagreement on how they should be used.

The fact that they decided to put exception handling on hold here for now is really encouraging to me.

"there are very compelling reasons for not having exceptions, given goroutines and channels"

This confuses me I would have thought the opposite would be true. The goroutine/channel concept seems Erlang like to me. Erlang uses exceptions, if a process crashes an exception is thrown to its parent which can then act appropriately. How does Go handle this, i.e. if a goroutine crashes who gets informed and how?

I'm not sure there's always going to be a "parent."

goroutines are Erlang-like. Erlang doesn't have 'exceptions' though. In Erlang, if a process crashes (simulated or unexpectedly) it implicitly sends a specific message to it's parent. In Go you can emulate this by just checking for return values of stuff you do in the goroutine and send a similar message if it fails.

The fact that Go is in early development here and I'd say this both could and will be improved in the future.

"It's my understanding that one can use "goroutines" to implement your own rather powerful control structures. I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels."

The "goroutines" are just threads. They're not useful for building control structures. Unless you have continuations/a reified control stack or program in a monadic style (which would essentially be CPS in this case), you cannot "fake" exceptions.

I'm not talking about "faking" exceptions. I'm talking about just not using them. Instead of "catching" exceptions down (up? In my debugger, it's down) the stack, you can just detect errors and send something down a channel. If you can conveniently send the current function's pointer, or better yet, the current context, you can do much of what you'd use exceptions for.

How do you detect errors? That's the question that the exception-handling part of exceptions is designed to solve. Having every function need a reference to a channel is really no different than error detection using return codes.

You can build one-shot continuations on top of asymmetrical co-routines, though, and multi-shot continuations if you can copy them. I don't know about "goroutines", but I've done it with the co-routines in Lua.

(For a good analysis of the overlap of co-routines and continuations, see "Revisiting Coroutines" by de Moura et. al. - http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf)

A mostly agree with your point of view. I would like to add that I think the author confuses generics with templates. The former is done using casting and RTTI, while the later is done by generating new code / new classes.

Reply on news.ycombinator.com