Linked by fran on Fri 22nd Jul 2011 21:02 UTC
Google "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."
Order by: Score:
Oracle lawsuit
by fran on Sun 24th Jul 2011 13:16 UTC
fran
Member since:
2010-08-06

I wonder if Go would have been developed if this whole Google-Oracle suit about Java has'nt happened.

Reply Score: 2

RE: Oracle lawsuit
by kragil on Sun 24th Jul 2011 16:12 UTC in reply to "Oracle lawsuit"
kragil Member since:
2006-01-04

? Check your facts. Go is older than the lawsuit.

Reply Score: 2

RE[2]: Oracle lawsuit
by fran on Sun 24th Jul 2011 18:22 UTC in reply to "RE: Oracle lawsuit"
fran Member since:
2010-08-06

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.

Reply Score: 2

RE[3]: Oracle lawsuit
by galvanash on Mon 25th Jul 2011 00:36 UTC in reply to "RE[2]: Oracle lawsuit"
galvanash Member since:
2006-01-25

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.

Reply Score: 2

RE[4]: Oracle lawsuit
by fran on Mon 25th Jul 2011 16:26 UTC in reply to "RE[3]: Oracle lawsuit"
fran Member since:
2010-08-06

Galvanesh ..thanks for explaining this.

Reply Score: 2

RE[4]: Oracle lawsuit
by JonathanBThompson on Tue 26th Jul 2011 00:29 UTC in reply to "RE[3]: Oracle lawsuit"
JonathanBThompson Member since:
2006-05-26

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.

Reply Score: 2

RE[5]: Oracle lawsuit
by galvanash on Tue 26th Jul 2011 01:49 UTC in reply to "RE[4]: Oracle lawsuit"
galvanash Member since:
2006-01-25

C++ and dependency nightmares? Please elaborate on your statement there.


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).

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.


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.

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.


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

Reply Score: 2

RE[6]: Oracle lawsuit
by JonathanBThompson on Wed 27th Jul 2011 02:07 UTC in reply to "RE[5]: Oracle lawsuit"
JonathanBThompson Member since:
2006-05-26

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)

Reply Score: 2

RE[7]: Oracle lawsuit
by galvanash on Wed 27th Jul 2011 03:22 UTC in reply to "RE[6]: Oracle lawsuit"
galvanash Member since:
2006-01-25

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

Reply Score: 2

RE[3]: Oracle lawsuit
by jessta on Mon 25th Jul 2011 02:51 UTC in reply to "RE[2]: Oracle lawsuit"
jessta Member since:
2005-08-17

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

Reply Score: 3

As a programmer...
by JacobMunoz on Mon 25th Jul 2011 03:19 UTC
JacobMunoz
Member since:
2006-03-17

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

Reply Score: 2

RE: As a programmer...
by jessta on Mon 25th Jul 2011 05:29 UTC in reply to "As a programmer..."
jessta Member since:
2005-08-17

the "Defer/Panic/Recover" error handling...it was significantly harder than I expected (mostly because of exception handling)


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.

Reply Score: 2

RE[2]: As a programmer...
by henderson101 on Mon 25th Jul 2011 13:50 UTC in reply to "RE: As a programmer..."
henderson101 Member since:
2006-05-30

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.


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

}




Idiomatic error handling in Go is done using the multiple return statements and checking for returned error values.


Exception handling and Error handling go hand in hand in modern OO languages.

Reply Score: 2

RE[3]: As a programmer...
by jessta on Mon 25th Jul 2011 16:33 UTC in reply to "RE[2]: As a programmer..."
jessta Member since:
2005-08-17


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):


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.


Exception handling and Error handling go hand in hand in modern OO languages.


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.

Reply Score: 2

RE[4]: As a programmer...
by henderson101 on Tue 26th Jul 2011 09:33 UTC in reply to "RE[3]: As a programmer..."
henderson101 Member since:
2006-05-30

"Exception handling and Error handling go hand in hand in modern OO languages.


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.

Reply Score: 2

RE[5]: As a programmer...
by jessta on Tue 26th Jul 2011 09:48 UTC in reply to "RE[4]: As a programmer..."
jessta Member since:
2005-08-17


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.


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.

but in a true OO language the Exception carries a wealth of extra information that the programmer can use to diagnose the error condition.


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.

Reply Score: 2

RE[6]: As a programmer...
by Kalessin on Tue 26th Jul 2011 20:33 UTC in reply to "RE[5]: As a programmer..."
Kalessin Member since:
2007-01-18

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

Reply Score: 1

RE[7]: As a programmer...
by JonathanBThompson on Wed 27th Jul 2011 02:16 UTC in reply to "RE[6]: As a programmer..."
JonathanBThompson Member since:
2006-05-26

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.

Reply Score: 2

Startup time
by Not2Sure on Tue 26th Jul 2011 21:04 UTC
Not2Sure
Member since:
2009-12-07

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?

Reply Score: 1