Guest post by “Now everyone can use Google’s Go language on the company’s App Engine cloud platform as the company has announced that the Go runtime, which has been in development since it was announced at Google I/O, is now generally available.”
“Now everyone can use Google’s Go language on the company’s App Engine cloud platform as the company has announced that the Go runtime, which has been in development since it was announced at Google I/O, is now generally available.”
I wonder if Go would have been developed if this whole Google-Oracle suit about Java has’nt happened.
? Check your facts. Go is older than the lawsuit.
Before being snide check your facts.
Work on Go starter Sep 09.
Friction of Google use of Java begun in 2009. (Then Sun owned.)
The lawsuit is the second re-inactment of this feud.
Anyway this is just me speculating if Google’s long standing Java problems led to it’s Go investment, not really a factual pissing contest.
Regardless of the timing, I really don’t think it’s related.
My understanding, from listening to various talks on Go programming, was the developers behind Go wanted some very specific qualities in the language they used internally that were either not available or troublesome to deal with in most other languages:
1. The wanted something simple and fun, from both the standpoint of syntax and feature set. They liked Python, but wanted something akin to compiled Python with a more conventional syntax and static typing.
2. They wanted something that could do most of what C++ could do, without the dependency nightmares and slow compilation speeds.
3. They definitely wanted garbage collection, but they also wanted to allow the developer some control over it. In Java and most other languages the GC has a tendency to become a barrier to optimization efforts. They wanted automatic memory management, but they also wanted to retain programmer control of the granularity of the allocations and still have pointers.
4. They wanted to build concurrency features into the language without resorting directly to hardware threads. I.e. make concurrency simpler.
In my opinion it succeeds at all of these. It is still immature, and I have not myself done any serious development with it, but from toying with it I have to say I like it very much. I do see it as an attempt to replace Java, but more for technical reasons than anything else.
Galvanesh ..thanks for explaining this.
C++ and dependency nightmares? Please elaborate on your statement there.
Where there’s sloppy design, there’s dependency nightmares: where there’s proper design, there is not. This is not specific to C/Objective-C/C++, as all languages that allow forward declarations/references (and languages that don’t are rare) allow for circular dependencies, which is when things balloon out of control and become dependency nightmares.
What do a lot of more recent languages have that C/C++ doesn’t provide built-in? The import statement (or equivalent) where you don’t have to go out of your way to define something to say it has already been included. That’s all. Note, however, you can still ensure things aren’t included more than once in the same compilation unit, with proper usage of the preprocessor.
Go does not use header files at all, and unit/package scope is controlled through simple syntactic rules (anything starting with an upper case letter is externally visible, otherwise it is private).
Hence why Go does not allow forward declarations (I guess it is one of those rare ones you speak of). You define things once and only once – there is never any need (or even support) to do otherwise. Since there is no type hierarchy the need for forward declarations doesn’t exist.
I don’t do much C++ development (I very briefly dabbled in it a few years ago) – my understanding of the nuts and bolts of compilation and dependency resolution are very limited.
I can say though, that in trying to write a reply to you here I did do some reading up on how whole header/preprocessor/etc. combination works in C++. Suffice to say that after reading for about an hour I still don’t understand it. The “rules” in Go can be explained, pretty much in their entirety without omitting anything important, in a single sentence. Quite a contrast to me, just saying…
Thanks for explaining that. However, what Google has done just saves typing, but doesn’t do anything related to preventing a bad structure, except hide it
I can see how they do it (read through all the code on a first pass to find all identifiers) and why they do it (to reduce typing, because anything you possibly do more than once exposes human error into the equation needlessly) but it doesn’t change anything related to dependencies. (shrug)
I would not say they are hiding anything, rather they are making declarations intrinsic – you don’t have to declare separately. The language and compiler are designed in a way that removes the need to.
When you really boil it down… If you don’t need headers to “package” code into organized and useful constructs, the only purpose they serve at that point is a crutch for the compiler.
I might have concentrated on the wrong things in replying to you (I got carried away when you brought up headers and imports and what not).
When the Google developers said dependency hell, I think they might be talking about this type of scenario (as an example):
http://osr600doc.sco.com/en/SDK_c++/_Minimizing_interface_dependenc…
While this problem has a (usually) simple solution as demonstrated, it does represent a completely artificial issue that has nothing to do with the code you are writing or its organization – you are simply required to do things a certain way to make the compiler behave properly.
This kind of issue cannot happen in Go. However, you do lose some of the flexibility you have with headers. Its a trade-off.
Edited 2011-07-27 03:31 UTC
Check your facts.
The Go project released source code in sept 2009. The project itself started in 2007.
http://golang.org/doc/go_faq.html#history
… who has actually used Go – I can safely say it didn’t matter what their problems with Java may have been, Go would have happened regardless of Java. Go is significantly different from Java, the “Defer/Panic/Recover” error handling, “gothreads”.. it is a little odd – and can take some work to port other code to it, but worth looking at for most projects.
I had a fairly simple GTK#mono app I wanted to translate to Go, and it was significantly harder than I expected (mostly because of exception handling) but Go allowed me to efficiently multi-thread my app very easily. Its different and interesting – but be prepared to say goodbye to good ‘ol “Try/Catch”.
I would also say that Go needs better documentation, more like php.net and their contributed code samples.
This was probably your problem. Panic/Recover aren’t used for error handling. They are used for handling exceptional situations that the programmer wasn’t expecting and thus the program can’t handle(usually programmer error). It’s intentionally annoying to use to discourage people over using it.
Idiomatic error handling in Go is done using the multiple return statements and checking for returned error values. There are a few tutorials on the website and the language spec is easy to read. The standard library documentation is pretty good(far better than the vagueness of php’s docs), but some examples might help new devs.
Well, no.. surely the concept is similar as the following (Sorry, OS news seems to flatten the indentation in the preview, so probably the post too):
class X
{
void static Main()
{
X x = new X();
try
{
x.Whatever();
}
finally
{
//clean up or whatever
x.Dispose(); //e.g.
x = null; //…or
}
catch(Exception ex)
{
//silently swallow anything we don’t otherwise handle
}
}
void Whatever()
{
try
{
y();
}
finally
{
//defer
}
catch(MySuperException ex)
{
//recover
}
}
void y()
{
try
{
throw new SomeUnhandledException(“We don’t handle this”);
}
catch(SomeOtherException ex)
{
//recover
}
catch(AnotherKindOfException ex2)
{
//recover
}
}
}
Exception handling and Error handling go hand in hand in modern OO languages.
It’s possible to use panic/recover as a fairly limited traditional exception handling system, but it’s not nice to use and Go programmers won’t expect it. Similarly you can return null to indicate errors in Java but Java programmers won’t expect that either.
They are distinct concepts and Go treats them as such.
By making them distinct you make your error handling easier to reason about and more resilient to changes in other parts of the code base. Even Java’s checked exceptions have a neat trick of hiding the source of an exception from the code that has to handle it.
An exception is still an error that occurred in your code. This can be from a multitude of reasons, but many languages now treat exceptions as first class errors. What you are talking about is the traditional approach to Error handling – I pass in a bunch of params, including a pointer to my expected result, I return an integer (or boolean) that is either “success” or “reason for failure”. Yeah, there’s a place for this concept, but in a true OO language the Exception carries a wealth of extra information that the programmer can use to diagnose the error condition.
Exceptions aren’t recoverable. Your can’t plan for them and handle them. An exception is a bug in your program and it can’t continue until someone fixes the bug. It can restart but that’s not really error handling.
Errors are expected so code can be written to handle them and attempt some kind of recovery. Treating exceptions as errors leads to attempts to recover from unrecoverable situations.
I assume you haven’t actually had a look at how Go does error handling. Functions can return multiple values so it’s idiomatic to return a value and an error value.
The error value can be null or contain a data structure containing information about the cause of the error.
I find that particular distinction interesting since it’s completely backwards from what I’d expect. I would expect errors to be unrecoverable and exceptions to be at least potentially recoverable. For instance, I would expect running out of memory or dereferencing a null pointer to be an error, whereas I would expect trying to read from a closed socket to be an exception.
It’s all a matter of semantics, because it’s ultimately the concepts that matter rather than exactly what you call them. But still, if the official Go terminology has error referring to something recoverable and exception referring to something unrecoverable, it strikes me as being incredibly backwards.
I guess that it just goes to show that you have to make sure that everyone is on the same page terminology-wise before discussing something, or you’re going to have communication problems.
Running out of memory in a system that has more than one process in use is an exception: it’s something you can reasonably expect to happen, due to the nature of the system. So, too, would a closing socket, as stuff happens beyond your control. However, your statement about dereferencing a null pointer? That’s clearly an error, since that is 100% preventable: either you allocate memory/objects/resources and get a pointer to them, or you get a null, and you never try to dereference a pointer that’s not been set to start with: thus, that’s a very definite error.
However, that doesn’t change the fact that in both Java and C# that an exception is thrown by the runtime, which allows it to possibly be recovered from (to some extent) if you attempt to dereference a null pointer/reference. In C/C++, your program will likely be aborted by the OS, unless you’re using some implementation of structured exception handling (Windows has this in something similar to C++ semantics) or appropriate signal handling in Unix/Linux and similar OSes.
Can’t see myself rewriting any of the java GAE apps I have in production, but in theory it could cut down on the chief complaint I have about GAE.. the latency involved in spinning up jvms.
Peers tell me it used to be c++, java, python were the lingua franca of teamwork inside Google. No one ever told you couldn’t do any project in whatever lang you liked but as soon as it was a team project/product development kinda had to go in that direction.
Are there any serious Google projects/products built using Go yet or is still considered too experimental?