Go Version 1 Released

New submitter smwny writes "Google's system programming language, Go, has just reached the 1.0 milestone. From the announcement: 'Go 1 is the first release of Go that is available in supported binary distributions. They are available for Linux, FreeBSD, Mac OS X and, we are thrilled to announce, Windows. ... Go 1 introduces changes to the language (such as new types for Unicode characters and errors) and the standard library (such as the new time package and renamings in the strconv package). Also, the package hierarchy has been rearranged to group related items together, such as moving the networking facilities, for instance the rpc package, into subdirectories of net. A complete list of changes is documented in the Go 1 release notes. That document is an essential reference for programmers migrating code from earlier versions of Go. ... A similar process of revision and stabilization has been applied to the App Engine libraries, providing a base for developers to build programs for App Engine that will run for years.'"

Comments

Finally

[Ignacio]

Awesome. Only took them about 2000 years or so too.

Go is already being used

[CondeZer0]

The amazing thing is that even before the first stable release is out quite a few organizations are using Go in production to run real systems. Very impressive:

http://go-lang.cat-v.org/organizations-using-go

Re:Go is already being used

[Desler]

Yay! A bunch of no-names (with very few exceptions) are using it! Great success!

Re:Go is already being used

[Anonymous Coward]

Yeah, very impressive. Only one name in there barely worth mentioning.

Re:Go is already being used

[Anonymous Coward]

no-names for you, in fact im surprised that the Cablenet organization listed is in fact my ISP!

Re:Go is already being used

[vAltyR]

Don't forget vitess, which is a Google project aimed at making MySQL databases scale better, and is used in YouTube. The Thanksgiving Google Doodle was also written in Go, and developed in 24 hours. Google does eat their own dogfood.

Re:Go is already being used

[Anonymous Coward]

There's some impressive companies on that list, you just haven't heard of them. I'm guessing that the one name worth mentioning to you is Canonical since you've likely heard of Ubuntu. But Atlassian is a name that should be familiar to most developers whether you've worked with Jira/Confluence or not. And Heroku is a well-known name in the cloud space. ngmoco is also quite big in the mobile space, they're just almost entirely invisible to end users. I don't doubt that there's at least one other one on that list that's beyond my knowledge.

The bigger critique of pages like that is that you end up listing really impressive companies that have chosen to use a technology for some side project that they're not really relying on.

Re:Go is already being used

[Anonymous Coward]

Is vitess webscale?

Re:Go is already being used

[Eraesr]

What a nonsense statement. The systems that run on Go are equally important to these companies as Google's server farms are important to Google. Just because they aren't multinational super corporations doesn't mean it's not a risk for them to use a relatively unproven development platform.

Added value of Go?

[billcarson]

Can someone explain to me what Go's aim is, and why exactly it requires a new programming language? Is it meant a replacement for Java/C++/Python, or does it cater a new branch of programming?

Re:Added value of Go?

[cgt]

It is supposed to be a systems language like C, but better. It's sort of like Pythonic C (very expressive, but still C like).

Re:Added value of Go?

[Quirkz]

In addition, if I'm a hobbyist programmer who's gotten by on PHP and some JavaScript for web stuff over the last decade and a half, and I'm thinking about picking up something new, should I consider Go or stick with one of the older standards?

Re:Added value of Go?

[larry bagina]

It's a replacement/evolution for/of Limbo.

Re:Added value of Go?

[Urban Garlic]

Maybe I'm too old-school, but when I think "systems language", I think about something that would be good for embedded devices or kernel device drivers, stuff that's pretty close to the metal. I wouldn't use Go for that, garbage-collection and concurrency mean there's heap traffic and IPC signaling under the hood that I probably want to control.

I agree with the "C but better" characterization, but the ways in which it's better disqualify it from being a good systems tool, I think.

Re:Added value of Go?

[PCM2]

Maybe I'm too old-school, but when I think "systems language", I think about something that would be good for embedded devices or kernel device drivers, stuff that's pretty close to the metal. I wouldn't use Go for that, garbage-collection and concurrency mean there's heap traffic and IPC signaling under the hood that I probably want to control.

Java is used in a lot of embedded systems, and it has garbage collection and concurrency.

Unlike Java, though, Go compiles to native binaries, rather than running on a VM (though maybe the real difference is debatable with modern JITs).

Re:Added value of Go?

[aardvarkjoe]

I spent a little time playing around with it a few months ago. It had its good points and bad points -- enough of the latter that I didn't pursue it any further.

The syntax is obviously C-inspired, but with some changes, many of which seemed like experimentation -- doing something different just because it's different. Although I don't object to the philosophy, I'd like to see how those changes work out before investing a lot of time into them. In particular, the declaration syntax feels very strange to people who are used to C-style languages. There are also some contortions due to their desire to remove statement-ending semicolons; I wasn't convinced that the savings of not typing ';' was worth the cost.

You get a systems-level language that includes complex data structures, garbage collection, and various other nice features. The standard libraries are useful and fairly comprehensive, although I found several times that documentation, even for built-in libraries, is frequently outdated, insufficient, or nonexistent.

Re:Added value of Go?

[Anonymous Coward]

I would stay away from Go and pick up Python. It has lots of good libraries and frameworks. Its used in some games and lots of open source projects as their scripting language. Python is a very expressive and general purpose language. It does not appear to be going away within the next decade and in fact I expect Python to become much more prevelent once PyPy becomes more robust. Added to all that, extending Python with commonly available libraries is not a difficult task and there are numerous approaches (each with varying pros and cons) for doing so.

Re:Added value of Go?

[Raenex]

http://golang.org/doc/go_faq.html

What is the purpose of the project?

No major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously. There are several trends:

• Computers are enormously quicker but software development is not faster.
• Dependency management is a big part of software development today but the “header files” of languages in the C tradition are antithetical to clean dependency analysis—and fast compilation.
• There is a growing rebellion against cumbersome type systems like those of Java and C++, pushing people towards dynamically typed languages such as Python and JavaScript.
• Some fundamental concepts such as garbage collection and parallel computation are not well supported by popular systems languages.
• The emergence of multicore computers has generated worry and confusion.

We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation. Regarding the points above:

• It is possible to compile a large Go program in a few seconds on a single computer.
• Go provides a model for software construction that makes dependency analysis easy and avoids much of the overhead of C-style include files and libraries.
• Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.
• Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.
• By its design, Go proposes an approach for the construction of system software on multicore machines.

Re:Added value of Go?

[Anonymous Coward]

I work with multi-function printers that use Java for their embedded software, and BY CHRIST can you tell when it comes time to boot the fucking horrible things.

I don't know whether Java is poorly suited to embedded environments, or just that there's a particularly poor implementation being used, but it's universally poor on devices from several different manufacturers.

Re:Added value of Go?

[Tumbleweed]

Go isn't intended to replace web scripting languages. Dart is their language intended to replace JavaScript, and it's going to go exactly nowhere.

I'd suggest Python to replace PHP, and jQuery to abstract away the bulk of the pain of multi-browser JavaScript.

But it depends on if you're talking continuing to do web stuff, or if you want to do something else.

Re:Added value of Go?

[Tumbleweed]

Yeah, I'm waiting for PyPy to be Python 3 compatible, then jumping head-first into it and not looking back.

Re:Added value of Go?

[Quirkz]

A little bit of both, probably. I'm definitely curious about at least trying some non-web stuff, in addition to likely continuing to do web-based work as well. My last project was a web-based game and I haven't quite figured out what the next project is going to be.

Sounds like Python is appropriate for almost all situations, though, so maybe that's a good direction to pick.

Re:Added value of Go?

[Tumbleweed]

Yeah, Python can definitely be used for non-web stuff. I just saw a video about a guy who used Python to interface with openCV (computer vision) to make a squirrel-shooting watergun. He used Python and openCV to take images from a webcam, and allow it to know the difference between squirrels and birds, and only shoot the squirrels away from the bird feeder. Pretty fun stuff.

Re:Added value of Go?

[Anonymous Coward]

jQuery isn't that good.

Re:Added value of Go?

[Anonymous Coward]

See, I thought that was the goal as well, but when you actually look at it, Go is pretty awkward as a systems language. Garbage collection, IPC mechanism as part of the language, a complex runtime requirement and no pointer arithmetic.

From what I can see from the one and only Go operating system I can find, most of the code ends up being C and asm that implements either the Go runtime, or the bits that Go can't do itself or are too awkward to do in Go (MMIO for example, although it may be possible to do that with Slices?)

