Why Go feels like a balloon boy

One of my friends like to use the expression “balloon boy” to everything that gets a lot of attention but it turns to be a lot less interesting in the end.

Go is a new language created by Google that recently went open source and generated a lot of buzz in the interpipes.

As someone who have been working as programmer for almost 20 years and worked with almost a dozen languages and, on top of that, have a blog, I think I’m entitled to give my biased opinion about it.

One of the first things that got me off was the video pointing that the language is faster. Or the compiler is. Honestly, pointing that you become more productive because your compiler is fast is utterly wrong. If you’re aiming for a new language and you want people to be productive with it, make it so it’s easier to write code right in the first time. If you need to keep compiling your code over and over again till it does the right thing, you should probably check if there isn’t any impairment in the language itself that prevents right code to be written in the first place.

Which brings us to my second peeve about Go: The syntax, as presented in the tutorial. Syntax, in my opinion, is the biggest feature any programming language have to offer. If the syntax is straightfoward and easy to understand, it makes easier to have multiple developers working on the same code; if the language allows multiple “dialects” (or ways to write the same code), each developer may be inclined to use a different approach to write the code (which basically does the same thing) and you end up with a mess of a code where most developers would feel like rewriting than fixing a bug or adding a feature.

The first thing that caught my eye was the “import” statement that at some point uses a name before it and a block in the second example. Why two different ways (well, three if you count that one is probably optional — in the middle of the statement, nonetheless!) to import other packages with the same command?

Variable declaration also feels weird. “a variable p of type string” is longer to read than “a string p” (comparing var p string := ""; with C way string *p = "";). And that goes on. If you keep reading the statements in their long form (expanding them to natural English), all commands start to feel awkward and adding unnecessary cruft on the code, things that could be easily dismissed and force people to do less typing.

The “object” interface seems derived from JavaScript, which is a bad idea, since JavaScript have absolutely no way to create objects in the proper sense. And, because object attributes and members can be spread around instead of staying grouped together, like in C++ and Python, you can simply add methods out of imports. Ok, it works a bit like duck-taping methods in existing objects, but still can make a mess if you add two objects in one file and people decide to add methods just in the end of the file: You end up with a bunch of methods about different objects all spread your code, when you could “force” them to stay together.

So far, those were my first impressions of the language and, as you can see, it was not a good first impression. Focusing on compile speed instead of code easiness/correctness seems out of place for current IT necessities and the language seems to pick some of the worst aspects of most languages around.

