The Go 1.5 release includes preliminary support for shared libraries. You can now build your Go programs to use shared libraries, on x86_64 GNU/Linux. You can also build shared libraries that can be linked into a C/C++ program, on several platforms.
Go has had an FFI for calling into C from the beginning: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgolang.org%2Fcmd%2Fcgo .
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.
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.
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.
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.
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... .
Docker? (http://www.docker.com)
Restricting this kind of discussion to income tax is misleading to the point of being deceptive. Most people pay more in payroll taxes than they pay in income taxes. That 47% of households who paid no income tax paid plenty in payroll taxes.
The only way you can conclude that nearly 50% of the people in the U.S. pay not taxes is if you think that the only taxes people pay are income taxes. In fact most people pay payroll taxes, for social security and medicare. Those are about 7.5% of income for most people. 7.5% is a long way from zero.
And then there are sales taxes.
Go has panic/recover, which can serve the same purpose as exceptions in other language.
Go has no immutability concept, so it doesn't have half-assed one.
Yes, focusing on compile time is relevant; I think anybody who writes large C++ programs can see the point of that.
Go has a modularization system by my definition, I don't know what you mean by it.
Everyone has a purpose in life. Perhaps yours is watching television. - David Letterman
