Five Years of the Go Programming Language

← Back to Stories (view on slashdot.org)

Five Years of the Go Programming Language

Posted by timothy on Thursday November 13, 2014 @03:28AM 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.

82 comments

Min score:

Reason:

Sort:

Call the HR department by istartedi · 2014-11-13 03:32 · 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"?
1. Re:Call the HR department by __aaclcg7560 · 2014-11-13 04:43 · Score: 1
  
  HR will change the requirements from five years to ten years of experience in Go programming.
2. Re:Call the HR department by aaaaaaargh! · 2014-11-13 06:15 · Score: 1
  
  5 years of Go versus 30 years of Common Lisp and 50 years of Lisp. :)
3. Re:Call the HR department by Anonymous Coward · 2014-11-14 09:26 · Score: 0
  
  And Go already has more users.
4. Re:Call the HR department by Anonymous Coward · 2014-11-21 05:49 · Score: 0
  
  Not likely, unless you are only counting end-language end-users and not actual programmers.
For those interested... by Dimwit · 2014-11-13 03:35 · 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 · 2014-11-13 04:00 · 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 ThePhilips · 2014-11-13 04:05 · Score: 1
  
  Quirky syntax - which unlike Perl in places is mandatory in Go! - killed my interest in it pretty early.
  
  --
  All hope abandon ye who enter here.
3. Re:For those interested... by Anonymous Coward · 2014-11-13 04:19 · 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.
4. Re:For those interested... by serviscope_minor · 2014-11-13 04:29 · 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.
5. Re:For those interested... by Dutch+Gun · 2014-11-13 04:35 · 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.
6. Re:For those interested... by Anonymous Coward · 2014-11-13 05:02 · Score: 0
  
  Most of that was just Bell Labs versions of ground breaking ideas developed elsewhere.
  And graphics programming, concurrent programming, parallel programming, and high-level languages developed almost completely independently of Pike's work, and arguably languages like Newsqueak just got a lot of things wrong.
7. Re:For those interested... by Anonymous Coward · 2014-11-13 05:30 · Score: 0
  
  As a C++ developer, I say pull the other one.
8. Re:For those interested... by DuckDodgers · 2014-11-13 05:58 · Score: 2
  
  I think D is spectacular and I'm sorry it hasn't seen more adoption.
9. Re:For those interested... by Anonymous Coward · 2014-11-13 06:32 · Score: 0
  
  ... deep embedded (the Arduino environment rnus C++) ... In the first case Go simply cannot do that ...
  Have you seen this? http://gobot.io/
10. Re:For those interested... by interval1066 · 2014-11-13 06:45 · Score: 1
  
  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.
  
  --
  Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
11. Re:For those interested... by Anonymous Coward · 2014-11-13 06:52 · Score: 0
  
  Very fast compile times.
  Static binaries.
  Cross platform.
  Write the code on my macbook, compile it on linux, run it on android.
  A joy to program in, I really like the idioms.
  Concurrency solves problems I have today with simple to implement idioms, while the parallel thread jockey model of c++ is mental gymnastics that I would prefer to avoid.
12. Re:For those interested... by Waffle+Iron · 2014-11-13 07:38 · 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).
13. Re:For those interested... by Anonymous Coward · 2014-11-13 07:49 · Score: 0
  
  So simplicity has value as you've stated, so you don't have "help" doing bad code practices.
  For D vs Go, Go's strength is that it's Asynchronous-first.
  Asynchronicity has been NodeJS's biggest advantage, and Go bringing that
  - with fast compilation,
  - C++ integration, and
  - a simpler form of asynchronous development.
  And the value of asynchronous-first languages is huge because you can expect (but verify) all their libraries to offer the same performance.
14. Re:For those interested... by CurryCamel · 2014-11-13 08:18 · Score: 1
  
  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".
15. Re:For those interested... by Necroman · 2014-11-13 09:51 · 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.
16. Re:For those interested... by ogdenk · 2014-11-13 10:43 · Score: 1
  
  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.
