Google’s programming language, Go, gets a big speed boost

Google's Go hits version 1.1, now goes 30 to 40 percent faster.

Google has released version 1.1 of Go, its open source programming language, bringing significant performance improvements.

"We have made optimizations in the compiler and linker, garbage collector, goroutine scheduler, map implementation, and parts of the standard library," Google engineer Andrew Gerrand wrote on the Go blog yesterday. "It is likely that your Go code will run noticeably faster when built with Go 1.1." Go 1.1 is compatible with Go 1.0, so all users should upgrade.

Go was unveiled in 2009 after being developed inside Google for a couple of years. It was designed from the start to offer an "expressive type system, fast compilation, good performance, and built-in language features that simplify threaded programming and concurrency," as Ryan Paul wrote for Ars at the time. Google uses Go internally for a few services, including the server that delivers Chrome binaries.

Go code should run 30 to 40 percent faster in the new version, Google said:

Typical improvements relative to Go 1.0 seem to be about 30%-40%, sometimes much more, but occasionally less or even non-existent. There are too many small performance-driven tweaks through the tools and libraries to list them all here, but the following major changes are worth noting:

The gc compilers generate better code in many cases, most noticeably for floating point on the 32-bit Intel architecture.

The gc compilers do more in-lining, including for some operations in the run-time such as append and interface conversions.

There is a new implementation of Go maps with significant reduction in memory footprint and CPU time.

The garbage collector has been made more parallel, which can reduce latencies for programs running on multiple CPUs.

The garbage collector is also more precise, which costs a small amount of CPU time but can reduce the size of the heap significantly, especially on 32-bit architectures.

Due to tighter coupling of the run-time and network libraries, fewer context switches are required on network operations.

Promoted Comments

I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

I suppose since anyone could fork the tools and implicitly change the language behavior, you could consider the language open source. But that doesn't seem to be the reality. Vendor specific extensions (that eventually die or make it onto the next standard) aside, the major languages I can think of all seem to have some standard mechanism in place to define future standards of the language itself that are independent of how the tools, environment and everything else are licensed. And those mechanisms don't seem to fall in the "open source/close source" paradigm.

By this definition I don't believe any project would be considered open source. I can't think of any software project that doesn't have a Benevolent Dictator(either a person, company or group) making the final decision as to what goes in and what doesn't. It is open source because if you don't agree with the Benevolent Dictator, you are free to make your own version where you are in control and all you have to change is the name.

tl;dr - there were facets of Go's implementation that resulted in numerous untraceable bugs, even on the part of the original software programmer.

Go's Git integration had nothing to do with the problems listed in the blog post (it's just an excuse).

The problem is the original developer used a third party library, but never documented the arbitrary version he picked and didn't keep up with upstream (which is a bad idea in any language). And even worse, he modified his local copy, but then didn't distribute that local copy (which is an EVEN WORSE IDEA).

The fact that they picked a language like Go for a game is also... very odd. Their rationale was 'it wasn't ill-suited for game development' (despite having no games written in it).

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

From Wikipedia's article on "Open Source":

Quote:

Generally, open source refers to a program in which the source code is available to the general public for use and/or modification from its original design.

Seems like a pretty common definition. Doesn't Go satisfy this definition?

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

Does Python count as an open source programming language in your view? Just wondering because this is a fairly common description.

I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

I suppose since anyone could fork the tools and implicitly change the language behavior, you could consider the language open source. But that doesn't seem to be the reality. Vendor specific extensions (that eventually die or make it onto the next standard) aside, the major languages I can think of all seem to have some standard mechanism in place to define future standards of the language itself that are independent of how the tools, environment and everything else are licensed. And those mechanisms don't seem to fall in the "open source/close source" paradigm.

