In Part One of this post, we discussed the Great Concurrency Problem and the promise of Go in taking the throne from Java. Today, I show why Go isn’t going to get us there.
Back in the heady days of C++, if you wanted to add concurrency support to your application, you had to work for it. And I don’t mean just find a few calls and shove them into your application. I mean:
- Find a threading library available on your platform (maybe POSIX, maybe something more nightmarish, maybe even a custom thread library that would run you a few hundred bucks per license)
- Locate the obscure documentation on threading APIs
- Figure out how to create a basic thread
- In the process, read the encyclopedia-sized docs about all the real issues you’ll hit when building threads
- Decode the myriad of options available to you to synchronize your threaded application via header files
- Add the library to your makefile
- Code the example and
- Make it all work
Contrast that with Java:
- Create a Runnable interface
- Implement the run() method
- Call new Thread(myRunnable).start();
- Debug the obscure errors you get after about 6 months of production
Whoa. At least with C++, the Threading Shotgun wasn’t loaded, the safety was on and it was hanging on the wall. You had to do the hard work of loading the gun, removing the safety and pulling the trigger. Java took all that away by handing you the loaded shotgun, safety off. That shotgun is the Great Concurrency Problem.
Java’s great contribution and Achilles Heel, in my opinion, was the choice to make threading so darned easy to do, without making developers innately aware of the implications or difficulties of concurrent programming with the shared memory model. C++ made you wade through all the hard shared-memory stuff just to get to threads, so by the time you wrote one, you at least felt smart enough to give it a go. The concurrency models in Java and C# hide all sorts of ugliness under the covers like shared memory models, caching of values, timing issues, and all the other stuff that the hardware must implement to make these concurrent threads do their jobs. But because we don’t understand those potential pitfalls before we write the software, we blithely assume that the language semantics will keep us safe. And that’s where we fall down.
Write a multi-threaded program in any shared-memory concurrent language and you’ll struggle with subtle synchronization issues and non-deterministic behavior. The timing bugs arising from even moderately concurrent applications will frustrate and annoy the most seasoned of developers. I don’t care if it’s in Java or not–the issues are similar.
My specific beef with Java is the ease with which we can create these constructs without understanding the real problems that plague us down the road. Until we have the right tools to produce concurrent applications in which we can reliably debug and understand their behavior, we can’t possibly benefit from the addition of a new language. In other words, if you want to create a Java killer, you’re going to need to make concurrent programming safer and easier to do. A tall order to say the least.
Enter Google’s Go in November, 2009. The number one feature trumpeted by reviewers is the use of goroutines (the message-based concurrency mechanism for Go) and channels to improve concurrent programming. Initial reviews are mixed at best. But I don’t think we’re anywhere close to killing Java off with this new arrival on the scene for a variety of reasons:
- Go decided to use a foreign syntax to C++, C and Java programmers. They borrows forward declarations from BASIC (yep, you heard me right…BASIC), creating declarations that are backwards from what we’ve been using for close to 20 years. Incidentally, syntax similarity was one of the main reasons C++ programmers easily migrated to Java during the Language Rush of 1995, so this is disappointing.
- Performance benchmarks that put it slower than C++ (and therefore, slower than Java today since Java finally caught up to C++ years ago). OK, I’ll grant you that Java wasn’t fast out of the gate, but Java was also interpreted. Go is statically linked, and not dynamically analyzed at runtime, so it’s not likely to get better immediately.
- A partial implementation of Hoare’s CSP model using message-based concurrency. I almost got excited about this once I finally understood that message passing really makes for safer concurrency. But they didn’t get the model quite right. For example, did you know you can take the address of a local variable and pass that via a channel to another goroutine to be modified? Bringing us right back to the same crappy problems we have in Java and C#. Oh yes. Not that you should do that, but even Java was smart enough to drop the address of operator for precisely that reason.
- A few low-level libraries bundled with language, but just barely enough to be functional for real world applications. Completely AWOL: Database and GUI. (translation: “I get to rewrite database access. One. More Time.” Neat.) Did I mention Java had those during it’s 1.0 release?
- Static linking. OK, I admit I’m an object snob and I like a strongly-typed, dynamically-bound language like Java. I like reflection and dynamic class loading and the fact I can pass strings in at runtime, instantiate objects and execute functions in ways the original code didn’t explicitly define (and yes, I’ve done this in enterprise production systems!). Not with Go, instead we’re back to C++ static linking. What you build is what you get. Dynamic class loading was probably one of the most useful aspects of Java that allowed for novel ways of writing applications previously unseen. Thanks for leaving that one out.
- Excepting Exceptions. Go decided to omit exceptions as the error handling mechanism for execution. Instead, you can now use multiple return values from a call. While it’s novel and perhaps useful, it’s probably a non-starter for the Java crowd used to error handling using exceptions.
This feels like some academic research project that will be infinitely pontificated about for years to come, but not a serious language for enterprise development (obligatory XKCD joke). In short, I’m not impressed. And I kind of wanted to be. I mean this is freakin’ Google here. With the horsepower of Robert Griesemer, Rob Pike, Ken Thompson in one building. The #1 search engine in the world. The inventor of Google Wave that created so much buzz, people still don’t have their Wave Invites yet.
Enterprise Languages should be evolutionary steps in a forward direction. But Go doesn’t really get us anywhere new. And it certain isn’t much of a threat to Java. Sorry Google, maybe you need to give it another go?
* Many thanks to my friend Tom Cargill (who you may know from the “Ninety-Nine Rule“) who reviewed early drafts of these 2 posts and corrected my mistaken notions of concurrency, parallelism, Goroutines and Go syntax. He didn’t stop the bad jokes, though. Sorry about that.
18 Replies to “Google’s Go Isn’t Getting Us Anywhere, Part 2”
The link to part one is wrong. The link must point to the slug google-go-not-getting-us-anywhere.
Thanks for letting me know. Fixed now.
I’m sorry, but you got it wrong – Java is not “Strongly-typed”, as you can do things like concatenating a number into a string without converting the number to string first.
And, nope, Java didn’t catch with C++: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=javaxint&lang2=gpp&box=1
I added my source link for speed tests of Java vs. C++. My point about statically linked vs. interpreted still stands. You can improve on the latter at runtime (JIT), but the former is what you get post-linking.
>> Contrast that with Java
Actually the original implementation of Java didn’t get threads right either. You may notice that several methods, like Stop(), are deprecated on the Thread class.
It’s pretty easy to start a thread, but really hard to stop one safely.
More here: http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
All these layers of abstraction (junk) on top of the low-level APIs don’t always help much. Sometimes it’s nice to have a low-level language where you HAVE to understand what’s going on. May Go is not that language, but it sure has some benefits over raw C or C++.
Indeed you are not impressed by Go.
You are afraid.
Go is not intended to replace Java and entreprise software development, it targets C++ and system programming.
So, Google’s new programming language will not get *you* anywhere.
Exactly like C did not get COBOL fans anywhere 😉
>> C++ made you wade through all the hard shared-memory stuff just to get to threads, so by the time you wrote one, you at least felt smart enough to give it a go.
Of course that doesn’t mean you actually _are_.
> I added my source link for speed tests of Java vs. C++
Which raises the question of why you think it’s okay to use the benchmarks game for Go vs C++ but not for Java vs C++ ?
Maurício, the link you put with your comment shows the comparison between C++ and Java -Xint. I’m sorry but do you know what -Xint means? Do you really use -Xint?
You should look at this instead.
@Issac: The source link I gave talks in depth about the methodology and there’s a specific quote in there that I think is important: Anything between 2x-4x different is noise, which I take to mean insignificant because of the tests run. That puts a lot of languages on par with C++, IMO. Heckling over smaller numbers is probably not worth the time. Java is 1.7x slower than C++, but Go is closer to 6x. That’s outside the noise barrier for me. But that aside, I don’t think performance is Go’s biggest problem.
@Laurent: I’m not even sure Go is for C++ folks, either. I’ll cover than in another post. Thanks for pointing it out.
i am totally underwhelmed by go. no generics + no inheritance = no reuse. that is an instant deal-breaker.
i guess if google has some tiny niche figured out for go, ok fine, but i was hoping for a lot more. oh well.
I don’t understand why you are focusing so much on things that a language should make hard. Your primary concern seems to be to help newbies or poor programmers avoid mistakes. That’s not what I want from a programming language.
Do you mean statically typed everywhere you say statically linked?
Nope, I meant statically-linked, which implies the executable cannot dynamically alter its runtime behavior through the addition of updated/changed code. C++ is statically linked, Java is dynamically linked. The JVM will recognize new JARs and load them at runtime without any interruption in the execution of the program.
What I want from a programming language is a set of tools that are powerful enough to express concurrent execution, but come with a strong enough warning and instruction manual so people don’t continue to create horrific, Heisen-bug nightmares. An abstraction that simplifies at the cost of making it easier to do something stupid is not a valuable abstraction at all.
I don’t think having more warnings or instructions would make much of a difference. The information is out there, so anyone who wants to learn about concurrent programming can do that. You cannot prevent incompetent programmers from screwing up without massively slowing down competent programmers. If anything, that is what Java has proven painfully well.
Java has only proven that these simplifying abstractions got us into trouble when they are given without any understanding of the underlying mechanisms. The information is there for Java too, but clearly no one bothers to look it up before creating a Runnable. Only when they hit serious problems do they start asking the hard questions.
And this isn’t limited to incompetent programmers in my experience…the smart ones gloss over this stuff too because it’s easy enough to do so without thinking about it.
I spoke to some Google guys about Go. Apparently it really wasn’t a big deal to anyone inside the company.
That was reassuring.
Comments are closed.