Five Years of the Go Programming Language 82
omar.sahal writes Go celebrates five years of its existence with this blog post recapping a little history, future and some philosophy. "Five years ago we launched the Go project. It seems like only yesterday that we were preparing the initial public release: our website was a lovely shade of yellow, we were calling Go a 'systems language,' and you had to terminate statements with a semicolon and write Makefiles to build your code. We had no idea how Go would be received. Would people share our vision and goals? Would people find Go useful?" The Go programming language has grown to find its own niche in the cloud computing word, having been used to code Docker and the Kubernetes projects. The developers also announced details of further projects to be released, such as a new low-latency garbage collector and support for running Go on mobile devices.
Call the HR department (Score:5, Funny)
Call HR. The candidates are not liars anymore.
Re: (Score:2)
Re: Was ok till I read this: (Score:2)
Rust? No GC with safety.
Re: (Score:2)
Re: (Score:2)
5 years of Go versus 30 years of Common Lisp and 50 years of Lisp. :)
For those interested... (Score:5, Informative)
Go was developed in large part by Rob Pike who has a long history of concucrrency programming going back to Plan 9 from Bell Labs and earlier.
Some of his more interesting papers about concurrency are:
http://swtch.com/~rsc/thread/n... [swtch.com] (The Newsqueak Programming Language)
http://swtch.com/~rsc/thread/n... [swtch.com] (Newsqueak Implementation)
https://www.usenix.org/legacy/... [usenix.org] (A Concurrent Window System)
You can even see some hints of what was to come in his paper outlining the design of the Blit terminal for Unix:
http://doc.cat-v.org/bell_labs... [cat-v.org]
Re:For those interested... (Score:5, Informative)
Interesting. I have been kicking around go on one of my side projects for a while now and I have come to REALLY LIKE the language. I never thought I would be happy to see typed variables again, but now, I like it so much, I get a bit annoyed at languages that don't have typed variables.
It doesn't surprise me that the lead developer has so much history, because the language feels like someone said "Ok what have we learned since C came out" and then reverted all the way back to there and built something new and clean from the lessons learned.
It reminds me a lot of the perl philosophy of "make it easy to do common things", no more fumbling around with memory allocation, it doesn't entirely do it for you, but it provides a very clean interface that makes sense for allocating what you need when you need it.
Re: (Score:3, Informative)
The language itself is basically Oberon, with concurrency from Occam, all with a thin coat of C syntax to make it seem more familiar. The runtime library is very different from Oberon though. And the language is moderately more complicated than Oberon, though maybe not - they added Occam/CSP to the language ,but deleted the wacky and nearly useless bitset support, so it may be a wash in the end.
I'm a big fan of Modula-2 and its successor Oberon and always though it was a major tragedy that they were ignor
Re: (Score:2)
I'm kind of surprised Modula-2 hasn't seen a renaissance for use with the little Arduino boards...
Agreed, a high-level language for embedded systems would be great.
Re:For those interested... (Score:5, Insightful)
From someone who knows little about the Go language (I just read up on Wikipedia a bit just now), could someone fill me in on what particular niche Go fills? Is it essentially a haven for people who dislike C++ (apparently the view of the language authors) but think C is too dangerous / archaic? What does it do that D doesn't, for example. Or maybe it's better to ask what it does better than D?
Also, now that C++ is moving forward much faster with language evolution (C++11/14 have modernized the language significantly with many advanced features), is Go still as relevant as it was five years ago? For instance, you say "no more fumbling around with memory allocation", but that describes my experience with C++ for years now, since smart pointers have been standardized. Then again, in C++, you need to discipline yourself to use the language appropriately, because you can do many awful things that are perfectly legal, language-wise.
Programmers love inventing languages (it's like a rite of passage, I think), but achieving significant and sustained adoption of your new language is always the tricky part. It's not just good enough to be better than language x. You have to provide so much more value that it overcomes existing inertia, which is pretty substantial in the world of C and C++.
Re: (Score:3)
Re: (Score:2)
I think D is spectacular and I'm sorry it hasn't seen more adoption.
I'll second that. It seems to be purely a matter of corporate backing - Go and Rust have received a significant amount of funding from Google and Mozilla, but D hasn't gotten much more than a few conferences sponsored by Facebook.
Re:For those interested... (Score:4, Informative)
Due to the inherent design of C/C++ header files and their "compile units", building any large project in C++ takes almost forever. The work to build grows significantly more than linearly with the number of source files.
Many things in C++ feel very "brittle" largely due to the limitations of its type system and generics.
C++ reference counting is better than fully manual memory management, but still often requires careful attention to "ownership" issues, leaving a risk of leaks or segfaults.
Most recommedations from the experts advise against using most of the actual features of C++ because they are so poorly conceived, poorly supported, or cause safety or compatibility problems. Best to stick with a bare-bones subset that's not very satisfying.
Many of these problems were addressed by languages such as Java and C#. However those both require a heavyweght "virtual machine" runtime. The nice thing about Go is that it creates self-contained executables that run without needing to install anything special on the target machines (at the cost of the executables being larger than most people are used to).
Re:For those interested... (Score:5, Interesting)
Go is a very opinionated language - IE: the language designers decided a lot of things for you, so you just code in the style that they have outlined. This leads to most code following similar styles and patterns. This improves readability of code from other people greatly.
The bar for adding specific features to the language itself is extremely high, so the overall language is simple at its core.
Rob Pike has a good writeup about it from 2 years ago: http://commandcenter.blogspot.... [blogspot.com]
Re: (Score:2)
Quirky syntax - which unlike Perl in places is mandatory in Go! - killed my interest in it pretty early.
Re:For those interested... (Score:5, Interesting)
Go was developed in large part by Rob Pike
Indeed, and I find it surprising. He seems to think that the reason C++ programmers haven't switched over to go is because it's just too awesome and C++ programmers are too stuck in their ways.
http://commandcenter.blogspot.... [blogspot.co.uk]
I do find it disappointing that someone with such an excellent track record would say something so astonishingly ignorant. But I suppose in his mind the cause for not getting C++ programmers must be the fault of C++ programmers, not Go.
Don't get me wrong: Go seems excellent for doing the things it was designed to do, which is having large groups write internet servers of some sort or another. But it is entirely inadequate for all sorts of other application domains.
In the two sorts of things I do, namely deep embedded (the Arduino environment rnus C++) and scientific computing, C++ is pretty much the best language out there. In the first case Go simply cannot do that. In the second case, the lack of generics or good builtin containers for vectors, matrices and images makes Go just plain horrible to use.
Also we C++ programmers have got used to not having to type extra code (like those funny defer lines) or wading through morasses of error checking on the main flow control path.
Re: (Score:2)
The front page makes no mention of embedded software. Instead it talks about "commanding robots" and shows an example of connecting from a linux desktop over a serial cable.
This is not "embedded".
Re: (Score:2)
But if you're talking about something running with 256kb of ram, then Go's current runtime isn't suitable. I've seen new runtime implementations for working with such systems though I don't recall the name of the project or links but there's nothing inherently preventative of Go for use on such systems given an app
Re: (Score:2)
But if you're talking about something running with 256kb of ram, then Go's current runtime isn't suitable. I've seen new runtime implementations for working with such systems though I don't recall the name of the project or links but there's nothing inherently preventative of Go for use on such systems given an appropriate runtime.
256K of RAM is doable. The ATMega's go down to 4K of RAM, which is getting awfully tight. Fundementally, a language relying on GC isn't very suitable for something with that littl
Re: (Score:2)
namely deep embedded (the Arduino environment rnus C++)
You do this for a living? The fact you said "deep embedded" and Arduino in the same sentence kinda made me giggle. With 8-bit AVR's you're probably better off with assembly. With the 32-bit ARM variant, straight ANSI C is probably where it's really at. I really don't know anyone using C++ for microcontroller programming.
"Deep Embedded" would be more like VHDL or CUPL programming.
scientific computing, C++ is pretty much the best language out there.
Yep, that's why there's still so much FORTRAN code getting written.
Re: (Score:2)
You do this for a living?
partly.
The fact you said "deep embedded" and Arduino in the same sentence kinda made me giggle.
An 8 bit integrated MCU pretty much qualifies as deep embedded. An Arduino is just an ATMega on a breakout board with a boot loader. That's no different from an 8 bit MCU soldered to any other board.
With 8-bit AVR's you're probably better off with assembly.
I write ASM on 12F series of PICS. Arduino support C++ just fine, and it's sufficiently useful that there are a group of people keepin
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I am so old, over the hill! So out of it! Completely fell off the wagon when it comes to shiny new things.
I don't even know about monoforphism!
Burning question (Score:3)
Do they explain why their mascot is a flying, startled, anthropomorphic burrito?
Re: Burning question (Score:1)
It is the plan9 logo, re stylized.
Re: (Score:2)
It's cute! So is the Plan 9 mascot.
Fun fact (Score:1)
The Japanese word for 5 is "go".
Re: (Score:1)
And what's fun about that?
Re: (Score:3)
Can anyone name a large (non-Google) project written in Go?
Re:So no one has used it yet? (Score:5, Informative)
Re: (Score:2)
Docker? (http://www.docker.com)
Re: (Score:2)
So that's one, then, from several replies. And pretty much the only project suggested.
Not a great endorsement.
Next question: Could someone have written Docker in other languages just as easily?
Re:So no one has used it yet? (Score:4, Informative)
Docker was the obvious suggestion, since it's right there in the article.
Here is a list of some projects written in Go: http://code.google.com/p/go-wi... [google.com] . A few are Google projects. Most are not.
> Could someone have written Docker in other languages just as easily?
I don't know, you'll have to ask the Docker authors. You could start at http://www.slideshare.net/jpet... [slideshare.net] .
Re: (Score:2)
and the list goes on and on with startups (http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html) and big names (https://github
Re: (Score:2)
Re: (Score:2)
8 years Go experience required... (Score:1)
Must be able to coordinate efforts with multiple teams in self-directed manner.
8 years with one or more of the following languages: Go, Swift, Dart, Erlang
Be able to explain the most influential sorting algorithms in your life.
Language bindings still broken on Mac OS (Score:3)
Language bindings still broken on Mac OS.
It's not that surprising, since they implement their own system call stubs, rather than linking the Go runtime against the system C language bindings.
The definition of the system call boundary on Mac OS X is "at the top of libSystem", *NOT* at the user/kernel boundary.
As a consequence, the language bindings used by Go omit information and parameters needed by the actual system calls.
For example, the "kill" system call on Mac OS X takes 3 parameters, while the "kill" libSystem routine is POSIX compliant, and takes two parameters. The third parameter is used to provide a behavioural hint to the OS as to whether you want traditional Mac OS X behaviour, or whether you want strict POSIX behaviour. One of these places is where a signal is sent to a process group of which the sender is a member (done by using a negative PID to indicate via the sign bit that the PID is actually a PGROUP).
What that means is that whatever the hell happens to be in the third parameter register determines whether sending a kill to your own PGROUP also sends the kill to yourself (POSIX) or you sit around on your thumb waiting for a kill that's never going to come, because you wrote to the POSIX behaviour, but selected the traditional Mac OS X behaviour instead.
There are about 40 of these "gotcha's" in the Go use of direct system call bindings that the Go developers failed to take into account on Mac OS X; I can only believe that there are similar issues on other platforms (mostly because I know of two of those issues on BSD platforms).
It's pretty much a given that composite APIS that use descriptors to avoid changing the user visible implementation underlying the upper level code (based on a contract change between the C library and the kernel, without a contract change between the C library and the application) also fall into that category. This includes most of the pthread_attr_t using/providing APIs, posix_spawn, POSIX semaphores, and so on.
I have a great deal of respect for Rob Pike as a language designer, but I have to say, the way language bindings have been handled in Go is pretty abysmal.
Re: (Score:2)
Please file bug reports at http://golang.org/issue [golang.org] .
Several of the main Go developers use Mac OS X every day, so it can't be that bad.
Re: (Score:2)
Several developers in the world work around bugs each day, so they can't be that bad.
If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.
Re: (Score:2)
Several developers in the world work around bugs each day, so they can't be that bad.
If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.
I'm sorry, you have misunderstood. Some of the main Go developers work on Mac OS without any trouble. They aren't working around anything. They are just using the language.
I don't know what problems tlambert is encountering, and I hope that he or she will be willing to report them to the issue tracker so that they can be fixed.
Re: (Score:2)
Several developers in the world work around bugs each day, so they can't be that bad.
If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.
I'm sorry, you have misunderstood. Some of the main Go developers work on Mac OS without any trouble. They aren't working around anything. They are just using the language.
I don't know what problems tlambert is encountering, and I hope that he or she will be willing to report them to the issue tracker so that they can be fixed.
Hi Ian.
When I was working at Google, I walked over and talked to the developers in person.
They didn't see it as a big problem, and preferred to be able to do static linking, which Apple (where I worked prior to working for Google) prefers you don't do (prefer as in intentionally make it impossible by leaving the necessary bits out of their development tools). It was more or less "irreconcilable difference" territory, even when I offered to do all the necessary dyld/dyle glue code for them (I wrote the kern
Re: (Score:3)
When I was working at Google, I walked over and talked to the developers in person.
They didn't see it as a big problem, and preferred to be able to do static linking, which Apple (where I worked prior to working for Google) prefers you don't do (prefer as in intentionally make it impossible by leaving the necessary bits out of their development tools). It was more or less "irreconcilable difference" territory, even when I offered to do all the necessary dyld/dyle glue code for them (I wrote the kernel exec code on Mac OS X, so I am very familiar with the C runtime code up in user space).
This is a case of a problem they are were unwilling to fix at the time; they may be willing now, but find themselves unable (the code for the runtime interaction with the dynamic binding required for libSystem for a new language binding is pretty dense).
The bottom line is that it's practically useless for the kind of user space code I'd like to be able to write with the language.
I'm on the Go team myself.
You are of course correct that Go has chosen to make system calls directly, in a way that Mac OS X explicitly does not support. But there is a difference between "not supported" and "not working." What I'm wondering about is when Go's approach causes actual problems, rather than theoretical ones. You cited specific problems in your original post above. Please file issues for the actual problems, so that we can fix them. Thanks.
Re: (Score:2)
I'm on the Go team myself.
You are of course correct that Go has chosen to make system calls directly, in a way that Mac OS X explicitly does not support. But there is a difference between "not supported" and "not working." What I'm wondering about is when Go's approach causes actual problems, rather than theoretical ones. You cited specific problems in your original post above. Please file issues for the actual problems, so that we can fix them. Thanks.
I'll consider filing bug reports for them, although I feel that it's probably more of a job for a QA person being paid by Google to do the work, rather than my job, seeing as I am not currently with Google. At present, none of the projects where I had considered using Go have used Go because of these deficiencies, so I have no real incentive to do the legwork for free, if it's going to take me away from other work.
Here's a partial list of interfaces that are implemented in the Libc portion of Libsystem, ra
Re: (Score:2)
Since you worked at Google, you know of course that the Go team is a small team working on a free software project. There are no paid QA people.
Thanks for the list of system calls. It's hard to associate that back to Go. As you know the Go library is not the C library. There is no support in Go for direct calls to functions like posix_spawn, pthread_create, pthread_mutex_lock, etc. These make no sense in the Go context. Go has its own facilities that provide similar functionality. Similarly for signa
What really does it bring to the table? (Score:2)
On the client side, we really need a bytecode standard that will allow developers to choose from multiple language "frontends". That would take the major browser makers coming together on this like they did for HTML5.
On the backend, we have dozens of VMs to choose from. What does Go bring that Java and JVM target languages, Ruby, Python, etc does not already give us?
Re: (Score:2)
- It's faster than Python and, I suppose, Ruby.
- It has a faster executable startup time than Java and other languages that depend on the clunky JVM.
- It's not as OO-perverted as Java, or at least, allows you to write your OO-perverted code with less keystrokes than Java.
- It has many features that the Algol68 language has, too.
- It lacks many features that Common Lisp has and will never have them. (Whether you think that's good or not, depends a bit on the length of your beard and weather you primarily liv
Re: (Score:2)
Its somewhat easier to learn and use than Forth,
i don't think so. in forth the awkward syntax actually accounts for a different paradigm. in go it just seems whimsical (speaking as someone who just did some go tuts, i find it has actually some pretty cool features ... i'd like to use in c!)
Re: (Score:2)
There's Go! [wikipedia.org] and there's Go [wikipedia.org]
Seems pretty obvious to me :P.
Re: (Score:1)