17. Re:For those interested... by dasacc22 · 2014-11-13 12:14 · Score: 1
  
  The OP mentioned Arduino. The front page provides an arduino sample and further down demonstrates uploading the firmware. This works with the beefier platforms. See also http://embd.kidoman.io/
  
  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.
18. Re:For those interested... by Anonymous Coward · 2014-11-13 14:48 · Score: 0
  
  D adds modern high-level language features to C++ to try and tidy it up.
  Go adds modern high-level language features to C so that you have a simple language you can use without having to learn C++ or D.
  It was created so that Pike et al. could do concurrent C like programming in a server environment. Continuing ideas they developed using Alef and Limbo in the distributed environments of Plan 9 and Inferno. With its simplicity it is fine as a high-level general purpose language and the compiled speed and concurrency make it useful for stuff on a server.
  What it lacks, like most new languages, is enough popularity to develop a lot of features or replace the base of knowledge and code for well established languages like C++, Java, Python, Javascript, Objective C/Swift, C# etc.
19. Re:For those interested... by Anonymous Coward · 2014-11-13 15:39 · Score: 0
  
  That isn't what Pike said.
  He said that C++ users aren't interested in Go because C++ offers a highly standardised and optimised language based around things like inheritance and types. Whereas Go has a different philosophy of making things simple so that compiling is fast, coding is fun and your code is readable and reliable. Pike believes that this will mean it scales better for large scale projects, but no one is building any large projects with it so we'll never know. He said Go it appeals to Python and Ruby programmers though because it's a philosophy they are used to and offers better performance and concurrency.
  Personally I think it more a case of if you have learnt to do stuff in C++ why would you want to spend time learning something else that is slower, not as well developed or featured and not proven for what you want to do. Established languages have advantages.
20. Re:For those interested... by serviscope_minor · 2014-11-14 00:49 · Score: 1
  
  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 keeping GCC up to date on them. I would much rather write complex control software in C++ and drop to ASM only whe nI have to than write the whole lot in ASM.
  With the 32-bit ARM variant, straight ANSI C is probably where it's really at.
  Or C++ because it uses precisely as many resources (sometimes even fewer!) is every bit as fast (idiomatic C++ is often faster!) and is far more expressive.
  I really don't know anyone using C++ for microcontroller programming.
  Whether you liek Arduinos or not, they are microtcontrollers and you've just ignored a large number of microcontroller programmers. It might not be the "proper" (only true Scotsmen program microcontrollers, amirite) thing you're used to but it's a large community and doig a lot of stuff.
  "Deep Embedded" would be more like VHDL or CUPL programming.
  Nope, that's FPGA or even custom silicon stuff. A tiny micro hidden on a board somewhere is deep embedded.
  Yep, that's why there's still so much FORTRAN code getting written.
  Turns out the OTHER thing I do for a living is scientific computing. It's split. FORTRAN is a bit faster, C++ is more flexible. I've never met a single image processing or computer vision person who uses C++. The last supercomputer group I worked wit htended to prefer C++ unless they were porting old FORTRAN codes.
  C++ is way more expressive than FORTRAN and it makes it a better language for general scientific programming, unless you need the absolute top performance.
  
  --
  SJW n. One who posts facts.
21. Re:For those interested... by serviscope_minor · 2014-11-14 01:00 · Score: 1
  
  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 little RAM. C++ works because you can use a mix of static and stack allocation.
  
  --
  SJW n. One who posts facts.
22. Re:For those interested... by Anonymous Coward · 2014-11-14 06:47 · Score: 0
  
  How do you feel about the module proposal for C++17?
23. Re:For those interested... by rdnetto · 2014-11-15 03:51 · Score: 1
  
  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.
  
  --
  Most human behaviour can be explained in terms of identity.
24. Re:For those interested... by Anonymous Coward · 2014-11-20 14:51 · Score: 0
  
  D is terrific.
  Its libs and ecosystem is a dumpster fire though.
