Posted
by
ScuttleMonkeyon Monday March 01, 2010 @11:27AM
from the fear-the-behemoth dept.

angry tapir writes with news that Google Go seems to be cutting a wide swath through the programming community in just a short time since its early, experimental release. While Google insists that Go is still a work in progress (like so many of their offerings), many developers are so intrigued by the feature set that they are already implementing many noncritical applications with it. What experiences, good or bad, have you had with Google Go, and how likely is it to really take over?

Google Go is in basically the exact same position Java was. Both are technically OSS, but both are also controlled by a single company. I'm sure this exact same thing happened in Usenet back before Java was popular, and look where it is now.

I read the spec, I noticed that Ken Thompson is one of the designers and this:

This approach makes for clean-looking, semicolon-free code. The one surprise is that it's important to put the opening brace of a construct such as an if statement on the same line as the if; if you don't, there are situations that may not compile or may give the wrong result. The language forces the brace style to some extent.

- if this is not done on purpose, I'll eat my hat (which by coincidence is currently made of some eatable stuff I think).

I know why there is this new language now, forget about everything else, Ken just wanted to make a point of the correct style of opening braces and he came up with a language that does not allow you to do any different!

Ken Thompson also developed Plan 9, and Inferno, and Limbo (what?). Yes, Limbo was a programming language. With concurrency support. While all of these were kinda neat, they never took off.

I looked at Go when it was released, but was underwhelmed. Seemed like another Java wannabe to me. The news article is just plain wrong. How can Go have the same productivity of Python when it is a statically typed language? I mean, try reading some actual Go code, and Python code, and then tell me which one is easier

We always laughed at Java's "portability" as being something that Sun's marketing dept. cooked up.

For a long time, the only supported platforms were Solaris and Windows. Then came Linux support. Some vendors, like IBM and HP, offered support on AIX and HP-UX, but it always trailed the features of the latest releases from Sun. Even Apple didn't have a good implementation of the JVM for Mac OS X for quite some time.

Perl is portable. Python is portable. Tcl is portable. Ruby is portable. Java is not.

I'm currently working with a relatively large Python app that we deploy to servers running Linux, Solaris, and (unfortunately) HP-UX. The same codebase works flawlessly on all of those systems. Oh, and most of the developers develop it on Windows, where it runs fine, too.

At a previous job, we developed a Perl-based web app that ran on our clients' servers. When I left, we supported Linux, FreeBSD, Solaris, Windows, HP-UX, AIX, UnixWare and even IRIX and BSD/OS, all with the same codebase.

One of the portability issues that I've encountered is that in Linux Java will repeat both KeyPressed and KeyReleased events when a key is held down, but on Windows it repeats only the KeyPressed, which makes it very difficult to work out when a key has physically been released on Linux.

Are you really claiming there are no large Python apps? A lot of people in high-performance computing (including myself) are running huge massively-parallel (either MPI or some MPI+threads hybrid model) scientific codes that are largely Python, with some computationally expensive modules written in C or C++.

As someone that works on a non-java cross-platform enterprise product and has experience working with some of the big java ones I'd like to add -

For fsck's sake please stop using java unless you know what you're doing!

I know, the old "C is just faster" meme makes people angry. I'm sure java can be programmed well and made to be fast and efficient. So why is it every java app of any size I encounter is a slow, bloated memory hog?

I know EXACTLY what you're talking about. Until I was forced to write in Java, I felt the EXACT same way.

Then I heard about how much of Google is powered by Java, and then finally I was forced to work with it for my day job.

As someone who prefers C, if you can obtain the performance you want in any higher level language the C/C++, then you can probably do it in Java. I've written an imagine processing library for SVGs that uses Apache Batik to convert my generated SVGs t

We have an internal RoR app that's used by quite a few people at once. We tried using JRuby a few months ago, but it just couldn't handle the load as effectively as Matz's Ruby implementation, which itself isn't all that good. This was on the same Solaris server, so I don't think it was a problem with Java or the server.

From our experience, JRuby is just too damn slow for anything serious. It takes the slow runtime of Ruby, adds in the bloat of J