3 thoughts on “Why Go feels like a balloon boy

  1. I’ve only looked superficially at the docs, but here are some quick replies on why my first impression was a good one, unlike yours.

    Calling a language “faster” is pointless — both regarding the runtime speed of the code and compiler speed, as both are implementation details, not really tied to language design (though some package systems may make things easier or harder). Look at the latest results in LuaJIT 2 to see how implementation can affect the perception of a language’s “speed”. Still, compile cycles (for those of us still using compiled languages — and we’re here to stay) do matter. Pascal’s design favors much faster compile cycles than C (remember Turbo’s speed, back in 286’s?) and switching from FreePascal to gcc was indeed a pain in that regard.

    Syntax is important, true, but semantics in the end count the most. Go’s syntax is a lighter version of C. Having used Limbo a little bit, I noticed a number of similarities, and all of those are things I missed in other C-related languages. These are welcome additions.

    Variable declaration in particular is the same as Limbo’s derivation of the Pascal/Modula/Oberon tradition into C-land and having used it, I can say it’s very comfortable. You either use “var” to declare a variable, or use the declare-and-assign operator :=. So in the end you just have to say p := “”; which is shorter and cleaner than C’s char* p = “”; so no worries there.

    I’m pretty sure the interface system does not come from JavaScript, but rather from the Modula module system. There is no object system per se — the point is that they provide abstractions that are more general than objects. I understand their reasoning behind this, but I confess I rather like having dedicated OOP constructs in a language. I’m yet to see if using Go for writing OOP code ends up feeling like OOP-by-hand in C or if the abstractions are good enough.

    Other great features you didn’t mention are the channel system (straight from Limbo), multiple return values and coroutines (looks like they’ve been paying attention to Lua) and cleaner pointer manipulation (much welcome).

    And finally, Go was created not “by Google”, but by Robert Griesemer, Rob Pike and Ken Thompson — yes, the Bell Labs guys.

    In short, Go feels _very much_ like what I would like to see in a programming language, except for the OOP part…

  2. I know that saying “it’s faster” is pointless. Everybody knows. Even the PyPy guys like to joke saying that PyPy is 400x faster than CPython… for very specific tests. Point is, it’s one of the first things they mention in the video and they don’t even go into specifics about how the language itself makes things faster; all they point is the compiler speed and such, which I think it’s even more pointless.

    Related, pointing that you’re more productive because things compile faster is highly irrelevant if you have to compile things a thousand times ’cause the language don’t let you express the requirements properly and you have to keep the cycle of “write, compile, test” about 5 times. If you can write it twice and make it work properly but your compiler takes 15secs more to compile, you still are more productive. That’s why I really don’t think compiler speeds matter at all. If your syntax don’t allow explaining properly what *you want*, then yes, compiler speed is important, but you’re not going for the root of the problem: Your language doesn’t allow the level of “explicity” you need to explain to the computer what you want.

    Agreed on “needs proper OOP, FFS!” point. Thing is, OOP in C is as awkward as they are pointing it in Go. But C never had “hooks” for OOP-like programming while Go have… in a very ugly looking way. Either do it properly or don’t do it at all.

    I didn’t mention the channel system ’cause, honestly, I didn’t read the whole tutorial. As I heard, it resembles the Objective-C message passing method to call functions (and Objective-C predates Limbo by about 10 years) — and, by God, may I be right in what you’re talking about ;)

    Multiple return values is not novelty. Python does that since 1991 (ok, maybe a bit later), although it does that using one of the internal types. Also, Python also supports coroutines but, in all honesty, I don’t see it being much more interesting for (and that’s when you can flame me to hell and back and to hell again) “consumer scale applications.” “yield” does a good job in a coroutine-like manner already.

    Pointers… honestly, they are not cleaner than C. I even though they were more confusing in Go than in C. They may be cleaner than C++, which is a mess with pointers, references, implicity-references and de-referencing. To me, the cleaner implementation EVER of pointers goes to Objective-C. But, again, personal, biased opinion.

    Finally, Ken Thompson currently works for Google since 2000; Rob Pike currently works for Google; Robert Griesemer also works for Google and started the Go language in 2007. So, calling Unix a “Bell Labs product” may very much apply to Go as “Google product.”

  3. Agreed on many points. Some further comments:

    Channels are sort of like “typed inter-thread sockets”. They allow for really clean inter-thread communication code, and also double as synchronization points. It’s a very elegant design; worth a look.

    I can’t explain precisely why, but Python’s “multiple returns using a tuple” never felt too right for me. I recall bumping into some issues because of that, but I can’t remember which.

    And credit where credit’s due: Objective-C’s message and object system is basically Smalltalk’s. :)

    Coroutines are underrated, but they keep showing up hidden under various names (Windows Fibers, etc.) lately. In the end, they can scale way more than threads, but you have to change your way of thinking a little to work with them (personally, I’m still very much thread-minded, but I appreciate the theory behind the whole thing.)

    On pointers: I found them cleaner than C simply because they removed pointer arithmetic. Unless you’re writing a memory manager, doing pointer arithmetics means you’re not using a proper data structure. :)

    On the brand, yeah, it’s a Google product, of course. But that doesn’t matter much for programming languages… it’s not like we care that Python was a “CWI product”, or Pascal was a “ETH product”. I think the people behind it matter more than the company. :)

Comments are closed.