25. Re:For those interested... by Anonymous Coward · 2014-11-21 07:27 · Score: 0
  
  Are you high?
  It is much easier to write complex mathematical functions in Fortran than C++ will ever be.
  C++ expressive?
  Lay off the crack.
Parametric polyforphism by Anonymous Coward · 2014-11-13 03:40 · Score: 0

I will care about Go when they get it.
1. Re:Parametric polyforphism by interval1066 · 2014-11-13 07:29 · Score: 0
  
  I smell a Haskell programmer in the room. Quick, get a net!
  
  --
  Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
2. Re:Parametric polyforphism by fisted · 2014-11-13 08:29 · Score: 1
  
  polyforphism? seriously?
  
  --
  CLI paste? paste.pr0.tips!
3. Re:Parametric polyforphism by darenw · 2014-11-14 10:41 · Score: 1
  
  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 by TangoMargarine · 2014-11-13 03:41 · 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
1. Re: Burning question by Anonymous Coward · 2014-11-13 03:48 · Score: 1
  
  It is the plan9 logo, re stylized.
2. Re:Burning question by Anonymous Coward · 2014-11-13 03:51 · Score: 0
  
  That is supposed to be a gopher.
3. Re:Burning question by Rinikusu · 2014-11-13 04:35 · Score: 1
  
  It's cute! So is the Plan 9 mascot.
  
  --
  If you were me, you'd be good lookin'. - six string samurai
4. Re: Burning question by Anonymous Coward · 2014-11-13 09:16 · Score: 0
  
  The gopher is a spin-off character by Renee French, who also drew Glenda the Plan 9 mascot.
Fun fact by Anonymous Coward · 2014-11-13 03:46 · Score: 1

The Japanese word for 5 is "go".
1. Re:Fun fact by Anonymous Coward · 2014-11-13 06:18 · Score: 1
  
  And what's fun about that?
So no one has used it yet? by Anonymous Coward · 2014-11-13 04:03 · Score: 0

I'd totally forgotten about it. Has anyone ever gotten paid to write code in Go?
1. Re:So no one has used it yet? by ledow · 2014-11-13 04:06 · Score: 2
  
  Can anyone name a large (non-Google) project written in Go?
2. Re:So no one has used it yet? by Anonymous Coward · 2014-11-13 04:12 · Score: 0
  
  Docker is the first thing that comes to mind.
3. Re:So no one has used it yet? by chuckymonkey · 2014-11-13 04:15 · 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
4. Re:So no one has used it yet? by Anonymous Coward · 2014-11-13 04:26 · Score: 0
  
  Docker and LXD are being written in GO ..
5. Re: So no one has used it yet? by Anonymous Coward · 2014-11-13 04:31 · Score: 0
  
  Btcd by conformal https://github.com/conformal/btcd is a huge project wrote in go. In an almost feature completed alternative full node in go.
6. Re: So no one has used it yet? by LeadSongDog · 2014-11-13 04:55 · Score: 1
  
  What's that in English?
  
  --
  Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