Re:Added value of Go?

[GWBasic]

I get the impression that go is suited to high-performance network software where C would be too low-level. The memory isolation model minimizes the overhead of garbage collection, because it can be optimized to not "stop the world."

Re:Added value of Go?

[GreatBunzinni]

It is supposed to be a systems language like C, but better.

IMHO, if it isn't standardized, opened up and backed up by an international standard then it will never be better than C. For all problems that may or may not affect C and for all problems involved in the development and update of a standard for each version of the C programming language, these multiple versions of the C programming language are effectively set in stone. This means that the language is future-proof, as multiple implementations may be developed and, by targetting the standard, they can interoperate without any major consequence.

If Go isn't standardized and if Google intends to control the language then it would be a terrible decision to adopt Go instead of a time-tested, well established tool which is future-proof and resistent to bit-rot. We all have Oracle and Java as a good warning.

Re:Added value of Go?

[Spykk]

I tried grabbing go and compiled a hello world to compare it to C:

[talisman@talisman-pc:~/tmp]$ uname -a
Linux talisman-pc 3.2.13-1-ARCH #1 SMP PREEMPT Sat Mar 24 09:10:39 CET 2012 x86_64 AMD Athlon(tm) II X4 640 Processor AuthenticAMD GNU/Linux
[talisman@talisman-pc:~/tmp]$ cat test.go
package main

import "fmt"

func main() {
fmt.Println("Hello, world")
}
[talisman@talisman-pc:~/tmp]$ time go build test.go

real 0m2.215s
user 0m2.547s
sys 0m0.210s
[talisman@talisman-pc:~/tmp]$ ls -lh test
-rwxr-xr-x 1 talisman talisman 1.3M Mar 28 15:43 test
[talisman@talisman-pc:~/tmp]$ time ./test
Hello, world

real 0m0.003s
user 0m0.000s
sys 0m0.000s
[talisman@talisman-pc:~/tmp]$ cat test.c
#include <stdio.h>

int main(int argc, char **argv) {
printf("Hello, World!");
return 0;
}
[talisman@talisman-pc:~/tmp]$ time gcc test.c

real 0m0.047s
user 0m0.027s
sys 0m0.013s
[talisman@talisman-pc:~/tmp]$ ls -lh a.out
-rwxr-xr-x 1 talisman talisman 6.6K Mar 28 15:45 a.out
[talisman@talisman-pc:~/tmp]$ time ./a.out
Hello, World!
real 0m0.001s
user 0m0.000s
sys 0m0.000s
[talisman@talisman-pc:~/tmp]$

This is obviously not a very scientific comparison, but the takeaways are that the go executable was 1.3M compared to the C executables 6.6K and the go compile took over 2 seconds whereas the C compile took less than 0.05 seconds.

Re:Added value of Go?

[Greyfox]

You can come up one level from that and still be doing systems programming types of stuff. I tend to think of things like process control (fork, exec, waitpid, etc,) and IPC (semaphores, pipes, shared memory, network sockets.) Stuff like writing shells and servers, that not everyone got into. The old IRC, FTP, telnet, DNS and mail servers I'd consider examples of system programming. Also your shell, and maybe the editor (Maybe vi, maybe not ed...) Some of that stuff can be done equally as well in Java, though I'm pretty sure I wouldn't want to write a shell using Java.

I'm not sure Go would be any better in these areas. I did the language-of-the-week club thing with Java, Perl, Python and Ruby and have always come back to C or C++. I'm really not inclined to look at another entry in the club unless it's offering something really compelling. If Google tells Oracle to take a hike and re-implements Android in Go, maybe then I'd take a look. Otherwise, I'm not really in any hurry to delve deeper into the language.

Re:Added value of Go?

[tixxit]

http://golang.org/doc/go_faq.html#Why_is_my_trivial_program_such_a_large_binary

Re:Added value of Go?

[shutdown -p now]

I don't know whether Java is poorly suited to embedded environments

It is. I mean, it's a language that doesn't have stack-allocated user-defined types or arrays or primitive types - how's that for embedded?

The fact that not only was it pushed for that role, but enough people actually bought into it, tells you all you need to know about the average IQ of homo sapiens.

Re:Added value of Go?

[serviscope_minor]

Go may be a fine language. I'm not sure, I've not really looked at, but it does have some neat things in it. However, that does dound a little fuddy to me.

Computers are enormously quicker but software development is not faster.

I program mostly in C++. In the last 10 years, even ignoring C++11, the C++ landscape has changed enormously, with compliant compilers and advanced libraries. C++ today is nothing like C++ in 2002 and even the same language has turned into a much more effective platform.

There is a growing rebellion against cumbersome type systems like those of Java and C++, pushing people towards dynamically typed languages such as Python and JavaScript.

There was a growing rebellion. Maybe I'm misjudging the general feel, but there seems to have been a bit of a backlash, especially as programmable typesystems have become more mainstream, people have found them to be an exceptionally powerful mechanism for catching bugs before they happen and for expressivity. 5 years ago I would have agreed with that statement (though I personally have always preferred static typing). These days, not so much.

Some fundamental concepts such as garbage collection and parallel computation are not well supported by popular systems languages.

Some popular languages don't generate garbage in the first place (and can automatically clean up any resources). It's obvious they're taking a dig at C++ there. As for parallelism, there are several (nonstandard) mechanisms in which C++ supports threads, depending on the tasks at hand. Some of them (such as OpenMP) are quite task specific, but within the domain are easier to use than just about any other threading system I've ever seen.

The emergence of multicore computers has generated worry and confusion.

That's really not in favour of Go or anything else.

Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.

That doesn't sound like an advantage. If types are related, it's kind of handy to be able to specify relations. That poor programmers have abused massive type heirachies in other languages doesn't make them inherently a bad idea. Bad programmers will find a way to abuse any language feature.

Re:Added value of Go?

[grub]

