Google's new "Go" language [LWN.net]

Google's new "Go" language

Posted Nov 11, 2009 15:46 UTC (Wed) by simlo (subscriber, #10866) [Link]

Isn't
x:=0

equal to

var x = 0

I.e. make variable x and set it to 0 (which is an int and therefore x is int).

Google's new "Go" language

Posted Nov 11, 2009 15:46 UTC (Wed) by nas (subscriber, #17) [Link]

The language piqued my interest since it appears to have some attractive qualities. However, how can you design a language in 2009 without exceptions? That just boggles my mind.

Google's new "Go" language

Posted Nov 11, 2009 19:01 UTC (Wed) by elanthis (subscriber, #6227) [Link]

A lot of hardware flat out can't do exceptions in a performant fashion, like all the major
gaming consoles. Granted, Go has no appeal to game programmers.

Homestly, all these c-like c++ replacement languages miss the point of why c++ is so
popular: near 100% c compatibility. If I have to write code or definition files to bind c
libraries, the language already costs me more time than it can save over c++ (especially
c++0x).

Fixing the warts of the c syntax is great, but unless you can do it while maintaining support
for the c syntax as well (even if it requires marking sections of c code) with enough support
to use OpenGL, gtk, directx, and Lua without writing additional wrapper
code, the language is useless to at least one major portion of the software industry. Which
is fine if the designers don't care, of course.

Google's new "Go" language

Posted Nov 11, 2009 21:43 UTC (Wed) by nix (subscriber, #2304) [Link]

A lot of hardware flat out can't do exceptions in a performant fashion

The hardware would have trouble distinguishing an exception (either sjlj-style or DWARF2 table-style) from a few jumps. I find this sort of hard to believe.

Google's new "Go" language

Posted Nov 11, 2009 23:33 UTC (Wed) by ikm (subscriber, #493) [Link]

Does one need some sort of hardware support in order to implement exceptions? That sounds new to me. What kind of support is that? And how do gaming consoles differ from other computers in that regard?

Google's new "Go" language

Posted Nov 12, 2009 2:14 UTC (Thu) by BrucePerens (subscriber, #2510) [Link]

A lot of hardware flat out can't do exceptions in a performant fashion, like all the major gaming consoles.

Whoever told you this, it's just not true.

Doing exceptions from a lightweight coroutine context might make it heavier, I guess. You have to save some amount of context from the death of the coroutine until someone comes along to collect it.

Google's new "Go" language

Posted Nov 12, 2009 10:08 UTC (Thu) by cortana (subscriber, #24596) [Link]

I have yet to run into problems using exceptions on the Nintendo DS. :)

Google's new "Go" language

Posted Nov 13, 2009 13:22 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

"near 100% C compatibility" is achieved by shouting at C programmers every time their perfectly legal and readable C won't compile in your C++ compiler

That's no kind of compatibility, it's just bullying. I've yet to work on a large project with a C++ programmer where they don't come to me and whine about how, yes, they said they could fit in just fine with the tens of thousands of lines of existing C code, but they assumed for some reason that we meant "C++ code written using a language subset that looks like C" rather than what we said, which was "C".

It would have been better if C++ had accepted that it wasn't compatible, eliminated silliness like "extern C" and attempts to be syntax compatible so that nobody got the wrong idea. Out of all the languages I know well enough to actually write serious code in them, C++ is by far the worst, and that's before allowing for the fact that it's frequently a mistaken choice anyway (ie some project manager knows C++ and Java, they can't figure out how to solve the problem in Java, so their next choice is C++ when really they needed Prolog, or a shell script)

So, hopefully Go, unlike C++ does enough of the Right Thing to be worth using in its own right, rather than trying Stroustrup's cheap trick of merely claiming to be no worse than some other language when actually they've done away with its best feature ("C is not a big language").

Google's new "Go" language

Posted Nov 12, 2009 7:15 UTC (Thu) by jhoger (guest, #33302) [Link]

Entrance to the structured exception fan club requires a certain level of insanity. Does it really seem likely that in the face of an error or exceptional event that one should scramble randomly up the stack to some random higher scope? Is GOTO suddenly a good thing if you put lipstick on it and call it a "Structured Exception." Most people seem to be scared (mistakenly) about leaving a multiple exit LOOP. Yet the same folks will design an API that throws exceptions as expected behavior.

Further, to write code that leverages a system where structured exceptions are the insanity du jour, every properly written call into that system looks like an armed encampment bristling with defensive weapons, waiting for the API to invade its territory at any moment. Oh, but we're ready, with a thorny nest of exception type-specific contingencies.

Structured exceptions are the worst thing to happen to program maintainability that I've seen in my 20 year career (overloaded operators is a distant second). I prefer the simplicity of a return code and discipline of error checking being the responsibility of the user of the module. Really, C programmers have got along just fine without exceptions. Well, divide-by-zero is the, um, exception...

Google's new "Go" language

Posted Nov 13, 2009 21:29 UTC (Fri) by dvdeug (subscriber, #10998) [Link]

"Is GOTO suddenly a good thing if you put lipstick on it and call it a "Structured Exception.""

Unlike loops, structured exceptions can't be emulated with gotos.

"every properly written call into that system looks like an armed encampment bristling with defensive weapons, waiting for the API to invade its territory at any moment. Oh, but we're ready, with a thorny nest of exception type-specific contingencies."

So how does this differ any call in C? In either case, you have to deal with a variety of errors from any system call. The only difference is that ignoring it completely might give the person whose program just crashed some more information about what went wrong than "segmentation fault".

"C programmers have got along just fine without exceptions."

Yeah, random program crashes because no one bothered to check the results of malloc and fopen are just great. One of the goals of exceptions is that you don't have to handle every error at its home, and that a consistent way of warning the calling function that something has gone wrong means an error is more likely to be acknowledged. Worst case scenario, a program in a language with exceptions can usually realize that something has gone wrong and clean up and exit gracefully, instead of plowing ahead until the compounding errors cause the program to crash or hang.

Google's new "Go" language

Posted Nov 16, 2009 19:01 UTC (Mon) by oloryn (guest, #7408) [Link]

I always thought exceptions were a variant on a 'Computed Come-From', with all of the attendent implied ickyness.

Google's new "Go" language

Posted Nov 19, 2009 16:43 UTC (Thu) by Baylink (subscriber, #755) [Link]

What's icky about those? :-)

Google's new "Go" language

Posted Nov 11, 2009 15:58 UTC (Wed) by nye (guest, #51576) [Link]

I find this particularly interesting, since it's the first time I've read about the design philosophies of a language and disagreed with it more-or-less in its entirety. Plus the syntax is a disaster - those variable declarations make me want to barf for a start.

This language appears to be pessimal, which is quite fascinating considering the source.

Google's new "Go" language

Posted Nov 11, 2009 16:11 UTC (Wed) by dgm (subscriber, #49227) [Link]

It reminded me of the "worse is better" development philosophy.

Google's new "Go" language

Posted Nov 12, 2009 0:16 UTC (Thu) by cowsandmilk (subscriber, #55475) [Link]

pessimal? or piecemeal? or what?

Pessimal, says Mel

Posted Nov 12, 2009 3:38 UTC (Thu) by felixfix (subscriber, #242) [Link]

The Story of Mel

Google's new "Go" language

Posted Nov 19, 2009 16:44 UTC (Thu) by Baylink (subscriber, #755) [Link]

I don't have enough background to judge it on that front, but to the extent that's true, I wonder if it's Second System Effect writ large?

Google's new "Go" language

Posted Nov 11, 2009 16:24 UTC (Wed) by epa (subscriber, #39769) [Link]

As another poster pointed out, having to check return values manually is incredibly losing compared to exceptions. With a bit of imagination they could have done something to satisfy both the pro- and anti- exception camps. As a random idea, perhaps if a function foo() can throw an exception, then when you call it you must either put it in an explicit try { ... } block, or acknowledge that you want all exceptions rethrown, as
x = foo() rethrow;
or, perhaps, an explicit way to convert 'exception or no exception' into a Boolean return code to satisfy old-school programmers:
bool = success(x = foo());
Going back to the dark old days of success codes - which you must manually remember to check every time - is hardly a way to build robust software.

Google's new "Go" language

Posted Nov 11, 2009 20:52 UTC (Wed) by dw (subscriber, #12017) [Link]

What you describe sounds something like the checked exceptions Java has. The reason these were a terrible idea is that they often completely braindamage encapsulation, unless you define your interfaces to always "throw Exception". Otherwise, any abstract interface must include the exact exceptions thrown by any implementations of that interface.

Most of the complaints here were mentioned and justified in the Go literature.

Google's new "Go" language

Posted Nov 12, 2009 15:58 UTC (Thu) by alankila (subscriber, #47141) [Link]

Really, there are two general ways these cases are handled:

1) declare a general-purpose wrapper exception for the implementations to throw when none of the other types describe the problem.

2) since RuntimeExceptions are not checked, derive your own exceptions from that type.

I'm not sure if people do 2) at all. It's probably appropriate for cases where you are almost 100% sure the call will never fail, so you can avoid cluttering the API with an exception type that in practice doesn't occur. Like for Charset.forName("UTF-8"), or Digest.getAlgorithm("MD5") or whatever.

Google's new "Go" language

Posted Nov 11, 2009 21:38 UTC (Wed) by rvfh (subscriber, #31018) [Link]

Exactly. "#!/bin/sh -e" is my best friend!

Google's new "Go" language

Posted Nov 12, 2009 6:42 UTC (Thu) by nevyn (subscriber, #33129) [Link]

As another poster pointed out, having to check return values manually is incredibly losing compared to exceptions.

I disagree. 99% of the time exceptions occur for things that aren't "exceptional", so you have to work around it by catching them everywhere (or create helper functions which catch and return error values). They are also completely invisible exit points from functions, where you have no control over the state of the program ... so if you catch them at higher levels you can't do much more than print a nicer traceback.

With a bit of imagination they could have done something to satisfy both the pro- and anti- exception camps.

I don't see how you can think your success() example is better than their "multiple return values, one of which is an error indicator". But even if you do, you can easily convert from their style to win3^W yours.

A good thing to think about is probably the problem of "open". Pro-exception people tend to want this to throw FileNotFound and PermissionDenied ... because a majority of the time you are reading files that are there and readable.

Anti-exception people tend to hate exceptions here because: 1) Not being "a majority" isn't even close to "exceptional". 2) Putting an exception here makes it ugly as hell to do "open if you can" type operations. 3) #2 often means the resulting code is worse, generally (Eg. python is so bad it's common practice to just use os.path.exists and have a race condition).

Then you have the general complaints for things like at least 99% of the time it's just not that hard to check the return value of open() and dtrt. and anyone with a little experience does it. And that having exceptions on open means that if you add an open call to existing code you need to make sure it can handle the file exception being thrown there, or more likely you have to catch it anyway and do something else (thus. you just have more lines of code to always check the return value anyway).

Google's new "Go" language

Posted Nov 12, 2009 12:44 UTC (Thu) by epa (subscriber, #39769) [Link]

99% of the time exceptions occur for things that aren't "exceptional", so you have to work around it by catching them everywhere

But equally, if you have 'return 0' to indicate failure, then 99% of the time 'return 0' occurs for things that aren't exceptional, so you have to work around it by testing return values everywhere.

They are also completely invisible exit points from functions, where you have no control over the state of the program

If you choose to let them propagate, yes. This is the biggest problem with exceptions in my view. I would prefer some model where you had to explicitly choose whether to catch and handle the exception or send it up to your caller.

Then you have the general complaints for things like at least 99% of the time it's just not that hard to check the return value of open() and dtrt. and anyone with a little experience does it.

Hmm, and anyone with a little experience also remembers to check the success of every puts() and write() and printf() - not to mention memory allocation?

(Come to think of it, with growable types such as the built-in 'map' but without exceptions, how does Go deal robustly with out-of-memory errors?)

Google's new "Go" language

Posted Nov 12, 2009 13:46 UTC (Thu) by salimma (subscriber, #34460) [Link]

That is the Java checked-exception model -- the only problem with it is that programmers *are* explicitly choosing to let exceptions propagate.

Still better than .NET, where Heljsberg just basically gave up on the idea (ah, the joy of debugging C# applications where *any* exception could happen anytime).

Perhaps the compiler should throw a warning for any re-thrown exception, judging it to be bad style...

Google's new "Go" language

Posted Nov 12, 2009 15:38 UTC (Thu) by nevyn (subscriber, #33129) [Link]

But equally, if you have 'return 0' to indicate failure, then 99% of the time 'return 0' occurs for things that aren't exceptional, so you have to work around it by testing return values everywhere.

I don't think I understand your point. Yes, you get the "error return value" for things that happen often enough they aren't exceptional ... and so you have to test for them. But my point was that exceptions are only good when you don't have to test for them, when you do have to test for them return value testing takes less code and is much easier to read.

Hmm, and anyone with a little experience also remembers to check the success of every puts() and write() and printf() - not to mention memory allocation?

It's common to just test ferror/fclose instead of testing every call to a write function (esp. as close might be the first time you get an error).

(Come to think of it, with growable types such as the built-in 'map' but without exceptions, how does Go deal robustly with out-of-memory errors?)

fgrep "out of memory" **/*.c has quite a few hits. But to be fair, I've never seen a program that has exception based OOM "deal robustly" with it (It often sucks even more because a huge number of lines of code can throw it in those languages) ... admittedly with malloc() it's kind of a slog to do it, and most people prefer to define their own xmalloc() and ignore the problem.

Google's new "Go" language

Posted Nov 12, 2009 23:09 UTC (Thu) by epa (subscriber, #39769) [Link]

I think there are two separate issues: whether to use exceptions at all, and the boundary of what is considered 'exceptional'. You could mechanically convert every 'return 0' style function into an exception-throwing function, and vice versa, and it wouldn't change the amount of work the caller has to do to check the result (especially if some simple 'success(...)' primitive were provided in the language). The only thing that changes is that if the caller neglects to check at all, then in the 'return 0' case the code continues merrily on its way, while with exceptions it gives some kind of error, perhaps an ugly and unexpected one, but nonetheless something.

There is also the question of whether 'failure to open a file is hardly exceptional'. You might imagine an open() function defined as 'returns filehandle, or null if file not found'. Throwing an exception on file not found might be considered too bossy and awkward. But then, I would be content for such a routine to throw an exception if it got a hard I/O error or the current directory no longer existed or some odd condition like that.

But my point was that exceptions are only good when you don't have to test for them, when you do have to test for them return value testing takes less code and is much easier to read.

Not entirely, because often you're content to use the same exception-handling code for a block of several function calls. For example

try {
   f();
   g();
   h();
}
catch (Exception ex) { ... }

is less code than

if (! f()) { ... }
if (! g()} { ... }
if (! h()} { ... }

and less baroque than something like

if (! (f() && g() && h())) { ... }

Still, style discussions could go on all night. I would just like to suggest that some easy syntactic sugar such as 'success()' - or whatever - to unify the try-catch style and the check-return-value style might help reduce boilerplate code; and that exceptions don't have to be a baroque class hierarchy as in Java, but could be something more lightweight that helps the programmer write robust code by default without getting in the way.

Google's new "Go" language

Posted Nov 13, 2009 11:12 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> try {
> f();
> g();
> h();
> }
> catch (Exception ex) { ... }
>
> is less code than
>
> if (! f()) { ... }
> if (! g()} { ... }
> if (! h()} { ... }

This is a matter of style. Consider an alternative:

f(ok);
g(ok);
h(ok);
if (!ok) { ... }

Granted, this style requires that each function will have an extra ok parameter and the code inevitably will have quite a few ok checks. But when done consistently this style removes most of the ugliness of the repeated if checks and really raises the question about the need of exceptions.

Google's new "Go" language

Posted Nov 13, 2009 11:25 UTC (Fri) by farnz (guest, #17727) [Link]

But now, you've made the contents of f(), g() and h() uglier. Every function has to look something like:

function( ok, ... )
{
  if( !ok )
    return;
  manipulate ...
}

Otherwise, what stops you getting into a state where f() was supposed to set up the world ready for h(), g() was supposed to modify that set up slightly (but fails in interesting and unfriendly ways, because the state that should have been created by f() doesn't exist), and h() bombs badly because the state it expected didn't exist at all, due to f() failing?

Further, every function needs a valid return value for the early exit case. This all just feels to me like a bad reinvention of exceptions, and I don't see how it's any better.

Google's new "Go" language

Posted Nov 13, 2009 13:04 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> you've made the contents of f(), g() and h() uglier

Yes, but if the function has more then one call site (very typical), the ugliness is limited to the function itself, not to all its callers.

> Further, every function needs a valid return value for the early exit
case.

The most difficult case is when returning an allocated memory/object. If one just returns a null, the following crashes:

a = f(ok);
g(a->somefield, ok);

To deal with such cases one can return a special statically allocated object.

With such tricks the overall impression from a code written 15 years ago in that style was a surprisingly clean and easy to reason about code with ugliness limited mostly to parts that interacts with system API.

Google's new "Go" language

Posted Nov 13, 2009 13:32 UTC (Fri) by farnz (guest, #17727) [Link]

So basically, I get all the pain of return codes (having to mess up all my computation code with error handling logic to pass ok around and deal with it correctly when something goes wrong), and I get none of the benefits of exceptions (being able to write code that ignores errors when I cannot think of a sensible way to handle them)?

Doesn't sound like a good tradeoff to me; the big benefit of exceptions is that it's easy to let them propogate upwards when I can do nothing about the error (the common case). The only code that ends up looking ugly is code which knows how to cope with errors, not code that can't do anything sensible.

In some cases (such as tiny tools), the only sensible thing to do is use an outer wrapper that reports the error (usually language provided, as in Python's tracebacks). In others (such as the application I work on), there are certain errors which I can catch and do something sensible about (e.g. absence of required files triggers me to create default versions). I really can't see how having to add huge piles of ugly error state passing code all over the application would make it neater.

Google's new "Go" language

Posted Nov 13, 2009 13:29 UTC (Fri) by hppnq (subscriber, #14462) [Link]

There is one simple rule that applies here, I guess: refactor your code.

Google's new "Go" language

Posted Nov 13, 2009 14:18 UTC (Fri) by MKallas (guest, #38539) [Link]

(Eg. python is so bad it's common practice to just use os.path.exists and have a race condition).

This is only if you're doing it wrong. Just try to write your file and if it fails, you get your exception. No problem here. :)

Exception handling

Posted Nov 15, 2009 13:48 UTC (Sun) by fjalvingh (guest, #4803) [Link]

A lot of the people here do not really understand exceptions and how they should be used. Statements like

99% of the time exceptions occur for things that aren't "exceptional", so you have to work around it by catching them everywhere (or create helper functions which catch and return error values).

are an indication that exceptions are used in the same way as old return-value based error handling - and that is of course clearly useless. Using it like that indeed does not pose any enhancement.

Sadly enough, the Java checked exception blunder causes a lot of people to hate exceptions and makes it harder to see the real value. Every time you have to catch an exception and rethrow some other one, simply because some idiot decided you could only throw MyBeautifulException is a complete waste of time, and code like that indeed looks like old-style code: you still have to do something for *every* error, and exceptions do not gain you anything. If you see code like that a lot it seems like that is proper use of exceptions - but it isn't.

99% of the time exceptions occur for things that aren't "exceptional"

Exceptions should indeed represent something exceptional, and at least in Java they mostly do. Why is not being able to open a file (possibly for a myriad of different reasons!) not exceptional? Clearly once you decided to open it you intended to do something with it - so not having it is a problem. The real gain in proper exception usage is in better behavioural control AND in WAY better control of error detail: What would *handling* that case mean usually? Reporting an error message? Where? Should the program stop? Is this a GUI application or a console one? What was the *reason* for the open failure? Network error? Bad disk? Disk full? If your subroutine opens 15 files- which one failed? How do you put that in an int??

Having exceptions means you have a meaningful and generic method of passing lots of information on the error, and delegating it's handling means low-level code does not need to handle things it does not know how to handle.

Comparing this with the return value approach is laughable. I still remember the beautiful Microsoft hex error codes used in COM. If you ever got one your only resort was to start the debugger and try to find out what actually went wrong, this could take hours. A single errno code or whatever holds hardly any information, is only correct if the software builder has thought about it deep and hard, and makes for fragile and badly maintainable software.

Other people make the argument that testing for errors in return values is so easy, and that any competent person does that routinely. Well, I probably worked with a lot of incompetents then, and 99% of C software I've seen is probably written by morons also? Because an enormous amount of code does NOT properly check these kinds of errors. Malloc and friends are notorious of course, but you see it everywhere. Clearly it is NOT very easy to check everything for errors, and you have to have a lot of discipline doing it. In addition, if you DO check it is often hard to decide what do do with it. Of course you return "I failed" - but how do you tell the reason?

In reality people are lazy mostly, and there are a lot of mediocre (say normal) programmers out there that often forget checks. I by far prefer that stacktrace, indicating the details and the location of the missing check, above error c0050001.

Proper code using exceptions hardly ever catches them. In properly written code you see only try/finally blocks used for resource management, and only on library boundaries or application main points do you see catches.

They are also completely invisible exit points from functions, where you have no control over the state of the program ... so if you catch them at higher levels you can't do much more than print a nicer traceback.

Another indication that you're simply using them wrongly. Granted, using exception handling means that you *have* to know that exceptions do occur. It means you have to do proper resource handling. It does not mean that you have to catch everything. And you have full control over the state of the program, of course; writing finally or catch is not much different from if(returnvalue==) - you have to know which functions to check there also.

Anti-exception people tend to hate exceptions here because: 1) Not being "a majority" isn't even close to "exceptional". 2) Putting an exception here makes it ugly as hell to do "open if you can" type operations. 3) #2 often means the resulting code is worse, generally (Eg. python is so bad it's common practice to just use os.path.exists and have a race condition).

This statement borders on the silly side. I way prefer "ugly" code above code that fails. It is not even ugly if you make that few-line helper function "try { return new FileInputStream(f); } catch(Exception x) { return null } method for this exceptional case. Point 3 is valid though - people too lazy todo things proper make lousy code. The point then would be to make the number of cases where they would do that as small as possible.

Finally, code using proper exception handling is smaller and easier to read, and if done properly it is easier to write correct code which provides meaningful (and correct) errors when it fails. It also encapsulates a quite hard subject (error handling) in a generic way.

If you write code doing lots of SQL for instance having every statement result checked manually is horror; you have to write some framework (with it's own conception of handling errors) just for that, and even then you have to check after every statement. Useless code.

Exception handling

Posted Dec 8, 2009 7:02 UTC (Tue) by yvesjmt (subscriber, #38201) [Link]

You are assuming that return values are always simple error codes.

In Go, errors usually carry a descriptive string.

http://golang.org/doc/effective_go.html#errors

Google's new "Go" language

Posted Nov 11, 2009 16:47 UTC (Wed) by nix (subscriber, #2304) [Link]

The problem with exceptions is that they add so many possible arcs to the flow graph that you can no longer hold it in your head properly, and they encourage overlooking of arcs merely because they're related to error-handling (of course without exceptions you have the converse problem, that error-handling arcs overwhelm your program and drown out all the others). I'm not sure we know, even in 2009, how to write C++ programs of any complexity that are exception-safe (although a lot of that comes about thanks to the ability to overload virtually everything, which is also missing from Go). The language's designers are noted minimalists so it's not even slightly surprising to me that they decided that all flow control should be explicit.

In any case, exceptions, like generics, are explicitly called out as an area where they haven't decided whether to add them yet or what their syntax should be. So it's more that they've decided that all flow control should be explicit *for now*.

The variable declaration syntax is *hugely* better than C's. Anyone who prefers C's has been using only C for so long that they've been blinded to what an appalling dog's breakfast its declarations are, with some things going before the variable name, some after, some at the start before *all* variable names, some wrapping around it, some (cv-quals) being allowed to appear more than once in different positions (*sometimes* but not always with different meaning)... I've been using C for twenty years now and I still sometimes misread complex declarations.

This was one area (not quite the only one) where the Pascal lineage had the right idea. There was no equivalent of cdecl(1) for Pascal because nobody would ever need it.

Google's new "Go" language

Posted Nov 11, 2009 16:56 UTC (Wed) by michaeljt (subscriber, #39183) [Link]

As far as I know, one of the main problems of exceptions in C++ is that C++ isn't garbage collected. With garbage collection, a lot of the exception safety bits become automatic, and for the rest (someone kindly tell me what I am overlooking :) ) you put your non-garbage-collected resources in garbage collected classes.

That wasn't meant be read as advocacy either for or against exceptions or garbage collecting of course, just against the one without the other.

Google's new "Go" language

Posted Nov 11, 2009 17:52 UTC (Wed) by nix (subscriber, #2304) [Link]

The biggest problem with exceptions in C++ is that they can come from *everywhere*, e.g. here:

std::cout << "hello world" << foo->bar() << a==b?"yes":"no" << std::endl;

pretty much the only syntactic elements that can't throw an exception are the ?: and the ;, and you have to ensure that you restored the system to a coherent state no matter which of those myriad places threw: such restoration might very well be much more complex than merely deallocating memory. On a quick count there are at least nine possible throwing sites in that one line (with foo->bar() containing three of them).

The second biggest problem with exceptions in C++ is destructors. Garbage collection is not a panacea as it only collects memory, but whatever your destructors do when they clean up the rest, if something they do to clean up throws an exception they'd better catch it and do something appropriate themselves, because if a destructor throws while an exception is being unwound, you get an unceremonious automatic std::terminate() call and a terminated program. (So this will work most of the time and fail when you least want it to.)

Of course, since destructors can't return values (where would they send them?), this means there is *no* way for a destructor to signal a problem cleaning things up.

Google's new "Go" language

Posted Nov 11, 2009 19:11 UTC (Wed) by zorro (subscriber, #45643) [Link]

The C++ philosophy is that if the construction of an object succeeds, then
the destruction of the object can not fail. This makes perfect sense to me.
When you have allocated a piece of memory, there should be no reason why it
cannot be deallocated. When you have opened a file, there should be no reason
why it cannot be closed. When you have acquired a mutex, there should be no
reason why it cannot be released. In other words, there should never be a
problem cleaning things up.

Google's new "Go" language

Posted Nov 11, 2009 20:00 UTC (Wed) by rks (guest, #55908) [Link]

but close(2) does a lot more than just closing a file, it may also report errors for earlier writes. If this happens in a destructor, there is no good way to to handle this: there is no return value, and you cannot throw an exception.

Google's new "Go" language

Posted Nov 11, 2009 21:30 UTC (Wed) by magila (subscriber, #49627) [Link]

Yes, in that case you are forced to make an explicit close() call before the destructor runs. That is the price you pay for inflicting such brain damaged behavior in the name of performance.

Google's new "Go" language

Posted Nov 11, 2009 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]

There are other hacky workarounds: you could remember what went wrong in
some other data structure.

But that doesn't fix the fact that they *are* hacks (and this is really
off-topic as Go has neither destructors nor exceptions nor scope defined
as tightly as C++, so RAII isn't practical either).

Google's new "Go" language

Posted Nov 13, 2009 12:29 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> Go has neither destructors

Go has the defer statement that defers execution of some function until the caller is about to return, http://golang.org/doc/go_spec.html#Defer_statements. They are much more flexible than C++ destructors.

Google's new "Go" language

Posted Nov 13, 2009 19:59 UTC (Fri) by nix (subscriber, #2304) [Link]

Yes indeed, but they're not destructors, so don't have the same problems.
(They're really neat; like a debugger feature usable in real life.)

Google's new "Go" language

Posted Nov 12, 2009 7:13 UTC (Thu) by PO8 (guest, #41661) [Link]

"When you have opened a file, there should be no reason why it cannot be closed."

Safely closed? Really?

Google's new "Go" language

Posted Nov 12, 2009 7:17 UTC (Thu) by PO8 (guest, #41661) [Link]

Oops. Too late.

Note, though, that a file might be unclosable because its underlying removable media has gone temporarily missing since the last write, and filesystem metadata needs to be updated. In this case, it's hard to blame the language, the OS, or anyone else for wanting to raise an exception during the destruction of the fd. It might or might not be nice if all hardware physically locked removable media while it was in use, but obviously this isn't the normal case in 2009.

Google's new "Go" language

Posted Nov 12, 2009 7:46 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

I will play the devil's advocate here, and say that a file can always (except see below...) be safely closed once it has been opened. It is just unwritten data which may not be safe :) But the job of a destructor is not to write unwritten data, it is to close/destroy resources. Where I work, we have a policy for dealing with this sort of thing that an object should also have an "uninit" method if it needs to do more advanced cleanup than simple destruction, which the owner is responsible for calling in time.

And of course, to my mind, failing to write because the user removed a removable medium is not an exceptional case - it is something that should be expected and handled. An exceptional case, in which the file cannot be safely closed, might be that the file's descriptor structures in memory have been corrupted or something on those lines - something that is not expected, and that we can't think of a reasonable way of handling.

Google's new "Go" language

Posted Nov 11, 2009 22:28 UTC (Wed) by rks (guest, #55908) [Link]

Exception safety is not only about resource loss. Broken invariants (e.g. corrupted data structures) are probably worse.

A lot of problems can be avoided if classes implement transactional behaviour. There are also straightforward techniques to provide this from a very small set of functionality that is guaranteed to never throw an exception. If you are interested in details, I recommend the "Exceptional C++"-books by Herb Sutter.

Google's new "Go" language

Posted Nov 11, 2009 19:13 UTC (Wed) by mikov (subscriber, #33179) [Link]

The variable declaration syntax is *hugely* better than C's. Anyone who prefers C's has been using only C for so long that they've been blinded to what an appalling dog's breakfast its declarations are, with some things going before the variable name, some after, some at the start before *all* variable names, some wrapping around it, some (cv-quals) being allowed to appear more than once in different positions (*sometimes* but not always with different meaning)... I've been using C for twenty years now and I still sometimes misread complex declarations.

Pfft. Don't pretend like you don't know why we all love the C declaration syntax. Once you really "get it" (and for that naturally you need to at least have written a C compiler, but who hasn't these days), it makes you feel smart. And more importantly, it is something that those darned kids with their Java and C# will never understand.

Google's new "Go" language

Posted Nov 11, 2009 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]

I'm not sure I like elitist language design, though ;} and it was meant to
be *easy* to read ('make declaration like expressions'), it just didn't
turn out that way.

Google's new "Go" language

Posted Nov 12, 2009 7:25 UTC (Thu) by jhoger (guest, #33302) [Link]

There are no useful system software developer certifications. We have to keep out the interlopers somehow. Having to grok C declarations is not really that high a barrier to entry, and if it keeps anyone out, it's probably just as well.

;-) , well, sorta...

Google's new "Go" language

Posted Nov 11, 2009 19:19 UTC (Wed) by tjc (guest, #137) [Link]

The variable declaration syntax is *hugely* better than C's.

Yes, I really like the left-to-right declaration syntax, especially the postfix pointer declarator. Complex declarations are much easier to read (and write).

My initial impression of Go is one of guarded optimism. I plan to write some programs this coming weekend and see how it is "in real life" (as opposed to whatever it is we call this).

Google's new "Go" language

Posted Nov 12, 2009 7:26 UTC (Thu) by PO8 (guest, #41661) [Link]

Check out Nickle for our compromise type declaration syntax. It is designed to mostly look like C's, but with the "type-to-the-left" style that Java allows in limited ways expanded to be completely general. We think the resulting type language needs no cdecl, yet is reasonably comprehensible to C programmers.

Google's new "Go" language

Posted Nov 12, 2009 11:13 UTC (Thu) by jwakely (subscriber, #60262) [Link]

> I'm not sure we know, even in 2009, how to write C++ programs of
> any complexity that are exception-safe

Speak for yourself.

Google's new "Go" language

Posted Nov 12, 2009 16:35 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, thanks for the detailed comment. :)

If you stick carefully to various rules (no exceptions from overloaded
operators or functors, not even <<, and catch all exceptions that arrive
there) then it might be possible, but that means you possibly have to
throw a bunch of exceptions away or record the fact that they were thrown
in some other error store: and if you're doing *that*, why not record the
problem in an error store to start with rather than throwing the
exceptions in the first place?

(It's true that the last time I paid much attention to this was in about
2003. Maybe there's been a giant leap in understanding of exception-safety
since then.)

Google's new "Go" language

Posted Nov 12, 2009 19:39 UTC (Thu) by rks (guest, #55908) [Link]

Im sorry to say, but what you describe is more like the understanding of exception safety in 1993 than in 2003. See for example this article from 1999: Exception-Safe Class Design, Part 1: Copy Assignment .

Today, I would consider this required knowledge for every serious C++ programmer.

Google's new "Go" language

Posted Nov 12, 2009 22:52 UTC (Thu) by nix (subscriber, #2304) [Link]

I'm not a serious C++ programmer, and I haven't used the language much for
years. However, it was my distinct impression that the article you pointed
at there was invalidated by later publications (mind you, the thing on the
web now probably has had the problems fixed, but way back when I was
paying attention to these things Meyers et al were musing that they looked
insoluble: however, I can't remember what the problems with it were,
anymore...)

Google's new "Go" language

Posted Nov 13, 2009 19:01 UTC (Fri) by rks (guest, #55908) [Link]

The solution described in the article is still considered the correct solution by the C++ community (and Herb Sutter is certainly a leading expert. At the time the article was written he chaired the ISO C++ Standards Comittee.) However, this is getting too far off topic.

Google's new "Go" language

Posted Nov 11, 2009 18:49 UTC (Wed) by wahern (subscriber, #37304) [Link]

At the very least, channels--which Pike has used before in Alef and Limbo--and the segmented stack are really cool.

The segmented stack solves the issue that has plagued threading (both user and kernel scheduled; and in C, Java, et al) and led so many people to use event-oriented callback models (myself included), or to use interruptible scripting languages like Lua.

Go gives you the best of all worlds:

o Simple control flow via threads.

o Scalable. Native thread implementations everywhere incur several hundred kilobytes, minimum, per stack, usually much more. In event-oriented network apps you usually only need a few kilobytes, maximum, for state. Elsewhere you can't really reduce thread stack size to below a 100k+ because you can't control recursion and auto-storage by other libraries. If you get it wrong, your app crashes. Anyhow, why would you want to prevent such usage? Recursion and stack allocation are useful.

o Speed. Compiled to native code.

o Closures + Channels == Coroutines. I haven't looked under the hood, but I bet their user space thread scheduler expects and optimizes this pattern. And I'm not even sure it needs optimization, because it would be natural to just immediately jump stacks to the next thread blocked on the channel.

When you consider all of those things together, Go is exceptionally elegant. What might look clumsy on the surface is extremely well thought out underneath; or rather, the product of instinct and intuition derived from decades of experience. It's not earth-shattering, but the sort of careful, thoughtful, and pervasive use of low-level I/O and control-flow abstractions one would expect from the authors, and what ultimately actually matters to programmers, especially those writing server software.

The syntax might not be agreeable, but it's certainly less of a barrier than, say, Erlang's syntax. I like the terseness. What bothers me most is the use of camel case in Go's library routines; so, so annoying. But that's all beside the point.

Google's new "Go" language

Posted Nov 11, 2009 20:40 UTC (Wed) by sourcejedi (guest, #45153) [Link]

> The segmented stack solves the issue that has plagued threading

People are working on this for C
<http://gcc.gnu.org/wiki/SplitStacks>.

I think the main benefits of language support for concurrency here are that

a) you get lighter syntax which encourages developers to use your light-weight implementation

b) you can reduce unpageable memory by using user threading, _with sane semantics_. I read that Solaris had a hard time getting all the corner-case bugs out of their M:N pthreads library (in particular w.r.t signal handling). They eventually managed it... but then gave it up and changed the default back to 1:1 threading in Solaris 9. See <http://www.kegel.com/c10k.html#1:1>.

I will be very interested to see if split stacks make 1:1 threading competitve with the likes of GCD blocks and Go's "goroutines".

Google's new "Go" language

Posted Nov 11, 2009 21:51 UTC (Wed) by nix (subscriber, #2304) [Link]

Note, by the way, that the person working on this for C (or at least who
wrote that wiki article) is the same person who (co-)implemented the GCC
Go frontend :) looking at the dates I would be unsurprised to learn that
Go was a major reason to start this, although of course it will benefit C
too.

Google's new "Go" language

Posted Nov 14, 2009 18:18 UTC (Sat) by engla (guest, #47454) [Link]

I'm trying to compile Gccgo, and it fails at Error: "-fsplit-stacks" not supported by this compiler configuration. So gccgo certainly uses it, much to my.. "amusement"*

(*) Subtle sarcasm about the joys of compiling gcc.

Google's new "Go" language

Posted Nov 12, 2009 2:44 UTC (Thu) by cmccabe (subscriber, #60281) [Link]

> Native thread implementations everywhere incur several hundred kilobytes,
> minimum, per stack, usually much more.

The in-kernel native thread implementation only takes about 4 kilobytes per thread. It is pthreads that determines your userspace thread stack size.

In the past, Linux didn't really support massive numbers of native threads very well. That has improved over the years with NPTL and better scheduler algorithms. The idea that native threads don't scale is a decade out of date. Nowadays, native threads have a lot of advantages-- they are visible to top, renice, and other UNIX utilities; they can be migrated between CPUs effectively by the kernel; and one thread doing I/O does not block other unrelated threads.

Anyway, I'm sure Go could be adapted to use native threads if someone spent some time on it.

> At the very least, channels--which Pike has used before in Alef and
> Limbo--and the segmented stack are really cool.
>
> The segmented stack solves the issue that has plagued threading (both
> user and kernel scheduled; and in C, Java, et al) and led so many
> people to use event-oriented callback models (myself included), or to
> use interruptible scripting languages like Lua.

The coroutine concept is interesting. Event-driven programming is definitely the way forward for massively multithreaded apps.

Google's new "Go" language

Posted Nov 14, 2009 18:23 UTC (Sat) by engla (guest, #47454) [Link]

Go already uses native threads, and already in an awesome way.

goroutines are "multiplexed" to one or more native threads. Start two goroutines, they will run, share a thread, then one of them locks on I/O. Go's runtime will put the other goroutine on a new thread to let it continue run!

Right now, threads are only used for avoiding blocking I/O in this way by default, however you can tell it to use more threads with GOMAXPROCS=N. Go code compiled with gccgo uses 1 goroutine = 1 pthread at the moment, but this should change.

Google's new "Go" language

Posted Nov 17, 2009 2:23 UTC (Tue) by cmccabe (subscriber, #60281) [Link]

> Start two goroutines, they will run, share a thread, then one of them
> locks on I/O. Go's runtime will put the other goroutine on a new
> thread to let it continue run!

Green threads just seem to reinvent stuff that is better done at the kernel level. For example, recent iterations of the Linux scheduler have tried to penalize threads that do a lot of computation, and push up the priority of threads that do a lot of I/O. This is supposed to make interactive performance feel quicker.

But with green threads, the kernel thread is not the "real" thread-- we will end up de-prioritizing something completely random. Kernel threads become just a set of identical slots for the "real" go threads to be fitted into. So we basically have to outsource all of the scheduler to userspace. Any volunteers for rewriting the scheduler in userspace? Don't forget to keep the two schedulers in sync, and make sure they don't work at cross-purposes...

Of course there's a lot of other complications. gettid() and renice() become virtually useless. strace and top are pretty iffy too. Anyway. You get the picture. Userspace threads just seem icky. Kind of like handling device interrupts in userspace. Sure, you can sort of get it working-- but there has to be a better way.

Anyway. Maybe once I get a chance to try out GOMAXPROCS I'll change my mind. For now, I'm not so sure about this particular feature.

Colin

Google's new "Go" language

Posted Nov 12, 2009 8:12 UTC (Thu) by roc (subscriber, #30627) [Link]

There are JVMs that use split stacks (aka "stacklets").

Google's new "Go" language

Posted Nov 12, 2009 20:26 UTC (Thu) by wahern (subscriber, #37304) [Link]

Interesting. Which ones?

Of course, it's easy to implement split stacks in a VM. What's desirable--and what distinguishes Go--is split stacks at the native machine code level. AFAIK none of the common JVM's do this--they're just layered atop the native ABI--but I don't follow Java very closely.

Google's new "Go" language

Posted Nov 11, 2009 19:06 UTC (Wed) by yodacallmesome (guest, #59853) [Link]

Not only do better languages already exist, but Google is using the name of an already established language.
See http://code.google.com/p/go/issues/detail?id=9

Google's new "Go" language

Posted Nov 11, 2009 19:29 UTC (Wed) by tjc (guest, #137) [Link]

I suppose they could get silly and call it gng (Go's not Go!).

Google's new "Go" language

Posted Nov 11, 2009 21:55 UTC (Wed) by nix (subscriber, #2304) [Link]

My IQ dropped fifty points just reading that page. Ye gods there are some
utter idiots out there.

(Still it's ironic that hackers employed by Google have come up with a
language with a name so difficult to google for!)