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.
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.
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.
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.
Re:I'm thinking of contributing to GCC...
on
GCC 4.1 Released
·
· Score: 1
gcc's inlining got much better in the 3.4 release, and got better still in the 4.0 release. If you still see a penalty for inlining in the 4.0 release, please file a bug report as described at http://gcc.gnu.org/bugs.html. Thanks.
As far as joining the project goes, it is easy. Sign up for the mailing lists, check out the code, and start working. Contributing a substantial patch requires signing a copyright assignment before it can be accepted.
Re:Do the new models replace or confuse old ones?
on
A Review of GCC 4.0
·
· Score: 1
When it comes to gcc 4, I disagree. I think gcc does much better with register-rich architectures than with register-poor architectures. By modern standards, of course, m68k is not register rich (nor register poor)--it only has 16 registers, and they are not fully orthogonal in that some instructions require data registers and some require address registers.
I also think that the m68k backend does not include EMAC support. Do you want to contribute support?
Re:Do the new models replace or confuse old ones?
on
A Review of GCC 4.0
·
· Score: 1
Sorry, my answer was ambiguous. gcc does already support the ColdFire in many variants. I was just using that as an example of why you might use the m68k backend, not as an example of work which needed to be done.
Re:Still generating 386 assembly?
on
A Review of GCC 4.0
·
· Score: 4, Informative
You need to read up on the -march, -mfpmath, -mmmx, -msse, -msse2, -msse3, and -m3dnow options.
If you build gcc yourself, you can even make them the default by configuring with an appropriate --with-arch option.
The linker --gc-sections option eliminates unused sections between object files. The compiler only generates one object file at a time. So they are different issues.
That said, see the -combine option, which permits compiling several source files together, permitting better inlining across source units.
If executable size is your main concern, make sure you compile with -Os. The default set of optimizations tend to try to decrease execution time by increasing code size (this is only a generalization, of course, as you also increase execution time by keeping your code small enough to fit in the L1 cache). -Os tells the compiler to prefer to decrease code size.
Re:This is expected, I think
on
A Review of GCC 4.0
·
· Score: 2, Informative
That is only partly true. All gcc releases since 1.0 have integrated optimizations across all languages. What gcc 4.0 has added is a new, higher-level framework for language independent optimizations. The new framework, known as tree-ssa, permits more powerful optimization techniques, in particular some of the techniques which have been developed by the compiler research community since gcc was first written in the 1980s. The old language independent optimization framework, known as RTL, is still there and is still used in gcc 4.0.
Re:Do the new models replace or confuse old ones?
on
A Review of GCC 4.0
·
· Score: 1
The new tree-ssa optimization passes do not affect the backends. The backends continue to be written using RTL. It is very difficult to make a "somewhat-clean break" here, since that would imply rewriting or dropping every existing backend.
In other words, writing a gcc backend continues to be a relatively black art. That said, there is of course continuing effort to clean up the backend interface and make it easier to use and to understand.
Finally I'll note that the m68k is a very old processor and is one of the oldest gcc backends. It would be an odd choice to pick that backend to modify to support a new processor, unless the new processor is a direct variant of the m68k like ColdFire. For any other processor, you should certainly start by looking at a different backend. And, in fact, in general, I think you should write a new backend from scratch. I've done it both ways, and starting from scratch, while of course looking at existing backends, means that you understand all the code and you don't have a lot of cruft which is irrelevant for your processor.
The founders of Cygnus Support, later Cygnus Solutions, later a part of Red Hat, for showing, in 1989, that you really could create a business on free software: David Henkel-Wallace, Michael Tiemann, John Gilmore.
They are suing IBM for contributing AIX code to Linux. But even if they win, that doesn't give them any IP rights to Linux itself. After all, SCO doesn't own the code which IBM wrote, and if they get damages from IBM, then they are fully compensated for the fact that the code was incorporated into Linux.
So SCO is also claiming that code was copied directly from the AT&T Unix sources, which SCO does own, into Linux. If that happened, then SCO can claim some IP rights to Linux.
Of course, since SCO won't reveal any copying, it's unlikely that they will be able to claim damages. They're supposed to first notify about copyright infringement, and only if it continues do they get damages. SCO is hoping that people pay their invoices without realizing that.
Like everybody else, I haven't seen a copy of the license text. But I think the general idea is that the license will grant you the right to use any IP owned by SCO while running Linux on one computer.
To put it another way, SCO currently claims the right to sue Linux users for copyright infringement. If you buy this license from SCO, they will no longer sue you.
Any similarity to a protection racket is not coincidental.
Well, natural resources etcetera are non-people reasons why we have greater productivity per capital, I suppose.
I would say that natural resources, etc., are reasons why the U.S. GDP is high. Greater productivity is also a reason for a high GDP. Natural resources do not obviously lead to greater productivity.
Certainly, the track record of resource-dependent countries, especially oil or diamonds, is rather poor.
There, see? You agree with me. Remember that while a country like Kuwait doesn't have high productivity, they sure have a high per capita GDP.
I'd argue your point about the economy being "highly artificial" in some kind of meaningful sense. It evolved organically. Just because it doesn't make sense from some higher purpose, well, that's true of all organic things.
Fair enough. I meant artificial in the sense that there is a great deal that people in the U.S. buy that they don't need--that is, things beyond food and shelter. I'm not saying that people shouldn't want these things, or shouldn't buy them. I'm saying that the U.S. economy works because people buy things they don't need. If people only bought what they needed--if we all joined a Zen monastery, say--the U.S. economy would collapse. Nobody would starve, but money would stop moving, jobs would disappear, and the whole thing would stabilize at a much lower GDP.
And I'm not saying that IT isn't helpful. But we got along fine without it for a few thousand years, and we could get along fine without it in the future if we had to. Suggesting that I couldn't do my job without e-mail sort of misses my point; my point is that my job is also non-essential.
It's an over-simplification to say that the U.S. GDP is higher because the U.S. is more productive per capita.
The U.S. benefits from a number of factors: vast natural resources, relatively late development of an agricultural economy (i.e., when the Europeans came in), isolation from the rest of the world permitting it to stay out of wars and leading it to become the financial center of the world.
That said, it's certainly true that exporting jobs doesn't hurt the economy in the long run. The U.S. economy is a highly artificial creation driven, ultimately, by consumer spending. As long as consumers keep spending, money keeps circulating, and the economy can keep growing. It doesn't really matter what people buy--it's not like most companies really need IT services in any fundamental sense, they just have to buy them because their competitors do.
A rather larger threat to U.S. productivity is the growing gap between the rich and the poor, because, proportionately speaking, the rich don't spend their money in ways that are useful to the economy.
Certainly UUCP is not necessary. But for laptop users it is more convenient than something like fetchmail. It operates as a push protocol--when new mail comes in, it is immediately sent to the laptop if the laptop is on-line, otherwise it is queued until the laptop comes on-line. I've been using it this way for years.
Whenever I see ESR refer to "his people," or "his tribe," or in any way refer to being a spokesperson for some group of people, I always try to figure out a way to get myself out of that group.
There are few things more irritating than having somebody else tell me what I think.
Slashdot Mirror
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://golang.org/cmd/cgo .
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.
gcc's inlining got much better in the 3.4 release, and got better still in the 4.0 release. If you still see a penalty for inlining in the 4.0 release, please file a bug report as described at http://gcc.gnu.org/bugs.html. Thanks.
As far as joining the project goes, it is easy. Sign up for the mailing lists, check out the code, and start working. Contributing a substantial patch requires signing a copyright assignment before it can be accepted.
When it comes to gcc 4, I disagree. I think gcc does much better with register-rich architectures than with register-poor architectures. By modern standards, of course, m68k is not register rich (nor register poor)--it only has 16 registers, and they are not fully orthogonal in that some instructions require data registers and some require address registers.
I also think that the m68k backend does not include EMAC support. Do you want to contribute support?
Sorry, my answer was ambiguous. gcc does already support the ColdFire in many variants. I was just using that as an example of why you might use the m68k backend, not as an example of work which needed to be done.
You need to read up on the -march, -mfpmath, -mmmx, -msse, -msse2, -msse3, and -m3dnow options.
If you build gcc yourself, you can even make them the default by configuring with an appropriate --with-arch option.
The linker --gc-sections option eliminates unused sections between object files. The compiler only generates one object file at a time. So they are different issues.
That said, see the -combine option, which permits compiling several source files together, permitting better inlining across source units.
If executable size is your main concern, make sure you compile with -Os. The default set of optimizations tend to try to decrease execution time by increasing code size (this is only a generalization, of course, as you also increase execution time by keeping your code small enough to fit in the L1 cache). -Os tells the compiler to prefer to decrease code size.
That is only partly true. All gcc releases since 1.0 have integrated optimizations across all languages. What gcc 4.0 has added is a new, higher-level framework for language independent optimizations. The new framework, known as tree-ssa, permits more powerful optimization techniques, in particular some of the techniques which have been developed by the compiler research community since gcc was first written in the 1980s. The old language independent optimization framework, known as RTL, is still there and is still used in gcc 4.0.
The new tree-ssa optimization passes do not affect the backends. The backends continue to be written using RTL. It is very difficult to make a "somewhat-clean break" here, since that would imply rewriting or dropping every existing backend.
In other words, writing a gcc backend continues to be a relatively black art. That said, there is of course continuing effort to clean up the backend interface and make it easier to use and to understand.
Finally I'll note that the m68k is a very old processor and is one of the oldest gcc backends. It would be an odd choice to pick that backend to modify to support a new processor, unless the new processor is a direct variant of the m68k like ColdFire. For any other processor, you should certainly start by looking at a different backend. And, in fact, in general, I think you should write a new backend from scratch. I've done it both ways, and starting from scratch, while of course looking at existing backends, means that you understand all the code and you don't have a lot of cruft which is irrelevant for your processor.
The founders of Cygnus Support, later Cygnus Solutions, later a part of Red Hat, for showing, in 1989, that you really could create a business on free software: David Henkel-Wallace, Michael Tiemann, John Gilmore.
SCO is saying both things at once.
They are suing IBM for contributing AIX code to Linux. But even if they win, that doesn't give them any IP rights to Linux itself. After all, SCO doesn't own the code which IBM wrote, and if they get damages from IBM, then they are fully compensated for the fact that the code was incorporated into Linux.
So SCO is also claiming that code was copied directly from the AT&T Unix sources, which SCO does own, into Linux. If that happened, then SCO can claim some IP rights to Linux.
Of course, since SCO won't reveal any copying, it's unlikely that they will be able to claim damages. They're supposed to first notify about copyright infringement, and only if it continues do they get damages. SCO is hoping that people pay their invoices without realizing that.
Like everybody else, I haven't seen a copy of the license text. But I think the general idea is that the license will grant you the right to use any IP owned by SCO while running Linux on one computer.
To put it another way, SCO currently claims the right to sue Linux users for copyright infringement. If you buy this license from SCO, they will no longer sue you.
Any similarity to a protection racket is not coincidental.
Amusing, but everybody remember that this was the old SCO (now Tarantella), not the new SCO (formerly Caldera).
Well, natural resources etcetera are non-people reasons why we have greater productivity per capital, I suppose.
I would say that natural resources, etc., are reasons why the U.S. GDP is high. Greater productivity is also a reason for a high GDP. Natural resources do not obviously lead to greater productivity.
Certainly, the track record of resource-dependent countries, especially oil or diamonds, is rather poor.
There, see? You agree with me. Remember that while a country like Kuwait doesn't have high productivity, they sure have a high per capita GDP.
I'd argue your point about the economy being "highly artificial" in some kind of meaningful sense. It evolved organically. Just because it doesn't make sense from some higher purpose, well, that's true of all organic things.
Fair enough. I meant artificial in the sense that there is a great deal that people in the U.S. buy that they don't need--that is, things beyond food and shelter. I'm not saying that people shouldn't want these things, or shouldn't buy them. I'm saying that the U.S. economy works because people buy things they don't need. If people only bought what they needed--if we all joined a Zen monastery, say--the U.S. economy would collapse. Nobody would starve, but money would stop moving, jobs would disappear, and the whole thing would stabilize at a much lower GDP.
And I'm not saying that IT isn't helpful. But we got along fine without it for a few thousand years, and we could get along fine without it in the future if we had to. Suggesting that I couldn't do my job without e-mail sort of misses my point; my point is that my job is also non-essential.
It's an over-simplification to say that the U.S. GDP is higher because the U.S. is more productive per capita.
The U.S. benefits from a number of factors: vast natural resources, relatively late development of an agricultural economy (i.e., when the Europeans came in), isolation from the rest of the world permitting it to stay out of wars and leading it to become the financial center of the world.
That said, it's certainly true that exporting jobs doesn't hurt the economy in the long run. The U.S. economy is a highly artificial creation driven, ultimately, by consumer spending. As long as consumers keep spending, money keeps circulating, and the economy can keep growing. It doesn't really matter what people buy--it's not like most companies really need IT services in any fundamental sense, they just have to buy them because their competitors do.
A rather larger threat to U.S. productivity is the growing gap between the rich and the poor, because, proportionately speaking, the rich don't spend their money in ways that are useful to the economy.
Certainly UUCP is not necessary. But for laptop users it is more convenient than something like fetchmail. It operates as a push protocol--when new mail comes in, it is immediately sent to the laptop if the laptop is on-line, otherwise it is queued until the laptop comes on-line. I've been using it this way for years.
Whenever I see ESR refer to "his people," or "his tribe," or in any way refer to being a spokesperson for some group of people, I always try to figure out a way to get myself out of that group.
There are few things more irritating than having somebody else tell me what I think.