Oh - I so agree.Java is portable on Windows & Solaris (haven't used Java on Linux, so no idea).Most other OS's you will get 90% of your stuff working. But chasing down theremaining 10% OS specific issues will take 90% of your time.

I run into more portability issues with Python than I ever have with Java, and thats just between Windows and Linux, the same could be said for Ruby. I haven't dug deep enough into perl to say the same for it. I avoid TCL ever since I stopped using eggdrop, vile creature that it is.

I've written a little python, a lot of ruby, and a fair amount of java, it beats both those others for cross platform issues in my experience, and I'm ignoring Ruby on DOS as thats a whole new set of issues and isn't really even a fair comparison since the OS is so far different, I don't think there is a DOS JVM, and I have no idea about python and DOS.

I absolutely HATED Java apps before I was forced to start writing Java code myself. What I learned VERY rapidly is that Java apps suck if you're a shitty programmer. If you don't have any clue how to write code and no clue about the common pitfalls of cross platform dev, it can kill you. 9 times out of 10, its because the programmer did stupid shit that he/she shouldn't have that is clearly OS specific when its a cross platform compatibility issue. Likewise all the slow beasts of Java 'apps' that you come across generally suck because the programmers have no idea what they are doing. Stupid crap like doing string concatenation one character at a time using a string variable rather than class designed for string concatenation and proper allocation for it.

Java isn't the problem. Much like VB, shitty Java programmers are the problem. Java and to a much larger extent, VB draw in people who aren't programmers because of the marketing, and then we see tons of crappy Java apps because the language is in fact, TOO easy to use.

Say what you want about Java in the past, it could be true. Today? Muh, there is very little if any truth in your statements at this point in time.

Many people think that portability means "your code will run on multiple platforms".

With Java, I feel it is more a case of "your code will run on the Java platform".

The distinction is that, in the latter case, a lot of the facilities that have been implemented for existing platforms have to be re-implemented for the new platform. I feel a lot of effort has gone into creating things for Java that already existed outside it.

By contrast, many other programming languages attempt to fit in and play nice with whatever platform they end up being deployed on. Where Java has your programs run inside a virtual machine which is more or less the same across native platforms, other languages have you create programs that are just like the programs your native platform knows how to run. Where Java has people build functionality on the facilities provided by the virtual machine, other languages have you build functionality on the facilities provided by the native platform.

The approaches are different, and lead to a vastly different feel both during application development and when using an application developed using one approach or the other. Both approaches have their pros and cons.

Java's approach has the advantage that, absent deficiencies in the specification and bugs in the implementation, the Java platform is the same everywhere, regardless of native platform. The disadvantage is that you lose access to the native platform's facilities that are not also in the virtual platform. It also means that your software is almost certain to not really fit in with the native platform.

The other approach leaves you with access to the native platform's facilities, which is a double-edged sword. The disadvantage is that many of those will not be available on all platforms, and code that uses them will therefore be non-portable. The advantage is that you can make your software do anything that would normally be expected of an application on the native platform. Software developed using this approach will thus tend to integrate better with the native platform, and feel less foreign to users.

Yeah. And all those are *extremely* slow interpreted scripting languages. While java on the server (its actual main base) is actually half as fast as C. Which is really nice for code that does all the type checking for you and is machine code independent.

The reason that Java WAS not on every platform is... well, have you seen the size of its standard libraries (J2SE, J2EE)?? All those language’s *built-in* languages are a joke to what Java offers out of the box.

Sorry, but for professional big projects, those languages can’t hold a candle to Java. The only one that can do that, might be.NET. But that one’s by definition not portable. (No, the Linux version of it doesn’t count, for it is way outdated.)

Perl and python are quite portable too, though not as portable as Java.

But in practice many nontrivial programs end up with so many dependencies that they aren't that portable anymore.

For example, say you want to write a program to record video from a video camera and audio from a sound device. And you want to cater for the possibility of more than one selectable camera and sound device.

Even if you write it in java, you're going to have to do different things depending on whether it runs on Windows, OSX or Ubuntu.

Why? Little things like figuring out which is the user's default recording device, and using it might be different on different platforms.

Or in theory it's supposed to work, but currently the current Java release for the current OS release is buggy, so the workaround meantime is "...".

If you want a polished end product you have to take care of stuff like that.

Can I get some sense of how you determined that Go was proprietary, then?

I don't think it's reasonable to call any language proprietary whose spec is licensed under CC-A [golang.org] and managed by an open team outside of the company. That's really hard to back up, and I'd need some kind of source for that.

There hasn't been a successful new systems programming language since the introduction of C++ almost thirty years ago. Programming language technology has advanced a great deal since then. A new systems language is a very big deal, and Google is playing very fair and open with it.

Another element that plays a role is Google's "ass-ness". Does anyone think for a second that they didn't bother *Googling* the damn name prior to release? There is and *was* a Wikipedia entry, it'd probably be one of the first results. They simply switched on the "Apple Mode" -- grab the name, and let's see who has the balls to sue.

It's still surprising to see the Go Programming language on the 4th place when searching for "Go".
How could it be so high based on just incoming links alone? It seems rather unpopular, considering how few of us./ users know of it.

Well we could suspect nefarious link ranking by Google, but it's more likely the fact that anything Google does is instantly linked from every news source on the planet, including the big, respected media websites which generate a lot of page rank and don't want to be seen as missing out on the Next Big Thing.

It is an interesting concept for a low-level language and could be pretty important. And since the gccgo compiler has been accepted by the gcc steering committee (link [gnu.org]), I am expecting Go to stay and prosper.

Haskell is lovely because it lets you write extremely elegant and witty code that is also utterly unreadable. It's like it went so far away from Perl that it came back to the same thing from a different direction - the more clever Haskell code has to be extremely carefully deconstructed, operator by operator, to understand what it does, much like you had to do the same with Perl's @#$ magical expletives.

I absolutely love Haskell, and it's type system is second to none, but it's not a productive language for vast majority of typical software written today. You need to look at languages that are specifically designed to tackle the problems (of working in a team, producing readable code, not breaking code with third-party library updates etc) there.

C# was developed as a reaction to Java. They were trying to make a language with Java's features but without its warts. I'm sure it is easier than Java for many things.

Ruby and Python were both developed as reactions to Perl (again: all the features, sans the warts). Python tried to be easy for beginner programmers (and was successful; it's taught in many intro classes). Ruby tried to be easy to experienced programmers. If you're trying to to real OOP, you will find no easier syntax than Ruby's.

Go actually provides a usable, platform independent method of concurrent programming that doesn't involve mucking about with pthreads, or constants like &MMDIPS_MULTICORE_AGG. You just call "go func()" and a new process is spawned.

It's an interesting language. Apart from its lineage, which is interesting and great if you're into Plan 9, it seems to me to be an old-school procedural shot across the bow of the current crop of compiled functional languages (ML, Haskell). It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert, but it's also missing some core functionality. I can live without exceptions but I'm not sure I can live without type genericity in this day and age. And a lot of other programmers have their own little nits with it.

Overall, it seems great. But I seldom need code compiled to the machine, and I'm conversant with and fond of the compiled FP languages so I tend to rely on them for these kinds of utilities. I suspect at Google this will eventually become the de-facto language for implementing protocol buffer servers. If and when that happens, the language will have a guaranteed niche for a long time to come, whether or not it wins over hearts and minds outside the giant.

Could anyone post a list of alternative modern programming languages that equally handles parallelism as well, that are still being actively developed, and their pros and cons compared to Google Go? I'm interested in learning one of these, I just can't find any easy overview anywhere (all mentioned in wikipedia are pretty old so lots must be missing...). Surely Haskell isn't the latest such project, there must be lots of others just around corner?

There's Scala, Erlang, and, as you mentioned, Haskell. All of them have active development, but I am most familiar with Haskell itself. All of them have the advantage that any more established language will have: they will have better or more numerous compilers, libraries, and instructional materials. They all have mindshare that Go does not have. In the case of Haskell, Haskell has a very strong type system and lazy evaluation, in addition to being a mostly pure functional language. Go does not use LE from

Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.

"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.

...

In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.

No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.

M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.

On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:

But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:

What Go has done is standardized this implementation detail into the language specification

The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.

I'll agree with your points, but many vehicles have wheels and motors and there is still a clear preference (or at least avoidance) of certain brands and models. Go brings things together well, and is a 'better' option because it does integrate so much prior art (as you have said) into a great package.

You're making a very old argument. One that was made by C purists when C++ was introduced: that simply adding syntax for something doesn't make your language special. C++ users disagreed and many defected from the C camp. Were they right? Possibly.

Of course, the smalltalk users were also right: these were not new features. C++ was just applying previously developed tools to the C language.

None of that mattered in the long term.

Is Go the new C++? I have no idea, but I don't think you're taking an objective,

Because we've reached the point where programming per se is not the limiting factor in programmer.

Oh, some languages are nicer to program in than others. I'll take Python over Java, for example, if the criterion is just how fun and easy it is to write programs. But I'll often choose Java in many instances because it has libraries and frameworks that make my job easier.

And there's the rub. It's dealing with frameworks and APIs and libraries that kills you. The Java ecosystem is like a huge, booby-trapped

Too bad they added significant whitespace. I'd support a semicolon-less syntax, but not at the cost of significant whitespace.Perhaps an alternate function call syntax or using {}instead of () in expressions would work.

angry tapir writes with news that Google Go seems to be cutting a wide swath through the programming community

He may write that, but that's not what the article says:

While Go is still a work in progress, some developers are so encouraged by its features and design that they have started using it to build noncritical application

What experiences, good or bad, have you had with Google Go, and how likely is it to really take over?

Um, take over what? Is this a serious question? The answer here is "never" -- for the same reason that no single language will ever "take over" the software development landscape. There is no one tool fit for every job.

I was one of those developers chafing at the bid to get my hands on Go. Once I started I never looked backed. I was able to write my own version of HelloWorld in half (that is 1/2) the time it took me to do it in C and it was bug Free with no memory leaks. I think that pretty says it all. If you're looking for a programming language that solves all your coding problems look no further. Now that I have abandoned Java my manually linking programs with xml skills have declined sharply. Similarly after abandoning Lisp my ability to match parenthesis's has almost vanished. No matter, with Go I perceive the universe in my belly button.

Reading the documentation on Go, really makes me wonder why I would want to use this instead of a language such as Java? One of the arguments is that it is 'loosely typed', which IMHO is not necessarily an advantage in large projects, since in a large project I want to be sure that the compiler catches the obvious mistakes, and not wait until runtime. I already used a loosely typed OO language called Smalltalk and if the documentation wasn't good, then you had to work hard to find out what object the method

You can allocate global multi-dim arrays.
But anyways, it's not a big deal. Make a macro or a function to do the address translation for you and then forget about the impl. details. That's what FORTRAN effectively has to do. That's for C, where there should be no performance loss. For less low-level C-derived languages -- well, I guess if you need performance, you wouldn't be using them.

You should not care about the memory layout of your arrays. If you do, you're programming at the wrong level. The whole point of providing array variable types is to hide the implementation details. How the compiler translates array(7,5,2) to a value is strictly an issue for compiler devs.

How long has Fortran had dynamic multidimensional arrays and how are they implemented without some sort of indirection? You can statically allocate multidimensional arrays in C just fine and it doesn't use indirection (I believe). I'm not so sure the pointers actually hurt you that much on performance, anyway. Continuously allocating an n-dimensional array is a pain, though, in C. And I'm facing a head scratcher right now as to why my C code on matrices is underperforming, but theoretically it works pretty

Go looks nice, but it still does not have real multi-dimensional arrays. This is the key issue that keeps me using Fortran.

Because it's spurious optimization.

Modern HLLs (and even most of the languages that live in the spaces between machine language/C and HLLs) spend so much time doing bounds protection, reference counting, garbage collection, constructing, destructing, etc, that if you find yourself in need of the extra cycle indicated by a double-indirect lookup, then you need to use a lower level tool for that code section, not a 2D array. In many languages this is commonly found in image processing and large math libraries