Slashdot Mirror
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.'"
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
"When in doubt, use brute force." Ken Thompson
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?
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?
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
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!
but mandating their terrible indent style is not one of them.
Do you even lift?
These aren't the 'roids you're looking for.
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?
Do the developers of GO have beards?
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Go-Bots suck. Transformers are the only acceptable sentient machinery.
Funny, though, I'll give you that.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
// It is an unreasonable way to calculate pi.
my other sig is written in brainfuck
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.
Please do not read this sig. Thank you.
Answer: It is the follow on to Limbo.
"To those who are overly cautious, everything is impossible. "
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.
I was SO hoping this would be another abandoned project
The syntax just blows!
Hey KID! Yeah you, get the fuck off my lawn!
FTFA:
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.
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
"Kill 'em all and let Root sort 'em out"
I wonder if it is a recursive acronym for "Go's Optional"
How does this language compare with Mozilla's new programming language?
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.
Please correct me if I got my facts wrong.
Can you download it through the Go Network Utility Transfer System?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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).
A successful API design takes a mixture of software design and pedagogy.
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.)
Ezekiel 23:20
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.
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?!
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 has type rune.
delta
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.
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.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
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.
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.
So, Go is a language best suited for quickly obtaining inaccurate answers? ~
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
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.
Skynet, is that you?
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.
A successful API design takes a mixture of software design and pedagogy.
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.
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.
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.
interesting formula.. thanks for the link