Slashdot Mirror

← Back to Stories (view on slashdot.org)

Five Years of the Go Programming Language

Posted by timothy on from the going-strong dept.

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.

15 of 82 comments (clear)

  1. Call the HR department by istartedi · · Score: 5, Funny

    Call HR. The candidates are not liars anymore.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  2. For those interested... by Dimwit · · Score: 4, 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... (The Newsqueak Programming Language)
    http://swtch.com/~rsc/thread/n... (Newsqueak Implementation)
    https://www.usenix.org/legacy/... (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...

    --
    ...but it's being eaten...by some...Linux or something...
    1. Re:For those interested... by TheCarp · · Score: 4, 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.

      --
      "I opened my eyes, and everything went dark again"
    2. Re:For those interested... by Anonymous Coward · · 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 ignored in favor of C, C++, and Java, so seeing some of the original guys that inflicted C on the world finally recognize the brilliance of Oberon it and push it this way has been extremely encouraging.

      I can remember doing concurrent programming in 1985 on my Apple-2 in UCSD Modula-2. I'm kind of surprised Modula-2 hasn't seen a renaissance for use with the little Arduino boards, Modula-2 has language-level support for doing things like interrupt handlers and memory-mapped I/O.

    3. Re:For those interested... by serviscope_minor · · 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....

      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.

      --
      SJW n. One who posts facts.
    4. Re:For those interested... by Dutch+Gun · · Score: 4, 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++.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    5. Re:For those interested... by DuckDodgers · · Score: 2

      I think D is spectacular and I'm sorry it hasn't seen more adoption.

    6. Re:For those interested... by Waffle+Iron · · Score: 3, 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).

    7. Re:For those interested... by Necroman · · Score: 4, 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....

      --
      Its not what it is, its something else.
  3. Burning question by TangoMargarine · · Score: 2

    Do they explain why their mascot is a flying, startled, anthropomorphic burrito?

    --
    Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
  4. Re:So no one has used it yet? by ledow · · Score: 2

    Can anyone name a large (non-Google) project written in Go?

  5. Re:So no one has used it yet? by chuckymonkey · · Score: 4, Informative

    It says right in the summary. Docker is one of them. Here's a few others: Doozer(Heroku) DropBox backend services CloudFlare SoundCloud BBC uses it pretty extensively etc....etc

    --
    "Some books contain the machinery required to create and sustain universes."-Tycho
  6. Language bindings still broken on Mac OS by tlambert · · Score: 2

    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.

    1. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · · Score: 2

      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.

  7. Re:So no one has used it yet? by Ian+Lance+Taylor · · Score: 3, 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... . 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... .