I wish I mad mod points for you :(

Re:Added value of Go?

[grub]

s/mad/had/g

Re:Added value of Go?

[vAltyR]

The syntax is obviously C-inspired, but with some changes, many of which seemed like experimentation -- doing something different just because it's different. Although I don't object to the philosophy, I'd like to see how those changes work out before investing a lot of time into them. In particular, the declaration syntax feels very strange to people who are used to C-style languages.

Perhaps this section of the FAQ might be useful in explaining some of those changes. Another page explaining the declaration syntax in particular can be found here.

Re:Added value of Go?

[JanneM]

We use Python quite a lot in my field of work (computational neuroscience). The main tool I sue right now is slowly, gingerly, gradually removing support for Python 2.4 over the nex year or so, and will require 2.5 or later from then on. Python 3 is not anywhere on the horizon and won't be for a long time.

I don't expect to even take a serious look at Python 3 before the end of this decade.

Re:Added value of Go?

[Anonymous Coward]

Most of the projects I've used Python for had absolutely nothing to do with web development. I've used it for various networking services, including a real time audio proxy and even network audio simulation in which it was used to simulate lossy networks. Python is an excellent general purpose programming language and contrary to most of those who speak out against python, its generally "fast enough", rather than slow. And if you really do hit something whereby python is too slow, chances are you can easily optimize that away, use one of many python to native code techniques, use native c/c++, or use a third party library. All in all, its exceptionally rare to actually find a problem domain where python really is too slow. After all, python is commonly used in scientific computing, which is almost purely CPU bound.

Definately go the Python route.

Re:Added value of Go?

[Lemming Mark]

Embedded has become a rather broad space these days as the range of computing hardware that's built into other devices gets more powerful at the high end.

Like the GP I think I'd usually prefer to think of a "systems language" as something that's suitable for kernel programming and for the low cost / simple CPU end of embedded work, where things can still be very highly resource constrained. But I can see why they're calling Go one, since I'd also expect a "systems language" to be suitable for writing OS utilities, servers, databases, etc - which Go probably is indeed suited to.

I do still hope we'll one day see a favoured C replacement emerge - one that has similar characteristics and abilities but which is nicer to code in. Not that C is bad at what it does - for the sorts of tasks it's good at it's still really quite good...

Re:Added value of Go?

[aardvarkjoe]

Perhaps this section of the FAQ might be useful in explaining some of those changes. Another page explaining the declaration syntax in particular can be found here.

I did read both of those pages while looking at Go. Their rationale for the declaration syntax was mostly that C-style declarations can get confusing when complex function pointers are involved. That's true, but from their examples it's obvious that compound declarations involving function pointers is confusing in Go as well -- if there's an advantage in readability for Go declarations, it's a small one, and I don't believe that it is enough to justify going against existing expectations.

They also neglected to mention that the readability problem that they mention can be sidestepped in C by using typedefs.

It's not that I think that C-style declarations are inherently better than Go-style. I just don't see that there's a big enough problem that "solving" it is worthwhile. I would be a lot more interested in Go if they had kept the C syntax intact, so that I could have spent my time learning and using the interesting language features.

Re:Added value of Go?

[Anonymous Coward]

It is supposed to be a systems language like C, but better.

IMHO, if it isn't standardized, opened up and backed up by an international standard then it will never be better than C. For all problems that may or may not affect C and for all problems involved in the development and update of a standard for each version of the C programming language, these multiple versions of the C programming language are effectively set in stone. This means that the language is future-proof, as multiple implementations may be developed and, by targetting the standard, they can interoperate without any major consequence.

If Go isn't standardized and if Google intends to control the language then it would be a terrible decision to adopt Go instead of a time-tested, well established tool which is future-proof and resistent to bit-rot. We all have Oracle and Java as a good warning.

It is open sourced. Standardization will come I am sure.

Re:Added value of Go?

[vAltyR]

I suppose I can respect that you don't think it's a problem worth solving. But I think that if you're going through all the trouble of designing a new language, you might as well fix as many problems as you can, no matter how small. Certainly compound declarations with function pointers are complex, but I think the ability to read the declaration from left to right is a major improvement over the Clockwise-Spiral Rule of C.

Re:Added value of Go?

[Anonymous Coward]

blah blah blah

So this is why we are blessed with so many different C implementations that interoperate with each other... like GCC and MSVC and... ?

Re:Added value of Go?

[aardvarkjoe]

But I think that if you're going through all the trouble of designing a new language, you might as well fix as many problems as you can, no matter how small. Certainly compound declarations with function pointers are complex, but I think the ability to read the declaration from left to right is a major improvement over the Clockwise-Spiral Rule [c-faq.com] of C.

Don't forget - for me, it's not an improvement. After all, I already know how to read C-style declarations. Also, keep in mind that declarations of the sort that they are using for examples are exceedingly rare -- I can't ever remember wanting to declare a function that takes a function pointer as a parameter and also returns a function pointer. I'm sure that it comes up occasionally, but considering that I write C professionally and have never seen it, it's not the kind of thing that seems worth building the language syntax around.

In any case, though, the syntax weirdness is just an annoyance. If I had a strong reason to learn it, I could get past it soon enough, and I'm sure most other programmers are the same. Maybe when the tools, libraries, and documentation are more complete I'll take another look at it.

Re:Added value of Go?

[DerPflanz]

So, basically, Go doesn't compile to native code, it just wraps the runtime engine (VM?) with it ....

Re:Added value of Go?

[Anonymous Coward]

You should not use gcc in your comparison but automake/make and/or friends. Because 'go build' is not invoking the compiler, but the full blown Go's build system, checking dependencies of all imported packages recursively and possibly recompiling and reinstalling any outdated ones.

The fair variant goes like this:

$ cat tmp.go
package main

import "fmt"

func main() {
        fmt.Println("Hello, world")
}
$ time go tool 6g tmp.go && go tool 6l tmp.6

real 0m0.034s
user 0m0.020s
sys 0m0.010s
$ time ./6.out
Hello, world

real 0m0.006s
user 0m0.000s
sys 0m0.010s
$

Re:Added value of Go?

[Daniel Phillips]

No. It statically links all the IO libraries. Which seem pretty bloaty but it's a bloaty world isn't it. Not the bloatiest pig on the farm though.

Re:Added value of Go?

[Daniel Phillips]

I have a generally better feeling about this project than I ever did about Java or C#. It seems like the prevailing sentiment is common sense. But mind you, maybe that is becuase I have not yet tried it. But I will fix that now.

Re:Added value of Go?

[Daniel Phillips]

OK, I checked out the merurial repo (good taste!), built it and ran hello.go. Just one thing: the syntax "go run hello.go" is stupid, it should be "go hello.go" and --options for anything else you want to do.

Re:Added value of Go?

[Anonymous Coward]

Also, with gccgo you can do dynamic linking I think.

Re:Added value of Go?

[Anonymous Coward]

Well that's a deal breaker right there.

Re:Added value of Go?

[Raenex]

In the last 10 years, even ignoring C++11, the C++ landscape has changed enormously, with compliant compilers and advanced libraries.

It's still stuck with the crappy #include mechanism instead of proper modules, along with slow compile times, plus the many traps and pitfalls that come with the language. C++ as a language is fearsomely complex.

programmable typesystems have become more mainstream

Really? Do you have real-world examples to cite? I also don't think the backlash against static type systems has disappeared. It's a constant source of contention.

Some popular languages don't generate garbage in the first place (and can automatically clean up any resources). It's obvious they're taking a dig at C++ there.

RAII comes at a cost (the programmer has to carefully implement it) and places limits on the structure of your program (such as avoiding cyclic data structures).

As for parallelism, there are several (nonstandard) mechanisms in which C++ supports threads, depending on the tasks at hand. Some of them (such as OpenMP) are quite task specific, but within the domain are easier to use than just about any other threading system I've ever seen.

There's something to be said for an easy to use, built-in model with language support.

That poor programmers have abused massive type heirachies in other languages doesn't make them inherently a bad idea. Bad programmers will find a way to abuse any language feature.

Blaming the programmers for clunky type systems is misguided. I like static types myself, but you often end up fighting the system because real world programming doesn't compose neatly into a hierarchy of types.

Re:Added value of Go?

[Anonymous Coward]

Wait until you run

go go power_ranger

or, to ignore all errors:

go johnny go go go.

Re:Added value of Go?

[PCM2]

Yeah, I think their definition of a "systems language" is broader than that. Maybe on Plan 9/Inferno, the predecessors of Go qualified as systems languages, because the OS provided a lot of the infrastructure for what they did. On other operating systems, the language itself has to provide that same infrastructure (e.g. garbage collection), so to call Go a strict systems language is a little specious.

Re:Added value of Go?

[Anonymous Coward]

Go is not intended to be a scripting language. Go programs that are to be executed repeatedly should be compiled, so a major part of the "go" tool commands are related to compilation. (The other major part is source code management, which is also very important and nicely integrated in Go.) Thus "run" is neither default nor a particularly promoted command within the "go" tool.

Actually the typical use case for "go run" might be just what you did: Hello World programs, and perhaps occasionally written some short programs for one-off execution.

Re:Added value of Go?

[Anonymous Coward]

It works well enough for a lot of tasks and the security model is why the Ricoh photocopier at work can run half a dozen apps from as many vendors without interfering with the core functionality.

Wake me

[buchner.johannes]

Wake me when it has supports seemless integration into Python like Fortran and C (with ctypes) -- then I might consider it for coding CPU-intense stuff. It's supposed to be as fast as C with better syntax, isn't that the point?

Re:Wake me

[Cenuij]

What's the point in that? Go is very expressive. Just write in Go instead of Python.

Re:Wake me

[buchner.johannes]

What's the point in that? Go is very expressive. Just write in Go instead of Python.

Yes, because all libraries in the world are already written in Go and everything is better in Go than in any other language in the world. You must only work on trivial problems if you don't need other packages / shoulders of giants.

Re:Wake me

[Desler]

Because not everybody wants to rewrite all existing libraries into Go to use them?

Re:Wake me

[Cenuij]

And what you consider non trivial must be very different from the rest of the world if all you ever do is reach for python.

Re:Wake me

[Cenuij]

So write in Go and import the C libs.

Re:Wake me

[thetoadwarrior]

Bad programmers need to rely on someone else to do their job for them

Re:Wake me

[Ibiwan]

So do good ones.

Re:Wake me

[amck]

The GP referred to Fortran and C as well as python.

Increasingly we're seeing lots of legacy code (C / C++ / Fortran) wrapped in Python. People using Python for simplicity and expressiveness, dropping to C , etc. for the heavy lifting. This is especially true in the sciences (in HPC, for example).

Trying to avoid the language flamewar, there are distinct advantages in a small number of interoperable languages like this.
If I'm to try a new language, I want to avoid having to rewrite the world in it. I might convince my colleagues to use my code if they can interop. from the language they are already using, like C/C++ or Python.

Re:Wake me

[Anonymous Coward]

Then port them. Or request that the creator of said library port them.
Or write a Python interpreter. (or find someone to do it, make it like a challenge)

I'd still rather learn a new language.
Over-dependence on black-box library-ism is bad coding practice.
You should know how a library at least functions if you are going to use it.

Re:Wake me

[ioshhdflwuegfh]

[...]

Increasingly we're seeing lots of legacy code (C / C++ / Fortran) wrapped in Python.

That does not make sense, you are just confused.

People using Python for simplicity and expressiveness, dropping to C , etc. for the heavy lifting.

You mean they use Python to express themselves and C and FORTRAN to program?

This is especially true in the sciences (in HPC, for example).

You do know what HPC mean, right?

Trying to avoid the language flamewar,

Indeed, indeed.

Re:Wake me

[Anonymous Coward]

The problem with Go is that they spent too much time developing a standard library and not enough time making integration with C dead-simple and easy. If they'd nailed just that one feature, it would have become useful very early on because developers could have delegated to the metric crapload of C libraries that are freely available.

Instead, they spent all their time re-inventing everything that already existed in C in their own language. Now, years later, the standard library is still minuscule in comparison with what's available in C and their language still doesn't integrate well with C. Sad...I actually like some of their syntax and it's much more pleasant to deal with than C.

Re:Wake me

[Anonymous Coward]

[...]

Increasingly we're seeing lots of legacy code (C / C++ / Fortran) wrapped in Python.

That does not make sense, you are just confused.

OP is correct and it seems YOU are confused. A huge portion of the python libraries are just wrappers for fortran/c/c++ libraries. Pretty much every useful Fortran/C/C++ library out there has a python wrapper! For those that don't, tools like swig and cython make it trivial. I can usually wrap a fairly complex library in less than an hour.

People using Python for simplicity and expressiveness, dropping to C , etc. for the heavy lifting.

You mean they use Python to express themselves and C and FORTRAN to program?

Again, you are an idiot, and the OP is correct. You write all of the tedious bullshit in python. This takes a small fraction of the code/time that it would take to implement in C. You then identify the areas that need speed and either develop a C library, or just use some of the nice feature in cython. The end product is an application that took WAY LESS TIME to develop, and runs at practically the same speed.

This is especially true in the sciences (in HPC, for example).

You do know what HPC mean, right?

I DO! Part of my work is in HPC. Python is easily the fastest growing language in the field. Again, users can take decades of C and Fortran legacy code and effortlessly upgrade to the ease-of-use/rapid development of python without really sacrificing any performance. Furthermore libraries like numpy, scipy, matplotlib, guiqwt, pyfftw, pycuda, mpi4py etc. etc. make developing new HPC applications easy.

Re:Wake me

[ioshhdflwuegfh]

[...]

Increasingly we're seeing lots of legacy code (C / C++ / Fortran) wrapped in Python.

That does not make sense, you are just confused.

OP is correct and it seems YOU are confused. A huge portion of the python libraries are just wrappers for fortran/c/c++ libraries. Pretty much every useful Fortran/C/C++ library out there has a python wrapper! For those that don't, tools like swig and cython make it trivial. I can usually wrap a fairly complex library in less than an hour.

People using Python for simplicity and expressiveness, dropping to C , etc. for the heavy lifting.

You mean they use Python to express themselves and C and FORTRAN to program?

Again, you are an idiot, and the OP is correct. You write all of the tedious bullshit in python. This takes a small fraction of the code/time that it would take to implement in C. You then identify the areas that need speed and either develop a C library, or just use some of the nice feature in cython. The end product is an application that took WAY LESS TIME to develop, and runs at practically the same speed.

This is especially true in the sciences (in HPC, for example).

You do know what HPC mean, right?

I DO! Part of my work is in HPC. Python is easily the fastest growing language in the field. Again, users can take decades of C and Fortran legacy code and effortlessly upgrade to the ease-of-use/rapid development of python without really sacrificing any performance. Furthermore libraries like numpy, scipy, matplotlib, guiqwt, pyfftw, pycuda, mpi4py etc. etc. make developing new HPC applications easy.

[emphasis in bold added]

Dear Anonymous Coward,

I'm glad to hear that Python lets you express yourself so eloquently!

Wish you a many successful HPC wrappings [after] writing "tedious bullshit".

I like Go

[Anonymous Coward]

I've done some experiments with Go and I like to see a language which does not follow the OOP hype. CSP is a very nice concept and easy to use with the channels and goroutines.

But what I really need is a toolchain that compiles binaries with dynamic libraries. This is how system executables should work. static binaries are not enough!

Re:I like Go

[Anonymous Coward]

So I guess this version 1 still doesn't support dynamic/shared libraries? That os the primary thing keeping me from seriously considering this programming language.

Holy hell, how can they put this much work into it and leave that out. Idiotic.

Re:I like Go

[Anonymous Coward]

It's built first and foremost to be the language that Google Web Server is written in; I guess they don't use dynamically linked libraries for that application.

Re:I like Go

[mounthood]

First, Go has an FFI system like every other language. You can directly compile C code into your binary, and make wrappers with "cgo" for C and C++ libraries. Second, you should read this about dynamic linking -- I don't know if it's perfectly accurate but it's definitely interesting: What does dynamic linking and communism have got in common?

Go has some good ideas

[larry bagina]

but mandating their terrible indent style is not one of them.

Re:Go has some good ideas

[Cenuij]

The style, or your preference for a particular style, is not important in the least. What's important is the consistency. Really... *nobody* cares what style *you* prefer.

Re:Go has some good ideas

[cgt]

I completely agree with this. I love Go! It is the most excited I have been about a programming language since Python, but the semi-colon issue is stupid. Why do automatic insertion of semi-colons if it causes problems? Why not just let developers insert the semi-colons themselves? Programmers have done so for decades so it probably won't kill them. Do it right or don't do it at all (automatic semi-colon insertion).

Re:Go has some good ideas

[istartedi]

IMHO the indent wars are best solved in the editors. For example, I've always preferred tabs because one tap of the tab key gets me to the start of the line. Holding down the spacebar is not ergonomic for me. I always overshoot or undershoot.

I could fire another salvo in the tabs vs. spaces war, or I could have an editor that's smart enough to look at spaces at the beginning of the line and let me tab through them. Problem solved.

I don't like Go's K and R indents either. This is only marginally more tricky to solve. The only solution I don't have for it is when use of __LINE__ comes into play. I love to use __LINE__ in C to generate location specific error return codes. If my editor transformed K and R to Whitesmiths then the line numbers would be different. The solution is for the editor to have a notion of shared and local line numbers. If code generated a runtime error based on __LINE__, I would just have to make sure that I told my editor to go to the shared line when debugging the error.

I'm not aware of any editors that have really nailed down a feature set like this. It's been a while since I've looked though.

Re:Go has some good ideas

[bill_mcgonigle]

Really... *nobody* cares what style *you* prefer.

The most important person who cares what style he prefers is him. Really, that's all that matters.

It's a silly reason to drive people away from your language. I'm sure a smart preprocessor could deal with many indent styles just fine, but what's scary is when the language developers say, "here is how you will use our language." Because other people always find more clever things to do with flexible languages than the designers intended. That's just being humble.

Re:Go has some good ideas

[mounthood]

The style, or your preference for a particular style, is not important in the least. What's important is the consistency. Really... *nobody* cares what style *you* prefer.

Go has "gofmt" which reformats code to a sensible standard and is also used by editors, so basically all code in Go is formatted consistently. There really isn't any discussion on formatting; everyone has taken the attitude of 'whatever gofmt does is fine, and that's the standard we'll use.'

Re:Go has some good ideas

[Anonymous Coward]

For example, I've always preferred tabs because one tap of the tab key gets me to the start of the line. Holding down the spacebar is not ergonomic for me. I always overshoot or undershoot.

I don't understand this comment. Who even uses the tab key or the space key for indenting with modern editors? autoindent, smartindent, cindent, etc. It is probably the weakest tabs vs spaces reason I have ever heard, regardless of the side you're on.

Re:Go has some good ideas

[larry bagina]

The C preprocessor (and other utilities that generate C code) use #line number [filename] to handle that situation.

Re:Go has some good ideas

[HiThere]

The semicolon issue probably isn't any more significant than Python's indentation based syntax. Both can work, and both require adjusting to. And both are a nuisance. I refused to use Python until they officially allowed tab based indentation (as long as you were consistent about it). I.e., as long as Python3000 was going to disallow tab based indentation, I wasn't willing to bother learning it. When they changed that, I found it something I could adapt to. I still find it annoying, but every language has its annoyances.

That said, my beef with Go is that my preferred indentation style alligns open and close brackets. I find this makes it much easier for me to identify a block of code. And Go explicitly forbids this. So I'll need to be shown that it's worth bothering with. (It's got lots of other features that I find questionable, but no others that are so obviously arbitrary misfeatures that were just insisted upon.)

Re:Go has some good ideas

[vAltyR]

Um... what problems are caused by the automatic semi-colon insertion?

Re:Go has some good ideas

[vAltyR]

Really... *nobody* cares what style *you* prefer.

The most important person who cares what style he prefers is him. Really, that's all that matters.

Every person who ever reads your code disagrees. Programming is not a solitary activity.

I'm sure a smart preprocessor could deal with many indent styles just fine, but what's scary is when the language developers say, "here is how you will use our language." Because other people always find more clever things to do with flexible languages than the designers intended.

How does having a canonical brace format in any way limit what you are able to do with the language?

As mentioned below, in the Go community there isn't much discussion of formatting. If you prefer a technical reason, then the canon format can be easily enforced using the "go fmt" command. Using a separate brace style means you must either manually enforce it, or fork gofmt and make the changes yourself. In the end, is it really worth the extra effort?

Re:Go has some good ideas

[bill_mcgonigle]

Every person who ever reads your code disagrees. Programming is not a solitary activity.

And in the mid-80's I was handing in work sets that needed to be run though a pretty-printer before submitting so the teacher only saw one typesetting variation (his preference). What's the excuse today? This was on a z80 card running in an Apple ][ and that ran in realtime so there's not a horsepower problem.

How does having a canonical brace format in any way limit what you are able to do with the language?

Does it not limit how you write your code?

Using a separate brace style means you must either manually enforce it, or fork gofmt and make the changes yourself. In the end, is it really worth the extra effort?

To some people it might be. I don't know why, but I'm not them. What's the harm in letting the machines handle formatting again?

Re:Go has some good ideas

[istartedi]

That would involve modifying the code. The crux of my argument is that it's a problem with editors, not code. Think "document view architecture".

Re:Go has some good ideas

[istartedi]

If you've got your editor tweaked up so that it feels good to you, then great. I haven't been able to quickly and easily tweak all the editors I've worked with in such a way that the output satisfies everybody else working on the code AND feels good to me. If all the editors were really that smart, we wouldn't be having this conversation. They'd just be auto-detecting the indent method and making it feel good for everybody. Plainly we aren't there yet.

Re:Go has some good ideas

[kikito]

It forces you to write the opening { on the same line. You can't write code like this:

foo(blah blah blah)
{
    other foos
}

You *have* to write it like this:

foo(blah blah blah) {
    other foos
}

For the record, I see this as an advantage, not an issue. But other people differ.

Re:Go has some good ideas

[cyclomedia]

I'm with the former, but I get tripped up by auto-indentation that either adds tabs to or b0rks when I write this

if( a==b )
{

}
else
if( c==d )
{

}
else
{

}

yes that's a lot of vertical space but I find it easier to follow, if it's my code in my project on my computer that I'm not even sharing then I should be able to do that!

Re:Go has some good ideas

[kikito]

You will probably be a lot more comfortable using a switch statement. I think they are more idiomatic than if - elseif -elses:

switch {
    case a==b:
        f1()
    case c==d:
        f2()
    default:
        f3()
}

Re:Go has some good ideas

[Bill Barth]

You know that Emacs has been able to let you use the tab key to insert the correct number of spaces for the current line for probably 30 years, right? I suspect that Vim can do it, too.

Re:Go has some good ideas

[vAltyR]

So the issue of canonical brace style and automatic semi-colon insertion kind of go hand in hand. If you know you're going to have a canonical brace style, then choose the one that allows you to simplify the rules of the automatic semi-colon insertion and allows easy line-at-a-time parsing for interactive implementations.

Re:Go has some good ideas

[cyclomedia]

True, but you can't put login in the Case in all the c-syntax languages that I use

Re:Go has some good ideas

[kikito]

I don't understand. What do you mean by "putting login in the Case"? And what do other languages have to do with this?

Re:Go has some good ideas

[istartedi]

Yeah terrific. Then after it's inserted the "correct number of spaces" and you are scrolling around in the code, you still have... spaces. So you stil have to hit the keys N number of times where N is the number of spaces it inserts, or try to hold down the space bar just the right ammount of time.

Maybe you won first chair in band and this kind of timing is easy for you. Lucky you. As I said originally, it's not ergonomic to have those spaces in there.

Once again, if it were such an easy problem to solve we wouldn't be arguing about it. Nevermind the fact that I prefer Microsoft's IDEs.

Re:Go has some good ideas

[istartedi]

Oops. I mean to say, "hold down the cursor keys the right ammount of time". Also, now that I think about it it's not even the precision of the timing that bothers me. It's the fact taping the arrow (cursor) keys once for each indent is always going to be faster than tapping it N times, or holding it for N cursor repeat periods. That little bit of extra wasted time is annoying.

Maybe somebody has programmed EMACS or ViM to to leap ahead N spaces when you press the proper key (at the beginning of a line only!). Also beside the point. There should be a generally agreed upon algorithm for loading the source and presenting an ergonomic interface to it without unnecessarily modifying the source. I don't think it's too tall an order. ALL the editor teams, including the ones from MS, Apple, Communist Free Software Collective Farm No. 254 and Evil Corporate Empire Inc. should implement it.

Maybe I'll sketch it out on tumblr at some point. It'd be an interesting exercise...

Re:Go has some good ideas

[Mabhatter]

Fixed-format RPGIII rules!!!!

What are the practical advantages?

[Anonymous Coward]

New programming languages aren't a bad thing, but why would one choose Go over other languages currently in use? I see Go programs can be deployed with the Google App Engine, but if a project isn't taking advantage of that, what project(s) would Go most likely be used for?

Announcing Go-BOTS

[Anonymous Coward]

Today I'm announcing the Go-Binary Object Translation System. More details on what it does later, after I figure that out, but it's called Go-BOTS.

Re:Announcing Go-BOTS

[Quirkz]

Go-Bots suck. Transformers are the only acceptable sentient machinery.

Funny, though, I'll give you that.

Re:Announcing Go-BOTS

[istartedi]

Can you download it through the Go Network Utility Transfer System?

Re:Announcing Go-BOTS

[Anonymous Coward]

Only when you using the Go Go Go Google Automated Download Generating Execution Transmitter.

Re:Announcing Go-BOTS

[I(rispee_I(reme]

Wandering far off topic here, but I don't get a chance to hold forth on Go-Bots every day...

While you're correct that Go-Bots will always be inferior to Transformers by most measures, they do surpass their Cybertron brethren in one important way: Transformers toys were made of molded plastic, while Go-Bots were made of die-cast metal.

This had two important results:

1. Go-Bots toys always won any fight against Transformers.

2. When you hit your little brother in the head with Cy-Kill, he stayed down until the paramedics showed up.

Re:Announcing Go-BOTS

[Quirkz]

Heh. I can't say I ever spent any time with the Go-Bots. I latched on to Transformers first and made it clear no substitute would do. I think I got one Go-Bot once, but it ended up at the back of the closet and ignored. My impression of them, though it may only have been the particular toy that I was given, was that even after "transforming" the robot mode looked almost entirely like the car it had started as, just placed on end with a few flaps folded out, rather than anything even vaguely humanoid. I know a few of the Transformers suffered from that, but I felt even some of the small and cheap ones (Bumblebee for instance) did a decent job of making the robot mode more humanoid.

A few of the Transformers *did* have scattered bits of metal in their construction mixed in with the plastic, though often which pieces and why seemed pretty random. A car door here, half a leg there, some chunk of incongruous shiny gold-colored metal mixed into the grey of a Dinobot for no reason, etc.

I'll admit I never clunked my little brother in the head with a Transformer, and it was entirely because I didn't want to damage the toy, and had nothing to do with fearing I might damage him.

Re:Announcing Go-BOTS

[Anonymous Coward]

You can, but you don't have to. Real men use the Go Network Automated Delivery System.

Go for Web Applications?

[Anonymous Coward]

I've been looking beyond PHP for a while, and Go seems like a reasonably good programming language (albeit not entirely comparable to languages like PHP) for web applications. Activity around Go isn't *crazy* but there are quite a few resources for what was a "beta" language up till now.

It also seems like Google is giving the project a good distance (note that the official website doesn't mention Google anywere apart from the occasional video), which I think is a good thing.

Anyone here ever used Go for anything serious?

Re:Go for Web Applications?

[mounthood]

You can use Go on Google App Engine: https://developers.google.com/appengine/docs/go/

In other news

[gadzook33]

In other news, Google discovers the value of namespaces. Seriously, I am so tired of new languages with no real reason for being other than "because we could".

Re:In other news

[Anonymous Coward]

I'm planning a new langauge called Go2. It is a revision of Intercal with the addition of tag lines and goto statements.

Beard?

[ch-chuck]

Do the developers of GO have beards?

Re:Beard?

[Cenuij]

At least one does: http://googleblog.blogspot.fr/2011/05/japan-prize-honors-googler-ken-thompson.html

Pi is wrong on the main site

[Anonymous Coward]

If you use the little snippet, concurrent pi displays the wrong digits.

http://golang.org/

screenshot: http://i.imgur.com/v23W3.png

Re:Pi is wrong on the main site

[Cenuij]

// It is an unreasonable way to calculate pi.

Re:Pi is wrong on the main site

[rgbrenner]

This is interesting... If you run the Concurrent Pi example program on the Go website.. it prints:

3.1417926135957908

But it should be:

3.1415926535897932

It's wrong starting with the 5th digit...

What kind of language is that inaccurate? And why would they use it as an example program?!

Re:Pi is wrong on the main site

[Zoinky]

As it mentions in the code, it's an approximation of pi using concurrency. The number of "goroutine" calls used determines the accuracy. In the code comments, they refer you to http://goo.gl/ZuTZM if you want more information on the algorithm they are using. Increasing the accuracy is just a matter of increasing n in their example.

Re:Pi is wrong on the main site

[shutdown -p now]

So, Go is a language best suited for quickly obtaining inaccurate answers? ~

Re:Pi is wrong on the main site

[rgbrenner]

In Google's example, the number of goroutine calls was 5000. In the link you posted, it was set to 300,000, and he got:

3.14159598691202

In other words, 2 additional accurate digits.

I get that this is supposed to show how Go handles a large number of concurrent processes (not to calculate pi).. but shouldn't it still be accurate? especially if you are making 300,000 calls and are only posting 15 digits of pi

Re:Pi is wrong on the main site

[eldacan]

but shouldn't it still be accurate? No. The imprecision has nothing to do with Go. It comes from the mathematical algorithm used to approximate pi.

Re:Pi is wrong on the main site

[Anonymous Coward]

as it turns out, i have a cpu integer performance comparison program
written in c that calculates pi in exactly the same way. it's horribly
slow. it takes ~500m loops to get 9 digits accuracy.

Re:Pi is wrong on the main site

[Anonymous Coward]

Since when is it the *language* that is inaccurate, rather than the *algorithm*?

Go does floating point ops just like all the other languages do - on the CPU.

Re:Pi is wrong on the main site

[Zoinky]

http://en.wikipedia.org/wiki/Leibniz_formula_for_pi#Inefficiency discusses the algorithm in a bit more detail. To calculate 10 digits correctly requires n=5,000,000,000, it seems. So there are definitely better algorithms (a variant with better convergence is presented in the same Wikipedia article), but as you say, it's just an example to show concurrency in the Go language.

Re:Pi is wrong on the main site

[rgbrenner]

interesting formula.. thanks for the link

GO is the next major language (SQUIRREL!)

[gestalt_n_pepper]

Just like google real estate will transform the industry (SQUIRREL!) and google's solar power efforts will transform the world (SQUIRREL!) and google's anonymous accounts that protect user privacy (SQUIRREL!).

Sure, I'll invest my precious time in Go. You bet.

Re:GO is the next major language (SQUIRREL!)

[nschubach]

The amazing thing about corporations is that they are comprised of many individuals who can concentrate on many things at once without being distracted by what color squirrel is running past the office in some other lab.

Re:GO is the next major language (SQUIRREL!)

[ZeroSumHappiness]

SQUIRREL!

What is go?

[stox]

Answer: It is the follow on to Limbo.

It lacks a lot of things that you would expect

[Chrisq]

It lacks a lot of things that you would expect, like inheritance and operator overloading. To me this is a step too far, I mean its like going back to the 70s and using straight c almost.

Re:It lacks a lot of things that you would expect

[Anonymous Coward]

Given what a clusterfuck OOP has been, it's good to see new languages have jumped off the sinking ship. Inheritance makes for bloated, unreadable code. Good code uses composition instead, which means you don't have to spend hours tracking down weird vtable bugs.

Operator overloading I happen to agree with you, but it's not a super crucial feature really, just sugar.

I don't much care about go, but anyone who challenges the OOP priesthood is worth listening to in my book.

Re:It lacks a lot of things that you would expect

[Chrisq]

Given what a clusterfuck OOP has been, it's good to see new languages have jumped off the sinking ship. Inheritance makes for bloated, unreadable code. Good code uses composition instead, which means you don't have to spend hours tracking down weird vtable bugs.

In no programming language should you ever have to worry about the vtable, in fact you should only be able to be aware of it in system programming languages. I haven't come across bugs in inheritance since the very early days of C++, when it was implemented as a preprocessor for c.

That said I know that inheritance is one of those things that people disagree on, and thinking that we are better off using composition is a respectable stance. That said, though I would be the first to acknowledge that inheritance can be used to implement bloated, unreadable code, I believe that used correctly it can give very elegant and easy to read solutions.

BTW I meant function overloading rather than operator overloading ... but "go" supports neither.

Re:It lacks a lot of things that you would expect

[Anonymous Coward]

It doesn't need inheritance, it has embedding. Favor composition over inheritance (FCoI).

Re:It lacks a lot of things that you would expect

[mounthood]

Take a look at type embedding: http://golang.org/doc/effective_go.html#embedding

Go does not provide the typical, type-driven notion of subclassing, but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface.

Re:It lacks a lot of things that you would expect

[Chrisq]

Take a look at type embedding: http://golang.org/doc/effective_go.html#embedding

Go does not provide the typical, type-driven notion of subclassing, but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface.

That's interesting. I can see that they have gone full hog with the composition paradigm and given some innovative ways of implementing it. I will really have to take a look at this.

It seems to me that go is almost the direct opposite of Scala. Scala takes the approach that anything that the compiler can possibly infer it should do, regardless of impact on compile time, whereas go takes the approach of designing the language to facilitate fast compile time. Scala draws from the inheritance model - introducing mixins to give a well-defined multiple inheritance pattern - which can get complex. Go eschews inheritance and goes with composition.

I need to take a good look at go, because I am a Scala fan and want to avoid getting locked in to a single way of thinking.

Again, Really?

[FlyingGuy]

I was SO hoping this would be another abandoned project

The syntax just blows!

Rube Googleberg Machines?

[Mannfred]

FTFA:

You might have seen early Go talks in which Rob Pike jokes that the idea for Go arose while waiting for a large Google server to compile. That really was the motivation for Go: to build a language that worked well for building the large software that Google writes and runs.

I looked at the Go pages for 15 minutes to try to figure out why this was commissioned as a project to begin with. Ultimately I ran into the above paragraph. Projects like this make me think that Google no longer has a clear idea of how they could improve their existing business, so they're spending an increasing amount of time rearranging deck chairs to keep their programmers busy on the off chance that they'll need them for something useful.

Re:Rube Googleberg Machines?

[Cenuij]

I don't think you fully grok what they have achieved. Google employs only a handful of people who work on Go, and probably not all them work full time on it (though maybe that's not true lately in the last release cycle).Let me give you a quote from an accomplished (hint, you use his code every day) C & C++ hacker on using Go:

"In my experience Go is probably 5-10x faster than C or C++. I estimate that programs that take me half an hour to write in Go would take me about 2½ hours in C and 5 hours in C++."

Then when you only have to wait about 10 seconds or so for the whole Go std library *and* all your own libs and binaries to build, you can see it's value over waiting for large C++ projects (of which Google has many) to build.

Re:Rube Googleberg Machines?

[jgrahn]

I don't think you fully grok what they have achieved. Google employs only a handful of people who work on Go, and probably not all them work full time on it (though maybe that's not true lately in the last release cycle).Let me give you a quote from an accomplished (hint, you use his code every day) C & C++ hacker on using Go:

"In my experience Go is probably 5-10x faster than C or C++. I estimate that programs that take me half an hour to write in Go would take me about 2½ hours in C and 5 hours in C++."

Who's that? One of the Go designers, perhaps? He's doing something fundamentally wrong if it takes him more time to code in C++ than in C.

Then when you only have to wait about 10 seconds or so for the whole Go std library *and* all your own libs and binaries to build, you can see it's value over waiting for large C++ projects (of which Google has many) to build.

Long compile times is more of a build system problem than a compiler problem, IME. Of course, lots of people have broken build systems, and compile the same things over and over again ...

Re:Rube Googleberg Machines?

[GreatBunzinni]

"In my experience Go is probably 5-10x faster than C or C++. I estimate that programs that take me half an hour to write in Go would take me about 2½ hours in C and 5 hours in C++."

Extraordinary claims require extraordinary evidence. And the evidence that is out there states that the claim Go is 5-10x faster than C or C++ is bullshit. In fact, it's slower.

Notice the benchmark where Go took 30x the time the C program did to finish the benchmark?

Re:Rube Googleberg Machines?

[shutdown -p now]

He is saying that Go is 5-10 times faster to compile than C++, not that the output binary runs faster.

Re:Rube Googleberg Machines?

[hanwen]

I write both Go and C++ at google. Sadly, Rob Pike's joke has a definite core of truth: writing C++ code at google is extremely time-consuming and difficult to get right because it has to be multi-threaded and asynchronous.

Long compile times is more of a build system problem than a compiler problem, IME. Of course, lots of people have broken build systems, and compile the same things over and over again ...

Well, our in-house developed build system is the best I've ever seen, and probably the best in the industry. Read more about it here. Even with all the niftyness of a thoroughly correct build system and a data-center sized ccache, it still sucks.

Go is definitely awesome, and I recommend everyone to set aside the gripes with the syntax and learn it. I guarantee you that you'll be pleasantly surprised.

Re:Rube Googleberg Machines?

[bbn]

Notice the benchmark where Go took 30x the time the C program did to finish the benchmark?

Apparently this is a case of the C program using a mature library to do the heavy lifting. The Go program uses a slower library. Neither the C program nor the Go program actually implement the algorithm so it is a poor test of the languages and compilers. Instead it is a test of the libraries.

A practical program depends alot on libraries so I am not trying to talk down the significancy of a slow library. I am just pointing out that as a language and as a compiler the Go team is appears to be doing fairly well on the shootout. They have a much younger compiler yet they generate code that is within 2x of C. And the code size of the program is smaller in all cases, sometimes significantly smaller.

This tells me that for the 1% of my program were speed matters, I will probably be able to optimize that part to be very close to C. If necessary by avoiding using any slow libraries. For the 99% of the program I can take advantage of smaller code size, safer coding (no pointer arithmetic) and fast development.

Disclaimer: I have never used the Go language.

Re:Rube Googleberg Machines?

[Anonymous Coward]

func foo(y int) int {
                var (
                                a, b c int
                                x, y, z float64
                                p, q, r string
                )
}

Re:Rube Googleberg Machines?

[Anonymous Coward]

FYI, there is

var (
      x, y, z int
      foo string
)

Re:Rube Googleberg Machines?

[Anonymous Coward]

Dear self-claimed expert,

If you could read, you'd learn that in Go, you rarely define variables. Instead, you use automatic declarations when you need them using :=

x := 1 // eq: var x = 1;
x, y, z := 1, "hello", 4.5 // x will be of type int, y string and z float

So much for your expertise. Get off my lawn.

Re:Rube Googleberg Machines?

[Cenuij]

Please re-read the quote, there is no claim of execution performance. The quote was entirely about the time it takes for a proficient hacker to write a program in the three languages.

Re:Rube Googleberg Machines?

[celle]

You know all you 'whatevers' whining about syntax reminds me about what George Carlin said about "bad hair days".

"Put on a hat and go to work you shallow ..." -- George Carlin

In other words:
Reset your damn editor and get to work! -- me

Re:Rube Googleberg Machines?

[Cenuij]

I was quoting Russ Cox

A work in progress

[MRe_nl]

Fuego, North Korean Silver Star/KCC Igo, ZhiXing Chen's Handtalk, Michael Reiss's Go++, David Fotland's Many Faces of Go, GNU Go. Still nothing close to human.

http://en.wikipedia.org/wiki/Computer_Go

Re:A work in progress

[Raenex]

Still nothing close to human.

I don't know what you mean by that. If it's performance, you don't make any mention of Zen. Try reading the "Recent results" section from your link. It's 6d on KGS (5d in slower games), and recently beat a pro with only 4 stones handicap.

Re:A work in progress

[MRe_nl]

ONLY 4 stones handicap? My grandmother could beat a pro with four stones handicap, and she was a Bridge player ; ).

Re:A work in progress

[Raenex]

Unless you're a dan player, a pro could probably spank your ass with 9 stones easily. Besides the pro game, 6d KGS is quite strong.

Did they name it properly?

[Iniamyen]

I wonder if it is a recursive acronym for "Go's Optional"

Another new langauge?

[Dwedit]

How does this language compare with Mozilla's new programming language?

Time to Give Go Another Look

[inglorion_on_the_net]

First time I looked at Go, my conclusion was "this language isn't ready". The next time I looked at Go, I concluded that it had essentially bled to death. But the release of version 1 changes things. I will take another look. I hope they've worked out enough of the details for me to be able to tell if this is a language I would love to work with or not.

Re:Time to Give Go Another Look

[iplayfast]

The semicolon at the end of the line thing decided me that it was a toy language. That the meaning of the statement(s) change if the semicolon is on a new-line or on the same line.

Re:Time to Give Go Another Look

[Cenuij]

Just skip through the tour: http://tour.golang.org/ until you find something interesting to play with.

Re:Time to Give Go Another Look

[Anonymous Coward]

The semicolon at the end of the line thing decided me that it was a toy language. That the meaning of the statement(s) change if the semicolon is on a new-line or on the same line.

Yeah, semicolons are certainly the main concern in evaluating a language. It's right up there with } versus ) versus "end".

Re:Time to Give Go Another Look

[kikito]

> That the meaning of the statement(s) change if the semicolon is on a new-line or on the same line.

I don't know what you mean. In Go, semicolons are clearly stated *not* supposed to be used to end lines. There is no ambiguity there.

Re:Time to Give Go Another Look

[iplayfast]

I can't remember the specifics now, but it was something to do with the meaning of the line changing if the semicolon was on the end of the line, or on the next line. The statement was one that needed a semicolon. So to me it showed a big inconsistency.

Re:Time to Give Go Another Look

[kikito]

Semicolons are never on the next line. I don't know where you get that idea from. Maybe you are referring to the opening bracket (see my comment below). But even in that case, it's not a case of "the program meaning two different things" (as it happens in Javascript in certain cases). It's a case of "the program will not compile if you don't put the opening bracket in the same line".

Re:Time to Give Go Another Look

[iplayfast]

You could be right. I spent a few days playing with it, then dropped it, so those memory cells have been reclaimed for other uses. Still even if it is as you state, requiring an open brace to be at the end of the line or else it's a syntax error, seems arbitrary, and IMHO ugly.

nothing to see here...

[Anonymous Coward]

I looked and saw a lot of high-mindedness.

Let me know when it can define itself (i.e., its source is "go"),
and maybe I'll be impressed (I suspect it's 'C' or c++).

Many have tried to match the incredible elegance of C, none
have succeeded so far, JMHO.

Re:nothing to see here...

[tibit]

I don't see how C is elegant. It's a horrible pain to write a lot of modern code from across many disciplines in C and even C++. Most software that deals with hardware or UIs needs to process asynchronous events and producers/consumers, so you need state machines and yield at the very least. Those are almost universally a royal pain to hack around. Just look at the statechart and msm libraries in boost -- and that's C++, not C! In plain C, look at Miro Samek's QP framework. Both C and C++ gets you to drown in irrelevant syntax for anything but old style procedural code, never mind that those languages artificially hide introspective data -- for example, there's no generic way in C nor C++ to add structural information about instances to enable non-conservative garbage collection. Go is a step in the right direction at least, even if it offers no compile-time computation (I consider that a must in any modern language).

Re:nothing to see here...

[Anonymous Coward]

Stop trying to use frameworks and get back to the basic language. It's easy and clean to do event-oriented programming in C. Hand written state machines can be written more easily and legibly in C than in just about any other language. This is where the quirks of C shine through.

Integration with other libraries will always be a PITA, and no framework will ever fix that; odds it'll makes things worse by adding complexity and obscurity. The best you can do is focus on the maintainability of your own code: less code, fewer dependencies, saner and simpler designs. Don't try to solve every problem under the sun; rather, solve the problems right in front of you as simply and elegantly as possible, and don't worry about imaginary problems, which will always look different when you actually come upon them.

Re:nothing to see here...

[tibit]

Hand written state machines can be written more easily and legibly in C than in just about any other language.

If you think that doing explicit double dispatch by hand is somehow legible or OK performance wise, then I've got a couple bridges to sell. The best C-style hierarchical state machine code will have potentially crippling overheads due to runtime traversal of state handler hierarchy. By overheads I mean that the handler traversals may take an order of magnitude longer than whatever the state handler did.

Things are somewhat broken if you can write state machines with less syntax and runtime overhead and in a higher-level style in a decent macro assembler than in C. In good a macro assembler, you can exploit assembly-time computation to generate specific state traversals automagically and forgo any sort of runtime exploration of the hierarchy. In C, a supposedly higher-level language, you can't do squat for compile-time computation except for preprocessor metaprogramming (sigh). In C++, template metaprogramming is still such a resource hog on the available compilers that it's wholly impractical for anything but toy state machines, never mind that forcing functional programming for compile time computation in a fundamentally imperative language seems like an odd choice at best. Sane people give it a look and say: WTF?!

As for using frameworks: those are a.k.a. libraries. There's only so many times the humanity needs to reimplement and debug UML statechart semantics. I'd much rather reuse tested and optimized code than reinvent the wheel.

I'm not concerned at all with integration with anything -- only about making my own code look decent. I think I know every published way out there that producers/consumers ("yield") and state machines can be implemented in either C or C++, and it's not an amusing picture at all. Interestingly enough, it seems that out of "old" high-level languages still in common use only Lisp lets you implement both yielding generators and state machines such that there's no extra syntax overhead, no manual housekeeping, and no runtime overhead. C# and Python take care of generators, and both CLR and JVM will let you implement a library that rewrites code to generate precomputed state hierarchy traversals, but it's not fun to implement and I don't know of any decent open source implementations anyway. Forth lets you do what Lisp would let you do, but I'd be hard pressed to call it a high-level language.

silly

[Anonymous Coward]

Slashtards - everyone knows that version numbers are arbitrary... the only version number that counted was 1.2.13

does Google even use it?

[Anonymous Coward]

Last time I checked Googlers were limited to C++, Java, JS, and Python. Isn't this little more than a hobby project of people that work at Google? Maybe calling it "Google's systems programming language" is a bit of a stretch.

Re:does Google even use it?

[K. S. Kyosuke]

Last time I checked Googlers were limited to C++, Java, JS, and Python.

If you check now, you'll find out that the list is C++, Java, JS, Python and Go. In future, it may even be just C++, Java, JS and Go, judging from the trend at Google. (Specialties like Sawzall don't count here, I guess.)

new Rune data type

[bames53]

I see language designers are still making the mistake of trying to represent characters as fixed size entities. Go 1 adds a new data type 'rune' intended to represent a UTF-32 codepoint, which is fine as long as it's only used for code points, but then the example code they show is:

        delta := '' // delta has type rune.
        var DELTA rune
        DELTA = unicode.ToUpper(delta)

When you design an API that accepts or returns individual characters (as opposed to code units or code points), do not use rune, char, wchar_t, char16_t, char32_t, int, or any other fixed length type to represent a character. Characters are fundamentally variable length.

You should use a string data type because fixed size types can only represent a subset of characters. For example, a single UTF-32 code point cannot represent the Lithuanian characte LATIN SMALL LETTER A WITH OGONEK AND ACUTE. In Unicode this character can only be represented as a sequence of multiple code points (<U+0105> <U+0301> or <U+00E1> <U+0328> or <U+0061> <U+0328> <U+301>). So using strings works whereas using a fixed size type will inevitably fail.

Using strings to represent a character has another advantage beyond the fact that it's the only way that works. It eliminates the client's need to convert between the string type and the type used to hold a code point. Clients can just directly use text in whatever the native encoding is.

Re:new Rune data type

[Waffle Iron]

Q: What is a string?
A: A sequence of characters

Q: Ok, what is a character?
A: Well obviously, each character should be a string!

QED

Re:new Rune data type

[shutdown -p now]

Q: What is a string?
A: A sequence of codepoints

FTFY.

Re:new Rune data type

[jrumney]

A "character" data type has no meaning beyond representing codepoints. There are languages, such as Hindi (and other South Asian languages) and Arabic, where any attempt to output a single character at a time will result in an unreadable mess due to the fact that characters change their shape depending on what comes before or after. So a better rule is not to use strings to represent a character, but to always output whole strings, never individual characters.

Re:new Rune data type

[Anonymous Coward]

Your rant is really against "unicode.ToUpper" taking a codepoint and receiving a codepoint. This has nothing to do with language design; only library design. Of course the intrinsic type to hold a codepoint only holds codepoints. What the fuck do you expect to compose your string-that-supports-ToUpper-even-in-obscure-languages from?

Possible replacement for Dalvik into the future?

[Pengo]

Does anyone know if this is an R&D project that could be poking at the idea of a litigation free runtime for Android away from Dalvik?

I'm curious to see how this language evolves and its internal adoption inside of google.

Regardless of the language taking off or not, it's a great to see a new language enter the ecosystem, and no doubt we'll learn things from it that can be brought back into main-stream languages or interesting innovation that could open the doors for new (pray disruptive) development in new areas.

Dependency Management

[vAltyR]

One thing I'd like to add that most people miss is that the language was designed for easy dependency management, and it's built into the go tool. For instance, if you download library A that depends on library B that you don't have installed, when you build library A the tools will download, install, and build library B automatically.

gofmt is the killer feature...

[Anonymous Coward]

If there's one thing we can be sure shall apply to various future languages is the fact that the formatting of the source code is mandated by the specs.

This is a godsend to parsers, tools authors, IDE authors, Emacs pluging authors, and whatnots.

It ends the age old retarded spewtard "my indentation style is better than yours" war. I just love it.

Also, before comitting, you SHOULD use gofmt to format to the official formatting and then commit. No more "zomg but I prefer this lame indentation style so I reindented everything and then commited like a noob".

This is wonderful. For this feature only I'd switch to Go.

Or I could dream of "Javalang", which would be Java (not my choice) but with a clearly specified formatting.

Re:gofmt is the killer feature...

[Anonymous Coward]

Also, Allman Style blows.

Pity the fool...

[Anonymous Coward]

...with a closed mind. Of which there seem to be several in this thread. Come on guys, what happened to your sense of adventure? Are you all such corporate drudges that you can't have fun with programming anymore? No wonder Commander Taco left. Goodness, what a bunch of sticks in the mud!

BTW, that attitude is exactly one of the reasons why they created Go...

Skynet, is that you?

[Pepebuho]

Skynet, is that you?

MOD PARENT UP

[Anonymous Coward]

This is a continuing source of confusion (apparently). To be Unicode-correct, you must avoid treating strings as sequences. (There are certainly individual cases where it may be valid to do so, but you can't assume that it is.)

I guess the simple way to think about it is that the strings are an ADT unto themselves.

Stick it inside Android.

[Anonymous Coward]

If Google really thingks the langauge is cool, why not use it as the default app programming language in Android OS and thereby get Oracle, whose Java programming language Google has unabashedly cloned or reimplemented, off its back.

it seems you hate them so much ....

[Anonymous Coward]

you use their email.

Re:Possible replacement for Dalvik into the future

[Anonymous Coward]

New languages are cool, but we the world is rich with programming languages. What we are really missing is a good cross platform GUI programming environment.

Re:Go is already being used while obviously buggy.

[Anonymous Coward]

Scary, not amazing.

$ cat imports.go
package main
import (
    "fmt"
    "math"
)
func main() {
    fmt.Printf("Now you have %g problems.\n", math.Nextafter(2, 3))
}
$ go run imports.go
Now you have 2.0000000000000004 problems.

Same on google's site (click on the "RUN" button to execute):

http://tour.golang.org/#4