7. Re:So no one has used it yet? by Ian+Lance+Taylor · 2014-11-13 05:04 · Score: 1
  
  Docker? (http://www.docker.com)
8. Re:So no one has used it yet? by ledow · 2014-11-13 05:06 · Score: 1
  
  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?
9. Re:So no one has used it yet? by Ian+Lance+Taylor · 2014-11-13 05:54 · 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... .
10. Re:So no one has used it yet? by dasacc22 · 2014-11-13 06:45 · Score: 1
  There's so many
  
  stackoverflow https://github.com/bosun-monit...
  ex-googlers https://github.com/cockroachdb...
  like bittorrent sync https://github.com/syncthing/s...
  drone.io CI https://github.com/drone/drone
  raft protocol implement https://github.com/goraft/raft which is used in a number of other projects such as the underlying projects in CoreOS (also written in Go)
  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.com/dropbox/godropbox https://github.com/facebookgo) alike. Just google for more or explore github.
11. Re:So no one has used it yet? by interval1066 · 2014-11-13 07:37 · Score: 1
  
  Tons. I don't really need to trot out some project names for you, do I? But what I can point to: do google search on variations of "google code", "google projects", "google api", search for various apis on github, and you may be startled by the number of those projects that are written, some times in part but often whoally, in C++.
  
  --
  Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
12. Re:So no one has used it yet? by Anonymous Coward · 2014-11-17 01:22 · Score: 0
  
  > Next question: Could someone have written Docker in other languages just as easily?
  Regarding the new question, that I feel is very different from the earlier question, most applications could have been written in almost any language. What a lot of Go proponents say is that is usually easier to write a large system in Go than in C++, except in some special cases. They seems to use it inside Google more and more since they have some experiencess which probably says that this is true in their cases.
8 years Go experience required... by AnontheDestroyer · 2014-11-13 04:06 · Score: 0

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.
1. Re:8 years Go experience required... by Anonymous Coward · 2014-11-13 04:17 · Score: 0
  
  I'm guessing you're naming languages that haven't been around for 8 years yet, so, you do know that Erlang is much older than 8 years old, right? I think it goes back to the mid 80s.
2. Re:8 years Go experience required... by Anonymous Coward · 2014-11-13 05:08 · Score: 0
  
  I'm guessing you're naming languages that haven't been around for 8 years yet, so, you do know that Erlang is much older than 8 years old, right? I think it goes back to the mid 80s.
  I am certain Anonymous knows Erlang is over 8 years old but the other languages are much younger. In a job advertisement only an Indian could possibly have this combination of languages and 8 years of experience with each of them.
3. Re:8 years Go experience required... by Anonymous Coward · 2014-11-13 05:31 · Score: 0
  
  But the original post said "one or more"
Language bindings still broken on Mac OS by tlambert · 2014-11-13 05:07 · 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 · 2014-11-13 08:14 · Score: 1
  
  Please file bug reports at http://golang.org/issue .
  Several of the main Go developers use Mac OS X every day, so it can't be that bad.
2. Re:Language bindings still broken on Mac OS by frank_adrian314159 · 2014-11-13 09:33 · Score: 1
  
  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.
  
  --
  That is all.
3. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · 2014-11-13 09:39 · Score: 1
  
  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.
4. Re:Language bindings still broken on Mac OS by tlambert · 2014-11-13 09:59 · Score: 1
  
  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 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.
5. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · 2014-11-13 13:34 · 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.
6. Re:Language bindings still broken on Mac OS by tlambert · 2014-11-13 18:05 · Score: 1
  
  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, rather than directly as system calls, and are therefore unavailable to call from Go:
  bsd_signal, confstr, creat, crypt, encrypt, ftw, gethostid, gettimeofday, getwd, killpg, nftw, semctl, setpgrp, setregid, setreuid, shmctl, sigsetmask, sigblock, sigpause, sighold, sigrelse, sigignore, statvfs, tcgetsid, uname, utmpx
  etc., including all 32 POSIX1e ACL related commands, almost all pty related code, much of termios.
  Here's a partial list of system calls which use an additional parameter/error checking/descriptors at the user/kernel boundary, and therefore randomly exhibit POSIX non-compliant behaviour when called from Go programs:
  posix_spawn, posix_spawnp, pthread_create, pthread_mutex_lock, pthread_mutex_unlock, fork, kill, sigaction, sigvec, etc. ...like I said, a job for a QA person to identify them all.
  Ideally, what would happen, is that The Open Group VSU, VSX, VSTH, and VSRT tests, at a minimum, would be converted to Go, and verified that they get the same results as their C language counterparts when run against any UNIX or UNIX-like platform. Barring that (due to licensing expense), the Open Source LSB-FHS, LSB-VSX, and LSB-OS tests would be used instead.
7. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · 2014-11-14 04:00 · Score: 1
  
  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 signal handling, process control, etc. Any programs that call the functions you list have to use C, not Go, on any platform--and Go supports calling C functions in Darwin, and those C functions will use the usual library interface.
  So it's still not clear to me that there is an actual problem.
What really does it bring to the table? by kervin · 2014-11-13 05:50 · Score: 1

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?
1. Re:What really does it bring to the table? by aaaaaaargh! · 2014-11-13 06:31 · Score: 1
  
  - 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 live off coke and chinese food and pizza or not.)
  - It has built-in concurrency like Ada has, only that it is much less safe than Ada and also much slower.
  - It is slower than C and Fortran, so if you do number crunching it will give you an additional coffee break.
  - It provides endless opportunities and fun with fiddling around with glue code for interfacing to C and C++ libraries - like all new language!
  - Its somewhat easier to learn and use than Forth, but less easier to use than Python (which is good, because we don't want it to be too easy now, do we)
  Please notice that I'm not in any way affiliated with Google, so this not some hidden advertising/slashvertisement.
2. Re:What really does it bring to the table? by znrt · 2014-11-13 10:33 · Score: 1
  
  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!)
