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?
Until this article, I forgot it was ever announced.
Translation: Someone is drumming up some marketing astroturf for a single-company controlled proprietary language.
Whatever happened to the previous language named Go? Did the creator settle with Google, or did Google just ignore him?
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), I am expecting Go to stay and prosper.
"Hannibal's plans never work right. They just work." Amy/A-Team
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
This summary reads like a bad infomercial. "How likely is it to really take over?" not likely at all, and nobody would ask that question unless they worked for Google Marketing.
Just because I can hook a shark from a boat, I do no offer to wrestle it in the water.
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.
"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 ...)
Do you even lift?
These aren't the 'roids you're looking for.
Why pick Go when there's D which already has a pretty stable platform to develop on?
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.
http://en.wikipedia.org/wiki/Considered_harmful
If Pandora's box is destined to be opened, *I* want to be the one to open it.
30 years ago there were enough programming languages "already". What do you need that can't be handled by COBOL, FORTRAN, Pascal, Ada, ANSI C and assembly language?
"Mr. Burns, your campaign has the momentum of a runaway freight train. What makes you so popular?"
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
And this is most funny because C *does* actually have multi-dimensional arrays (at least statically sized ones).
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.
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'll let you know if/when my program halts...
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?
And this is most funny because C *does* actually have multi-dimensional arrays (at least statically sized ones).
C99 has non-statically-allocated (albeit still non-resizeable) arrays, including multi-dimensional ones.
Go? That's the language that Toyota uses to write their firmware, right?
Read my blog.
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.
What's with the line numbers? I thought we buried those in the same unmarked grave as disco and rotary dial phones.
Those line numbers, they're
Ah ah ah ah stayin' alive stayin' alive
(apologies to the Brothers Gibb)
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. PIL for Python, PDL for Perl, etc. are designed to perform these low-level operations in a way that the high level language can manage cleanly.
You don't need a huge tumor on the side of the language syntax just so that your reference counted, garbage collected, safe accessed arrays are stored without an extra pointer. That would be absurd.