(Edit: Of course those mechanisms for evolving the language can be "open/closed/proprietary" - I am talking about "open source" "closed source" specifically". That is why I think what Go has on their main page - "Open source programming environment" is a more apt description.)

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

I suppose since anyone could fork the tools and implicitly change the language behavior, you could consider the language open source. But that doesn't seem to be the reality. Vendor specific extensions (that eventually die or make it onto the next standard) aside, the major languages I can think of all seem to have some standard mechanism in place to define future standards of the language itself that are independent of how the tools, environment and everything else are licensed. And those mechanisms don't seem to fall in the "open source/close source" paradigm.

By this definition I don't believe any project would be considered open source. I can't think of any software project that doesn't have a Benevolent Dictator(either a person, company or group) making the final decision as to what goes in and what doesn't. It is open source because if you don't agree with the Benevolent Dictator, you are free to make your own version where you are in control and all you have to change is the name.

[quote="I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

But such pedantry is critical to programming. If you want your programs to actually work, you need to be precise about distinctions in definitions of things. "Well, sorta something related to that" doesn't tend to be good enough. I'm reminded of helping programmers with problems related to, for example, confusing the properties of a type with the properties of a particular object of the type.

The problem for Haunts was that these modules were modified on both the developer's machine and in the upstream repository. That developer has now left, and the code is now maintained by volunteers who are trying to understand how the code is structured to get it so that it (a) builds and (b) runs.

That Go allows referencing code from external sources at unspecified versions makes the code hard to maintain, as the code will change under your feet. The repository syncing should be managed by either referencing the repository via "git submodules" where you can specify the exact version to use, via a pre-built version using something like autotools or adding the code directly to the repository. That way, you have control over the version of the module you are using. Also, you should also be referencing release builds that should be more stable.

What's the definition of such a language?AFAIK Go is designed by Google, it's basically a proprietary language.An 'open source' Go compiler / platform might be available but that doesn't make it an open (source) language.

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

You're free to fork and modify the language as well as the tools. Sounds like open source to me.

tl;dr - there were facets of Go's implementation that resulted in numerous untraceable bugs, even on the part of the original software programmer.

Go's Git integration had nothing to do with the problems listed in the blog post (it's just an excuse).

The problem is the original developer used a third party library, but never documented the arbitrary version he picked and didn't keep up with upstream (which is a bad idea in any language). And even worse, he modified his local copy, but then didn't distribute that local copy (which is an EVEN WORSE IDEA).

The fact that they picked a language like Go for a game is also... very odd. Their rationale was 'it wasn't ill-suited for game development' (despite having no games written in it).

I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

I suppose since anyone could fork the tools and implicitly change the language behavior, you could consider the language open source. But that doesn't seem to be the reality. Vendor specific extensions (that eventually die or make it onto the next standard) aside, the major languages I can think of all seem to have some standard mechanism in place to define future standards of the language itself that are independent of how the tools, environment and everything else are licensed. And those mechanisms don't seem to fall in the "open source/close source" paradigm.

By this definition I don't believe any project would be considered open source. I can't think of any software project that doesn't have a Benevolent Dictator(either a person, company or group) making the final decision as to what goes in and what doesn't. It is open source because if you don't agree with the Benevolent Dictator, you are free to make your own version where you are in control and all you have to change is the name.

I am not saying that tools/environment are not open source. I am talking about the specification of the language itself. In practice, are there 8 variations of the Java language with significant traction, all calling themselves Java Language Specification 2.1, because people "forked" the language itself? Or are there instead multiple implementations of the JVM because there are both closed and open source variants of the implementation?

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

You're free to fork and modify the language as well as the tools. Sounds like open source to me.

Given that the language specification is nothing more than a description/definition document I guess the shopping list my wife left me this morning qualifies as "open source"

I dunno, just seems to me that there is merit in differentiating between the tools/environment and the language, because for some uses, having language itself developed behind closed doors on an unknown time frame is not beneficial.

So I make a version of the Go tools/environment that supports variations in the language that Google doesn't support - is anyone really going to consider that "Go" when it is not blessed by the entity that the vast majority of users consider the keeper of the language spec? How did the Java modifications in Visual J++ go over in the 90s?

Does changing a Word Google Docs document really qualify as open source?

I am not saying that tools/environment are not open source. I am talking about the specification of the language itself. In practice, are there 8 variations of the Java language with significant traction, all calling themselves Java Language Specification 2.1, because people "forked" the language itself? Or are there instead multiple implementations of the JVM because there are both closed and open source variants of the implementation?

The implementation(s) of a a language are more defining than the specifications. Since all Go implementations seem to be open source, I think that calling it an open source language fits well enough. I'd think there'd have to be a notable (or existing at the least) closed source implementation in existence to say otherwise.

Human languages are not precise for every context. Close enough is close enough. When someone releases a closed source implementation, then you can start QQing over semantics.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

You're free to fork and modify the language as well as the tools. Sounds like open source to me.

I agree with this. Too many spoiled people in this thread not stuck using closed languages. For example, take MATLAB:

I admit it is pedantry. But if you look at the the Wikipedia page for "open source programming languages" for instance, the actual license is listed under the heading "Implementation License". In other words, the license for the implementation of the tools or environment, e.g., compiler, interpeter, standard libraries, etc.

I suppose since anyone could fork the tools and implicitly change the language behavior, you could consider the language open source. But that doesn't seem to be the reality. Vendor specific extensions (that eventually die or make it onto the next standard) aside, the major languages I can think of all seem to have some standard mechanism in place to define future standards of the language itself that are independent of how the tools, environment and everything else are licensed. And those mechanisms don't seem to fall in the "open source/close source" paradigm.

(Edit: Of course those mechanisms for evolving the language can be "open/closed/proprietary" - I am talking about "open source" "closed source" specifically". That is why I think what Go has on their main page - "Open source programming environment" is a more apt description.)

Right, it is distributed under an open source license. Like Chromium or Android.

Those are the tools. The phrase "open source programming language" is a little strange. Even on the Go's main page the statement is "open source programming environment".

For a given language, there may be open or closed source tools, runtime environment implementations, etc... or both.

The language itself may be designed by committee, by single organization or entity, as well as be or not be certified as a standard of some sort. But categorizing that method of control for determining language evolution doesn't really fit into an "open source/close source" definition.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

You're free to fork and modify the language as well as the tools. Sounds like open source to me.

Given that the language specification is nothing more than a description/definition document I guess the shopping list my wife left me this morning qualifies as "open source"

I dunno, just seems to me that there is merit in differentiating between the tools/environment and the language, because for some uses, having language itself developed behind closed doors on an unknown time frame is not beneficial.

So I make a version of the Go tools/environment that supports variations in the language that Google doesn't support - is anyone really going to consider that "Go" when it is not blessed by the entity that the vast majority of users consider the keeper of the language spec? How did the Java modifications in Visual J++ go over in the 90s?

Does changing a Word Google Docs document really qualify as open source?

So I make a version of Firefox that supports some new features that Mozilla doesn't support - is anyone really going to consider that "Firefox" when it's not blessed by the entity that the vast majority of users consider the keeper of Firefox? How well did that go over for Debian? (tldr version: Mozilla doesn't like when other people modify Firefox and try to keep calling it 'Firefox'!)

Since Go doesn't satisfy your definition, why don't you provide an example of a language that is 'open source', and specifics of how it differs from Go.

I am not saying that tools/environment are not open source. I am talking about the specification of the language itself. In practice, are there 8 variations of the Java language with significant traction, all calling themselves Java Language Specification 2.1, because people "forked" the language itself? Or are there instead multiple implementations of the JVM because there are both closed and open source variants of the implementation?

The implementation(s) of a a language are more defining than the specifications. Since all Go implementations seem to be open source, I think that calling it an open source language fits well enough.

I think in many cases you are right that there are more concerns about being beholden to closed source implementation of a language than to whether the language itself evolves in an "open" vs. internal/behind closed doors manner.

At the same time, many people have been bitten by languages with open source open implementations whose language specification was nevertheless subject to the whims of single entity, and where language improvements were always "just around the corner". I would argue that forking the tools/runtime/environment implementation on your own to support those improvements is not just a practical scenario in many/most cases.

Quote:

I'd think there'd have to be a notable (or existing at the least) closed source implementation in existence to say otherwise.

I don't even think that closed implementations of the Go environment would make the Go environment any less "open" or "open source" (as I interpret your comments suggest), so long as there were still mainstream open implementations, such as the Google one.

So let's say you want to add a language feature to what everyone considers "Go" syntax - how do you do that?

Do you fork and contribute it back to Google? If so, do you think their metric for accepting a change that modifies the sytax of the language is different than a change that simply improves performance or adds features to standard libraries? I suspect they would evaluate those differently, given the implications for breaking other tools, etc with syntax changes. Maybe I am wrong though.

Or do you fork and just make it your own version of "Go"? If so what is the "Go" language if there are two versions with different synax?

And just to be clear, I am not trying to cut down Go, or argue whether Google is or is not being more or less open than <insert favorite language of mine>. I am just a little surprised that calling the language definition "open source" or "open source code" vs. just the tools and environment that are actually produced with, well code, is so fervently argued.

I would have thought using Go's own terminology ("open source programming environment" vs. language) would be more accepted. And that code openness would be separate from how open or proprietary the language itself is. YMMV

The implementation(s) of a a language are more defining than the specifications.

No. No. A thousand times no. I'll buy that one could have a concept of an open source language. I don't really think that's what was meant in this case (I think it was just sloppiness), but I'll buy that one could at least have such a concept as some other posters have noted.

But I will not buy that the implementations are more defining than the specifications. Specifications are critical. Try to do pretty much any major project (not restricted to computer-related things) without specifications. I don't think I want to fly in your airplane if it didn't get a *LOT* of attention to design specifications instead of just whatever happened to come off the assembly line.

I was editor several revisions of the international standard for a major programming language (I'll avoid side tracks by declining to name it, though it wouldn't take more than a few minutes with google to figure out). The reason I got into work on language standards was because I had seen how important such standards (specifications) are. Sure, specifications can and do have various problems, including internal inconsistencies, requirements that are impractical to implement, and words that don't actually say what the writers meant. I've seen all of those. That's why there are procedures for defect reports.

But I have seen the results of people who ignored the language specifications and just assumed that things would always work the way that they worked in the particular implementations they had used, or even in all implementations available at a particular time. Boy have I seen a lot of that! If I start into examples, I'd have trouble with stopping before I typed a book here.

Yep. A language isn't the same thing as the tools to build programs in that language. Just because there is an open source *SOMETHING* in sight somewhere, that doesn't make everything around open source. A language, as opposed to the tools for the language, doesn't even have source code per se. Probably the closest thing to the "source code" for a language would be the language specification document.

You're free to fork and modify the language as well as the tools. Sounds like open source to me.

I agree with this. Too many spoiled people in this thread not stuck using closed languages. For example, take MATLAB:

Closed source languages really do exist. Take a look at how many years the Octave people have spent reverse engineering MATLAB and you'll see why this matters.

I don't know if this was directed at me as well, but I use MATLAB everyday, sometimes all day And they have a list a mile long of language enhancements I would like to see on their class system (full disclosure, I was once a developer at The MathWorks).

But I think Octave sort of proves my point. You have an undocumented, proprietary, closed language definition. And yet there are open and closed implementations. And there are examples of the somewhat inverse with languages that have committees that pretty much open to membership for language evolution that have only open source, only closed source, or both implementations.

So the nature of the language itself and its evolution are separate from the nature of the implementation(s). If one agrees they are separate, then the question is what do you call the way the language, syntax and features, itself is developed? Since there is no code involved, I find calling it "open source language" a little strange, (especially when people then tell me 'open source' is short for 'open source code') but as I said above I appear to be in the vast, vast minority

Then where is the code in the language specification? The Go license listed earlier is linked to on Go's site as "and code is licensed under a BSD license" (scroll to the bottom of the main page). Great, the code is... open source code - as I think everyone agrees to without qualification. What does that have to do with the language syntax itself and changes to said language?

So let's say you want to add a language feature to what everyone considers "Go" syntax - how do you do that?

Do you fork and contribute it back to Google? If so, do you think their metric for accepting a change that modifies the sytax of the language is different than a change that simply improves performance or adds features to standard libraries? I suspect they would evaluate those differently, given the implications for breaking other tools, etc with syntax changes. Maybe I am wrong though.

Or do you fork and just make it your own version of "Go"? If so what is the "Go" language if there are two versions with different synax?

You send a patch. And of course they'll be more conservative than if it was a minor extension to an edge component. There's far more risk to break things, so more caution will be taken. Just like how the Linux kernel developers are much more cautious with any change that impacts kernel space <-> user space interaction (i.e. changes the ABI) than an optimization to a driver for an obscure piece of hardware.

Then where is the code in the language specification? The Go license listed earlier is linked to on Go's site as "and code is licensed under a BSD license" (scroll to the bottom of the main page). Great, the code is... open source code - as I think everyone agrees to without qualification. What does that have to do with the language syntax itself and changes to said language?

The only implementations of Go right now are open-source, so I think it's safe to say the language is open source. Just because Joe Coder can't change the language doesn't mean the language is not open source. Open source projects can totally change how they work to the detriment of those who use it as well. You can just fork the earlier compilers and maintain your own version of the language if that happens.

Then where is the code in the language specification? The Go license listed earlier is linked to on Go's site as "and code is licensed under a BSD license" (scroll to the bottom of the main page). Great, the code is... open source code - as I think everyone agrees to without qualification. What does that have to do with the language syntax itself and changes to said language?

Then where is the code in the language specification? The Go license listed earlier is linked to on Go's site as "and code is licensed under a BSD license" (scroll to the bottom of the main page). Great, the code is... open source code - as I think everyone agrees to without qualification. What does that have to do with the language syntax itself and changes to said language?

It may be that the way Go evolves is that various people make changes to that document, submit, and Googles looks and says - "Yup, that is a good change to the language, accepted". I suspect they have a clearer vision for the language than that, and are making those decisions via a more structured process and more planning than submit requests for the spec document. But if I am wrong and it is the former, I agree it would pretty much be an "open source" method for defining/evolving the language. I think it would be a first for a major language, but I may be wrong there as well!

As mentioned by other posters, the compiler, debugger etc may be open or closed source --- however, most languages are designed/maintained by standards bodies such as ISO, ECMA etc. As of now, the language spec seems to be only published on google's website and they remain fully in-charge of it's direction instead of a standards body.