Slashdot Mirror
Google Go Capturing Developer Interest
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?
Whatever happened to the previous language named Go? Did the creator settle with Google, or did Google just ignore him?
It's still surprising to see the Go Programming language on the 4th place when searching for "Go". ./ users know of it.
How could it be so high based on just incoming links alone? It seems rather unpopular, considering how few of us
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.
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 wrote a small utility for detecting duplicate files in Go back when it first came out. I haven't really kept it up to date so I'm not sure if it compiles with the current version.
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?
So, what has Go brought to the table?
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:
In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.
Or I'll use Haskell instead. I love seeing things like orderWords = unwords. sort. words. Yum.
SSC
"C++ is too hard, I'll use java. java is too hard, I'll use C#. C# is too hard, I'll use python. Python is too hard (boner?), I'll use ruby. ruby is too hard, I'll use Go." -- GoFanBoy (formerly RubyFanBoy, formerly PythonFanBoy, formerly ...)
Ruby is considered easier than Python? C# is considered easier than Java?
Oh whatever, this is news.
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.
Quit bitching.
In Capitalist America, bank robs you!
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.
I've run into significantly more portability problems with Java than I ever have with Perl or Python. I've never used Ruby or Tcl, so I can't comment there.
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.
Java was aggressively marketed as a flagship product, and language revisions were rather conservative post-release to create an image of stability. That's why it went so well.
Go is the exact opposite of that.
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.
Quartz Extreme and Core Image. Are there any other real reasons to spend all that money on generic hardware?
I like Go, but it's wrong to call it a systems language. I have no idea why they're marketing it as such. I can't think of a single system (as in, low-level, embedded, or even PC system software) where it would be suitable.
What they should have said is it's a NATIVE compiled language, or maybe just 'static'. There's huge advantages to that, even if it's not suitable for systems programming. Sadly, I think that niche is already pretty much covered by Java and C#.
I hate to sound like a Wikipedia faggot, but citations please?
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 Java, and in the end gives a really unpleasant experience to the users.
It is magic. No, really. Unless you're familiar enough with the Java memory model to know what you're doing, you treat it as magic.
What you don't do if you're not familiar with the model is listen to uninformed rants about how awful GC is and go inventing nonsense like "pools" to reuse objects that actually make the problem worse. Garbage collection of the young generation is nearly free. Anything outside it is not. Tenuring your temporary objects is A Bad Thing.
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 to read, and write.
Nah. It's like Perl; In high demand because nobody knows how to use it. <ducks>
Because most Java programmers suck.
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 to bitmaps for display. The port of the C code I originally had to Java was actually faster long term than the C code. Mind you, its not real heavy lifting and in reality the C code was doing some retarded things parsing the XML (like reseralizing for no good reason between steps) so I know for a fact the C code would be faster than it was, but considering I can process several thousand of svg files in a second on an old P4, it certainly far exceeds my requirements and took me almost no time to write.
Java really isn't bad, Java Apps do generally suck, and you should still be weary of Java apps. Treat them just like a VB app. Its probably a pile of shit, but there are good programmers working with Java that can make really nice, fast, well behaving applications.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.