This has been one of my frustrations (with a language I otherwise love). If you fail to update for a couple of months and then come back your code is broken. I understand and support why they chose to do it this way though.
I think it's pretty neat that they have a tool (gofix) that can walk your code and rewrite it so it works with changes. This is possible in many languages, but it's pretty impressive for one so young to have it. I guess anything that makes it easier for them to make reasonable changes is good for the language long-term.
I work on Go, and just used gofix to update all the Go code at Google. It was just a few command lines to update many, many files. Gofix will make updating much less painful (for me, it already has).
I agree that it's an issue, however it is nice that they aren't simply going to sit on mistakes that need breaking changes to fix. In some respects it's another aspect of the 'beta' culture at google, which is IMHO a good thing - open it up to public use then fix as you go before switching to a stable model.
maybe but still far away from making any real impact in terms of popularity. maybe Google can take out Java (or Delvik) from Android development and replace with Go. Well, even if they try now it will take a long long while. So realistically I don't see how Go has any future. Google can but some how Google is bad in marketing it's own stuff.
Languages don't reach mainstream popularity overnight. Go has been public for one year. Look at where Java, Python, or even C++ were a year after their release. With that in mind, I think Go is doing pretty well.
An important thing to note is that, while Go is a great general purpose language, we're building it to make systems development easier. That's what we're using it for at Google, and also how it's being used at other companies like Canonical and Atlassian. In that sense Go is already successful.
As one of the folks who was on the Java team when it was released to the public, I can tell you the response was very different than the response to Go's announcement.
Having been at Google (but not associated with Go in any way while there) when Go was announced my question then, as now, was "What was the problem again?"
The basis of that question is that languages that have been successful often, but not always, have a strong correlation with solving a painful problem.
Java solved a number of problems; the problem of connecting across architectures (I thought of it as the 'system libraries' problem), the C++ is too complicated problem (which would be the too complex;didn't learn (tc;dl) problem), and the interactive content from an untrusted source problem (which, in all fairness was a problem it self created when being able to run in a browser).
The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem (which is huge, but why ignore millions of man hours in HDLs which also solve this problem but with the caveat that you have to be able to infer hardware from the compiled code)
So unless there is something that is much easier to do in Go that you both need to do, and is so much better that doing it in your current language is too painful, it will join the ranks of languages like Lisp, APL, Modula-n, and Eiffel which all have things to recommend them but nothing to compel them into wide spread adoption and use that we associate with a 'popular' language.
"An important thing to note is that, while Go is a great general purpose language, we're building it to make systems development easier. That's what we're using it for at Google, and also how it's being used at other companies like Canonical and Atlassian."
Historical reference see the design, development, and use of the best language you've never used Mesa [1].
My interest in Go stems from its potential to replace C as a systems programming language. Basically, it seems like everything that has been tried for improving upon C has failed. However this is not because C doesn't have problems, rather it's because every replacement has been trying to achieve other things at the same time and has introduced complexities that made things worse.
So I think it's interesting to have a language that is finally being built with the primary purpose of being better than C at systems programming. My main issue however is the lack of support for Windows. One of the main points of a system language and the reason C dominates is that with enough hacks you can make it portable to anywhere. I can understand the Go folks probably don't have much interest in or use for Windows (or resources to support a port) but honestly, in my mind that's just incompatible with the stated goal of being a "systems programming language".
There is a small group of dedicated programmers working on the Windows port, and it works. Not 100% parity with the other Operating Systems, but it passes most tests: http://godashboard.appspot.com/ (see the rightmost column)
"The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem"
That's only a small part of it. It's also designed to be less confusing than C++, and more flexible and faster than Java. As a result, it's actually a very different kind of language. Feels like a scripting language, but you get static typing and the performance of a compiled language.
Lots of smart programmers are finding good use for Go, so your comments seem like unnecessary and misplaced negativity to me.
> Feels like a scripting language, but you get static typing and the performance of a compiled language.
Exactly. I'm a longtime enthusiastic Python programmer and reluctant C++ programmer, and for me Go is the first language that could realistically replace both Python and C++ for my programming.
For me the killer features of Go are:
- Go code is almost as compact as Python but--especially for numeric code--much, much faster.
- You never have to wait for the compiler! Everything I've written compiles and links in a fraction of a second.
Note too that, apart from the C runtime and low-level OS interfacing stuff, the entire Go standard library is written in Go itself. Contrast this w/ "scripting"/dynamic languages like Python or Ruby where much of the standard library has to be written in C for performance.
Go isn't the only language that matches those requirements though. I took a long hard look at Go for very similar reasons and ended up deciding on Scala.
It feels like a scripting language, incredible performance, extremely compact code when you need it to be, actors.
>Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code.
I actually disagree with this, CSP style, actors, message passing, you still have potential race conditions and deadlocks. What you gain is a nice separation between what is shared and what isn't. Just don't think Go's concurrency is the many-core silver bullet anymore than locks or Tx Memory is...
Java solved a number of problems, but introduced some of its own.
The work I do in C++ I could do in Java, but the extra memory and compute overhead would cost us on the order of another engineer. Go interests me because it might let me escape C++ without the cost of Java. (Go may still prove too expensive, my experiments aren't done yet.)
Also: Go developers have the Python ethos of short names and simple interfaces. Take a look at the Go standard library[1]. I may get the safety of Java and the productivity of Python in one go.
The fact that it was created by a big rich company makes all the difference. Seriously. Companies commit themselves to development projects in hideous proprietary languages like ABAP without a second thought, but a well-regarded language with multiple high-quality implementations can be a difficult sell if it comes without a ™ and a corporate logo.
Go does solve some painful problems for certain communities, esp. the linux desktop folks. Java hasn't caught on writing linux desktop apps, probably because of memory requirements and there are mixed feelings about Mono. Python is just too darn slow for such apps. I imagine this is why Canonical is using Go. Admittedly this isn't a huge space.
I work at Google, but let's be honest: Java and C++ continue to be the only game in town for existing and new projects, Go occupies only a very tiny niche in our code base, mostly for the reasons that Chuck mentioned: a lot of the parallelism value that Go claims is already widely available, battle tested and very robust in Java and C++.
The parallelism features of Go are a side-effect of the concurrency features, which are far more about how you structure your code than about how it runs.
Go's main feature is what it removes. I got stuck with C for a long time because nothing better with the same simplicity came along.
Languages march forward with increasing complexity while offering very little in return for it. Go is a reaction to that and a solution to that problem.
From my understanding, Go doesn't make things possible that are not available in Java/C++, but it attempts to make them easier and less error-prone.
The big problem with parallel/concurrent/distributed programming is that it is very hard to do both correctly and efficiently and scalable with current languages (and at the same time, keep the code maintainable). It has been bolted on, so to say, in may different ways. OpenMP, OpenCL, IPP, the list goes on. All those abstractions serve a certain purpose, and are useful at a certain scale, but are less useful outside of that, and generally you need to worry about way too many low-level details.
OpenMP: loops are easily parallelized, but due to data sharing, writing code that scaled to a large number of cores is very hard. Supports some other primitives like task parallelism, but in a limited way. At least you don't need to manage threads manually.
OpenCL: designed for huge numbers of cores, but very much focused on GPU-based development, makes it very inflexible on general purpose CPUs.
IPP: Work queue primitives to automatically distribute load over multiple cores. This is the most advanced approach, but fits very clumsily into C++ using arcane template syntax, which quickly results in macaroni code.
A language that would truly support scalable high-performance parallelization without having callbacks all over the place would be great. I'm not sure how far Go delivers on this promise, but it's certainly a step in the right direction. Which is expected from a company like Google, which understands these problems.
my friend, I am not anti Google or anti Go. 1 year in tech is like 10 years in real life. I am glad you mention "systems development" but Google is marketing or at least the Go lang site is marketing it as a mainstream application development language. The repeated thing I hear and see is Go is fast and simple, which I don't disagree. If it is so simple and fast why is this not even listed in any of the rankings at http://langpop.com/
Before java was even officially released colleges were teaching Java classes. I remember it, cause I took the class and I still have the book that says covers beta. That's how popular java was. We were wowed by animations (feels funny to think about it now) and how easy it was to write screen savers, moving robots and shooting games. This is not the 90s. Look at the success of Android development (different topic). It came from freakN no where wowed everybody. Made stupid HTC (who knew about it before Android) a huge competitor of Apple. We are wowed not by what a programming language can do (this is what we are getting from Google) but by it's demo implementation. Again, look at Android, App Inventor and google has tons of such examples. Go marketing team (if there is one) failed miserably in my opinion.
Go is mainly meant to be used for systems development not application development. It's audience is developers who currently use C/C++ rather than mobile developers coding in Java.
Why couldn't it replace Java? From reading about it and my limited use of it I get the impression that it's meant to be able to replace C or C++ but it's also meant to be used to write applications as a replacement for a language like Java. The libraries and API stability are lacking, but I don't see any language issues that would make it a bad application language.
I'd say that you should take your time with interop, and practice isolationism for as long as possible. I don't mind waiting for Go to evolve naturally.
Java still has a few killer features that Go doesn't. Primarily, running in a VM and "interpreting" byte code means you can ship a single binary to every platform. Go requires you to compile a separate executable for every platform.
Having to run in a VM is also seen as a drawback by some people, including me. The VM startup time makes using command line tools written in Java painful and Java apps often feel awkward on every platform since they don't use any platform specific features. So even though having a single binary work across all platforms is a killer feature for some people it's yet another disadvantage of java for others.
Despite that being its stated purpose it is an excellent general purpose programming language; GC, 'true' interfaces, i.e. interfaces that are implemented simply by a type having a function set which matches a specified interface, and a lot more - it's simple, clean and obviously has a great future ahead of it.
There's no reason to label go as simply a systems programming language in the same way you can't just label python or ruby scripting languages.
If you talk to people in the Go community you'll see that they interpret "systems programming" to mean both OS-level development and applications-level development.
Users interact with applications, things a user doesn't directly interact with are systems. Where you draw the line is really dependent on what you're doing.
Someone recently described academia as 'Java vocational training'[1].
I'd expect Go to replace Java in the academic context relatively quickly, which should precipitate a shift in business' center of gravity over time. I already suggest Go to people who are serious about learning.
Why would you expect go to replace java in an academic setting? Java is only partly taught due to introductory simplicity and mostly taught due to it ubiquity.
Personally, I'd be surprised if Go replaced Java in academic contexts. Java has inertia, marketability, better cross-platform support, and bundled GUI stuff.
That said, were I teaching a general programming and/or data structures course, I'd probably strongly consider using Go. It is possible and not unreasonable for students to read and understand the whole Go spec. The language is simple and orthogonal enough that I think students could start seeing past the language and to the tasks at hand rather quickly.
If Go compiles to ARM, there's no reason it couldn't run on Android. Check out the Android NDK; all you need to port is the Java Native Interface. After that, it should be almost as easy as dropping in the next version of GCC, which will support Go.
It's not a full replacement for Java, as most of the APIs are currently inaccessible via the NDK. But it's getting there.
It does :) though it's early days with the arm side of things. I'd be surprised if google don't work on specifically making it easy to code in go for NaCl and android.
So you're saying that the guys behind C, Unix and Plan9 have nothing to contribute to advancing the field of programming languages?
Comments like this bug me. Sure, some languages aren't terribly different from others, but there's always something new and valuable to be learned from a programming language, even if it's what not to do. At this point in my career, I can switch between languages almost seamlessly. Sure, you spend some time on syntax, but once you understand the concepts behind a language, you're running.
And with Google Go specifically, they're incorporating good ideas that aren't making it to existing languages. The Java guys can't agree on how to do closures, or even if they're a good idea, and the changes to C++ are making it more baroque. It's like they're having a contest to see how many meanings they can have for the const keyword.
I'm excited to see a new language designed by smart people with great track records, incorporating lots of cool new ideas, and from an organization powerful enough to make sure it's done right and supported long term. Is that not good enough for you?