3. Re:What really does it bring to the table? by Anonymous Coward · 2014-11-21 08:40 · Score: 0
  
  1. So what if it is faster? Rarely is execution speed an issue
  2. People care about startup time?
  3. Java isn't really OO. It claims to be but misses the point of OO entirely. See Smalltalk or Ruby for proper OO implementations.
  4. and?
  5. Derp If a language is not a lisp, it lacks features that lisp has or can be easily added to the language.
  6. Ada blows
  7. Again, unless you need to squeeze out as much in as little time, who cares? If your program has to wait for IO and spends most of its time waiting, execution speed is rarely a problem.
  8. And that is different from Ruby, Python, Ocaml, etc?
  9. Python is the Java of dynamic languages. It can sort of do dynamic things, but you have to use rigid constructs or use a ton of boilerplate that languages like Ruby give you for free.
  10. I noticed you are an idiot. Thanks.
Isn't Go 11 years old? by Anonymous Coward · 2014-11-13 06:46 · Score: 0

Go was created in 2003, which by my reckoning, means it's 11 years old.
Am I in some kind of a time warp here?
http://en.wikipedia.org/wiki/Go!_(programming_language)
1. Re:Isn't Go 11 years old? by jfbilodeau · 2014-11-13 08:17 · Score: 1
  
  There's Go! and there's Go
  Seems pretty obvious to me :P.
  
  --
  Goodbye Slashdot. You've changed.
2. Re:Isn't Go 11 years old? by Anonymous Coward · 2014-11-13 09:42 · Score: 0
  
  For the love of programming, free software and video games: Chronogears.com [chronogears.com]
  Nice blank page there. Maybe you should update to a working URL.
3. Re:Isn't Go 11 years old? by stephenmac7 · 2014-11-13 10:10 · Score: 1
  
  Go, not to be confused with Go!
  
  --
  "No man's life, liberty, or property are safe while the legislature is in session." -- Judge Gideon J. Tucker
Was ok till I read this: by Anonymous Coward · 2014-11-13 12:27 · Score: 0

"low-latency garbage collector"
Well, that ends my interest right there. No language should be doing anything I didn't tell it to do. Ever.
bzzzt,
1. Re:Was ok till I read this: by Anonymous Coward · 2014-11-13 13:28 · Score: 0
  
  Then don't turn garbage collection on? No langauge is psychic and supports you telling it what to do when you are too lazy to actually tell it.
2. Re:Was ok till I read this: by NoOneInParticular · 2014-11-13 14:38 · Score: 1
  
  If that's your point, you might want to get off your operating system as well. That thing is doing all kinds of stuff while running your program that you didn't tell it to do, leading to all kinds of unexpected behavior.
3. Re: Was ok till I read this: by LoRdTAW · 2014-11-14 15:39 · Score: 1
  
  Rust? No GC with safety.