[9fans] gcc not an option for Plan9
There are, regularly, mention for "porting" or having gcc(1) on Plan9 in order to be able to port more user level applications (because user level applications not only depend on a bunch of things---generally ignoring standards---but on compiler idiosynchrasies too...). With gcc 4.8.0, the implementation of gcc is now in C++... And to compile a compiler, one needs a C++ compiler... Great! I always thought that, because of what can be embedded in a compiler (cf. Ken Thompson's Trusting Trust) and because of a bootstrapping process (as explained in the red dragon book for example), the compiling of a compiler should need the strict minimum... IMHO, with the advent of a crisis compared to which 1929 will be a minor storm, there will be a general disgust and lack of trust and a return for crucial things to small is beautiful (and safer). Plan9 is not dead, simply waiting its "finest hour". Gcc on Plan9 is. And I won't weep. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
> With gcc 4.8.0, the implementation of gcc is now in C++... And to > compile a compiler, one needs a C++ compiler... This is not an insurmountable obstacle. In fact it's the normal situation when retargeting any self-compiled compiler for a new instruction set.
Re: [9fans] gcc not an option for Plan9
So, you perceive it, too unfortunately, then there will be no more computers, even electric power nomads don't need it, and won't care :-( ++pac > IMHO, with the advent of a crisis compared to which 1929 will be a > minor storm, there will be a general disgust and lack of trust and a > return for crucial things to small is beautiful (and safer). >
Re: [9fans] gcc not an option for Plan9
I wonder if the new gcc will be written in cfront compatible c++ - that would work... ☺ -Steve
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 09:53:29AM +, Richard Miller wrote: > > With gcc 4.8.0, the implementation of gcc is now in C++... And to > > compile a compiler, one needs a C++ compiler... > > This is not an insurmountable obstacle. In fact it's the normal > situation when retargeting any self-compiled compiler for a new > instruction set. > Except that C is a great language because it is both high level enough and low level (near machine) that a compiler written in C without optimizations and pure integer is "easy" (less expensive) to write from scratch. Here, the dependencies increase. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 10:54:14AM +0100, Peter A. Cejchan wrote: > So, you perceive it, too unfortunately, then there will be no more > computers, even electric power nomads don't need it, and won't care :-( > ++pac > > > > > IMHO, with the advent of a crisis compared to which 1929 will be a > > minor storm, there will be a general disgust and lack of trust and a > > return for crucial things to small is beautiful (and safer). > > I guess you are in Europe too? The only ones to refuse to see it can be described by François Mauriac's sentence: "The ostrich hides in the sand is little brainless head, trying to persuade itself that its feathered rear is offending nobody's eyes." -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
Yep... On Sat, Mar 23, 2013 at 11:10 AM, wrote: > On Sat, Mar 23, 2013 at 10:54:14AM +0100, Peter A. Cejchan wrote: > > So, you perceive it, too unfortunately, then there will be no more > > computers, even electric power nomads don't need it, and won't care > :-( > > ++pac > > > > > > > > > IMHO, with the advent of a crisis compared to which 1929 will be a > > > minor storm, there will be a general disgust and lack of trust and a > > > return for crucial things to small is beautiful (and safer). > > > > > I guess you are in Europe too? The only ones to refuse to see it can be > described by François Mauriac's sentence: "The ostrich hides in the sand > is little brainless head, trying to persuade itself that its feathered > rear is offending nobody's eyes." > -- > Thierry Laronde > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >
Re: [9fans] gcc not an option for Plan9
> Except that C is a great language because it is both high > level enough and low level (near machine) that a compiler written in C > without optimizations and pure integer is "easy" (less expensive) to > write from scratch. Here, the dependencies increase. I wouldn't cry too many tears over GCC. Having investigated Hogan's port of GCC (3.0) to Plan 9, my impression is that GCC would never really fit in with the Plan 9 paradigm, it is way too expensive and unrewarding to bend it into shape, C++ notwithstanding. Hence Go, together with the upgraded (if you want to call them that) Plan 9 development tools. I'm still of the opinion that a convergence of the Plan 9 tools and the Go development can become the Esperanto of information technology, given that ease of portability to foreign architectures is a founding principle. Only time will tell, sadly I don't see any organisation or authoritative person recommending 8c et al for development, where I expect that would be a step forward. The obsession with optimisation, in part, is to be blamed, too. But not alone. Just as a side note, I was hoping to port Plan 9 to the Olimex LinuXino, one of many project that may or may not see the light of day. It comes with some or other variety of Linux, but has too little memory (64MiB) to be more than an embedded prototyping system and the default Linux release comes without the GCC development system. It struck me that the Go system could be cross-compiled for Linux/Arm on my Plan 9 network and used on the LinuXino. In fact, I have implemented some small applications in this way although I have had no occasion to do more than that. If I could figure a way to compile the Go distribution with its own tools, I may be able to prove that Go is a viable release development system without GCC backing it, something we have shown to a smaller audience with the Plan9/386 distribution. ++L
Re: [9fans] gcc not an option for Plan9
@Lucio: I still hope that some clone of plan9/nix/nxm will merge with Go ... just my dream, and I am just an embryo of a programmer (as multiply stated here and elsewhere) so take it easy however, I'm moving all my old stuff (and creating new one) to Go [unfortunately, I am afraid I will never see the 9GoNix OS ;-) brought into life] Cheers, peter. On Sat, Mar 23, 2013 at 11:24 AM, wrote: > > Except that C is a great language because it is both high > > level enough and low level (near machine) that a compiler written in C > > without optimizations and pure integer is "easy" (less expensive) to > > write from scratch. Here, the dependencies increase. > > I wouldn't cry too many tears over GCC. Having investigated Hogan's > port of GCC (3.0) to Plan 9, my impression is that GCC would never > really fit in with the Plan 9 paradigm, it is way too expensive and > unrewarding to bend it into shape, C++ notwithstanding. > > Hence Go, together with the upgraded (if you want to call them that) > Plan 9 development tools. I'm still of the opinion that a convergence > of the Plan 9 tools and the Go development can become the Esperanto of > information technology, given that ease of portability to foreign > architectures is a founding principle. Only time will tell, sadly I > don't see any organisation or authoritative person recommending 8c et > al for development, where I expect that would be a step forward. > > The obsession with optimisation, in part, is to be blamed, too. But > not alone. > > Just as a side note, I was hoping to port Plan 9 to the Olimex > LinuXino, one of many project that may or may not see the light of > day. It comes with some or other variety of Linux, but has too little > memory (64MiB) to be more than an embedded prototyping system and the > default Linux release comes without the GCC development system. It > struck me that the Go system could be cross-compiled for Linux/Arm on > my Plan 9 network and used on the LinuXino. In fact, I have > implemented some small applications in this way although I have had no > occasion to do more than that. If I could figure a way to compile the > Go distribution with its own tools, I may be able to prove that Go is > a viable release development system without GCC backing it, something > we have shown to a smaller audience with the Plan9/386 distribution. > > ++L > > >
Re: [9fans] gcc not an option for Plan9
It has long been the case that gcc can only be compiled with gcc. Switching its impl. lang. to c++ doesn't make the porting problem any worse. The other "industrial strength" open source c/c++ compiler clang/llvm is also written in c++. They can both be built on windows so it would certainly be possible to port them to plan9 if there was real demand.
Re: [9fans] gcc not an option for Plan9
> [unfortunately, I am afraid I will never see the 9GoNix OS ;-) brought into > life] I think Plan 9 spoils us, the OS is just a tool, not a faith. Just as Go is not a faith, just a logical evolution of Alef, through Limbo, to the platforms and conditions that prevail today. What matters is to be able to produce code that runs on useful platforms and does not require blood, sweat and tears to be made to work. Myself, I want to teach underprivileged kids to program, the OS platform of choice is Plan 9, but I also need to prepare them for the Windows, Linux and OSX world. ++L
Re: [9fans] gcc not an option for Plan9
> It has long been the case that gcc can only be compiled with gcc. Switching > its impl. lang. to c++ doesn't make the porting problem any worse. > > The other "industrial strength" open source c/c++ compiler clang/llvm is also > written in c++. > > They can both be built on windows so it would certainly be possible to port > them to plan9 if there was real demand. +1 ++L
Re: [9fans] gcc not an option for Plan9
go runs already on 9. Binaries are one order of magnitude larger and the go tool & part of the runtime code are, well…. but it's already there. On Mar 23, 2013, at 12:40 PM, "Peter A. Cejchan" wrote: > I still hope that some clone of plan9/nix/nxm will merge with Go
Re: [9fans] gcc not an option for Plan9
> Binaries are one order of magnitude larger and the go tool & part of the > runtime code are, well…. sorry to be dense. larger than what? - erik
Re: [9fans] gcc not an option for Plan9
Than plan 9's C ones. On Mar 23, 2013, at 5:09 PM, erik quanstrom wrote: >> Binaries are one order of magnitude larger and the go tool & part of the >> runtime code are, well…. > > sorry to be dense. larger than what? > > - erik
Re: [9fans] gcc not an option for Plan9
>> Binaries are one order of magnitude larger and the go tool & part of the >> runtime code are, well…. > > sorry to be dense. larger than what? C
Re: [9fans] gcc not an option for Plan9
On Sat Mar 23 12:20:57 EDT 2013, n...@lsub.org wrote: > Than plan 9's C ones. > > On Mar 23, 2013, at 5:09 PM, erik quanstrom wrote: > > >> Binaries are one order of magnitude larger and the go tool & part of the > >> runtime code are, well…. > > > > sorry to be dense. larger than what? ah. i thought you were saying that it was an order of magnitude larger than the unix version of go. by the way, does this scale with lines of go code, or is it just that the trivial go executable is megs? - erik
Re: [9fans] gcc not an option for Plan9
>> Binaries are one order of magnitude larger and the go tool & part of the >> runtime code are, well…. > > sorry to be dense. larger than what? > My guess "larger than they need to be" because the Go linker does not drop unused library modules. Nemo may mean something else, of course. ++L
Re: [9fans] gcc not an option for Plan9
> > ah. i thought you were saying that it was an order of magnitude > larger than the unix version of go. > > by the way, does this scale with lines of go code, or is it just > that the trivial go executable is megs? A simple hello world is megs. G.
Re: [9fans] gcc not an option for Plan9
On 3/23/13, Peter A. Cejchan wrote: > @Lucio: I still hope that some clone of plan9/nix/nxm will merge with Go > ... just my dream, and I am just an embryo of a programmer > (as multiply stated here and elsewhere) so take it easy however, I'm > moving all my old stuff (and creating new one) to Go > [unfortunately, I am afraid I will never see the 9GoNix OS ;-) brought into > life] do I need 3d glasses to read your text? words don't really stick out with all these random parantheses, strange punctuations and double-spaces.
Re: [9fans] gcc not an option for Plan9
Much of which is symbols. Plus, a a simple computer has gigs of memory. Yes, it's remarkable how much bigger programs are now than they were 20 years ago, but 20 years ago the same things were being said. I understand your objection - I really do - but it's time to face the future. The smart phone in your pocket is roughly 100 times faster than the machine Plan 9 was developed on and has 1000 times the RAM. Computers are incredibly powerful now, and the technologies of today can use that power well (as I claim Go does) or poorly (as some others do), or ignore it at the risk of obsolescence. -rob
Re: [9fans] gcc not an option for Plan9
On Sat Mar 23 13:16:39 EDT 2013, robp...@gmail.com wrote: > Much of which is symbols. Plus, a a simple computer has gigs of memory. so, assuming demand loading, this is more of a disk space issue rather than a memory issue? - erik
Re: [9fans] gcc not an option for Plan9
> What matters is to be able to produce code What matters is to get rid of code.
Re: [9fans] gcc not an option for Plan9
Although, in general, I agree. I think that having the resources doesn't mean we have to consume them (although we might if that pays off, of course). For example, looking at what go install does wrt what a few mkfiles would do for the same go source is illustrative of what I'm trying to say. On Mar 23, 2013, at 6:15 PM, Rob Pike wrote: > Much of which is symbols. Plus, a a simple computer has gigs of memory. > > Yes, it's remarkable how much bigger programs are now than they were > 20 years ago, but 20 years ago the same things were being said. I > understand your objection - I really do - but it's time to face the > future. The smart phone in your pocket is roughly 100 times faster > than the machine Plan 9 was developed on and has 1000 times the RAM. > Computers are incredibly powerful now, and the technologies of today > can use that power well (as I claim Go does) or poorly (as some others > do), or ignore it at the risk of obsolescence. > > -rob
Re: [9fans] gcc not an option for Plan9
> it's time to face the future. will go be able to run in the browser with activex? is it compatible with node.js?
Re: [9fans] gcc not an option for Plan9
I feel like the future is repeating itself. Don't know what you find so worthy in this.
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 10:15:20AM -0700, Rob Pike wrote: > > Yes, it's remarkable how much bigger programs are now than they were > 20 years ago, but 20 years ago the same things were being said. Can we conclude that the added power is lost for the result obtained from the applications, since it is taken by the "machinery"? Just as if a washing powder giving already a "perfect" result 20 years ago had been "improved" (from perfect to more than perfect) being able to give a perfect result even if you make a knot around the heavy dirt before throwing in the washing-machine: you have a perfectly clean result (as you could obtain before, but without making the knot), except that you have to make the knots before and try to unmake them after? I remember when I started to work in a surveyor office. There was microstation, back in early 90s, that ran on a DOS extender with a perfect graphical performance (you were able to work flawlessly, zooming, panning or whatever). You were never waiting for the application or the display; it worked faster than your input. Once Windows "improved" came, it took several years for the computers to give the very same user experience, by an order of magnitude increase in power for the "PC". It had to recover from Windows improvements first... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
On 3/23/13, Francisco J Ballesteros wrote: > Although, in general, I agree. Are you surprised that you do?
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 6:15 PM, Rob Pike wrote: > Much of which is symbols. Plus, a a simple computer has gigs of memory. > > Yes, it's remarkable how much bigger programs are now than they were > 20 years ago, but 20 years ago the same things were being said. I > understand your objection - I really do - but it's time to face the > future. The smart phone in your pocket is roughly 100 times faster > than the machine Plan 9 was developed on and has 1000 times the RAM. I was merely stating facts, not criticising, as I am still learning about the go implementation, and I am sure there are good reasons why all this is true. In any case, the argument that there is more memory now is not a very good one unless you use it for something useful. The phone is very powerful, but it also runs on a battery and has to do many things on a budget, so that is not really an argument. Saying why you need/use the giant tables for may be. - With greater power comes greater need for restrain. G.
Re: [9fans] gcc not an option for Plan9
I'll try to say it in a different way. I asked Siri and (s)he said (s)he does not consume many resources. Now, that's nice. I'm willing to give up the machine resources for that, or for dialling by voice on my car. *But*, I'm not sure that to print "Hi there" I need a few megs, nor am I sure that to install a and compile a few sources I need to see hundreds of stats/reads; The funny thing is that the compilers seem to be really fast, but the go tool fixes that problem. Fortunately, a few mkfiles fix the go tool problems. Also, doing a cp /bin/echo /bin/hg improves things a bit. This is just IMHO, the language is nice as are parts of the runtime. I'm glad go is out there. On Mar 23, 2013, at 6:44 PM, hiro <23h...@gmail.com> wrote: > On 3/23/13, Francisco J Ballesteros wrote: >> Although, in general, I agree. > > Are you surprised that you do?
Re: [9fans] gcc not an option for Plan9
> I remember when I started to work in a surveyor office. There was > microstation, back in early 90s, that ran on a DOS extender with a > perfect graphical performance (you were able to work flawlessly, > zooming, panning or whatever). You were never waiting for the > application or the display; it worked faster than your input. > > Once Windows "improved" came, it took several years for the computers to > give the very same user experience, by an order of magnitude increase in > power for the "PC". It had to recover from Windows improvements first... yes. this is a big problem. incremental improvement often fails. and we see this today with newer phones performing poorly with "new and improved" software. the way to get out of this trap is to provide real improvement by doing something new. (the term of art is "disruptive"—a rather annoying term. :-)) obviously the new approach isn't going to be as polished as the old approach. but if the new thing is a real improvement, folks will put up with the regressions in unimportant areas. there was an old way to say this, "you can't make an omlette without breaking a few eggs". :-) - erik
Re: [9fans] gcc not an option for Plan9
this is not a new discussion, it started in november 2009. the fact
that it's just coming to 9fans is a sign of how far behind the times
we are :(
the go runtime is ~380k. that one you must carry always even in an
empty program (see below). what you're complaining about is the
side-effect of importing fmt and other big packages such as os and
net. with fmt you're sucking in all the unicode code tables and the
reflection code used to process printing arguments (which you can't
prove will not be used). the initial jump is big, but as your code
grows the binary size tends to increase slower -- all of the imports
are already in. the biggest program from the Go distribution
frequently in use is "godoc". it deals with xml, json, binary
encoding, directory navigation, document preparation, source code
parsing, compression/decompression and serves the major website for go
-- golang.org... that program, statically linked, is 8 megs (64-bit).
i've seen things that deal with graphics which get to 20 megs. that is
reasonable, i think.
here's an illustrative progression of go binary sizes:
$ cat > t.go
package main
func main(){
}
$ go build t.go; ls -l t
-rwxr-xr-x 1 andrey wheel 384880 Mar 23 12:43 t
$ cat > t.go
package main
func main(){
println("hello")
}
$ go build t.go; ls -l t; ./t
-rwxr-xr-x 1 andrey wheel 389008 Mar 23 12:43 t
hello
$ cat > t.go
package main
import "unicode"
var _ = unicode.MaxRune
func main() {
}
$ go build t.go; ls -l t
-rwxr-xr-x 1 andrey wheel 581024 Mar 23 12:45 t
$ cat > t.go
package main
import "fmt"
var _ = fmt.Println
func main(){
}
$ go build t.go; ls -l t
-rwxr-xr-x 1 andrey wheel 1481920 Mar 23 12:44 t
Re: [9fans] gcc not an option for Plan9
It's pointless to complain about the size of "hello world". It's not a real program. In Go's case it's larger than a C binary because the libraries (and the presence of a runtime) are capable of much more under the covers, but by the time you write a real program in Go you'll find the ratio of Go binary to C binary isn't nearly so large; the incremental cost to the binary of a Go source file compared to a C Go file is negligible. A house is much heavier than a tent, but it also has a much stronger foundation. -rob
Re: [9fans] gcc not an option for Plan9
Thanks, Andrey, although what you say about Unicode and fmt isn't true. Believe it or not, we care about sizes and arranged that fmt doesn't need to import the whole Unicode tables, only the small subset it needs. -rob
Re: [9fans] gcc not an option for Plan9
I'll happily pay the price of bigger binaries for things such as the %v format. I don't write hello, world that often, or even care about its size when I do. One demo we used to do for Unix was show we could write an executable program that was 2 bytes. It was cute. Did it matter, in the end? Not really. But we used to call 4k programs bloated. I have a hard time worrying about 1M binaries on $200 machines with 12 GB/s memory bandwidth and 4G memory. It's 2013. ron
Re: [9fans] gcc not an option for Plan9
> incremental improvement often fails. why does it fail? I don't see why this has to be a rule. a frequently annoying counterexample is when they yet again reinvent the wheel, include a new "compatible" implementation of all the old features and some new features, all based on some better design - and most of the old bugs are gone, lots of things just work, lots of new stuff even - but lots of stuff that used to work is now bugged also.
Re: [9fans] gcc not an option for Plan9
so, assuming demand loading, this is more of a disk space issue rather than a memory issue? It's only an issue on mailing lists and discussion groups. -rob
Re: [9fans] gcc not an option for Plan9
On Sat Mar 23 15:30:40 EDT 2013, robp...@gmail.com wrote: >so, assuming demand loading, this is more of a >disk space issue rather than a memory issue? > > It's only an issue on mailing lists and discussion groups. i was hoping to know if the symbols are used for reflection. - erik
Re: [9fans] gcc not an option for Plan9
I have a few programs written, including fs sync tools and a few other things. I guess the largest one might be 10k lines. The language is nice, although binaries are still large. I mentioned hello world because that was the trivial example. I saw the same effect with other real world programs. I admit it might be necessary, but I wouldnt say sizes are comparable. Also, I was reading the discussion andrey mentioned by the time it happened. I guess it didnt reach this list until now because go didnt run on plan 9 until recently. On Mar 23, 2013, at 8:17 PM, Rob Pike wrote: > It's pointless to complain about the size of "hello world". It's not a > real program. In Go's case it's larger than a C binary because the > libraries (and the presence of a runtime) are capable of much more > under the covers, but by the time you write a real program in Go > you'll find the ratio of Go binary to C binary isn't nearly so large; > the incremental cost to the binary of a Go source file compared to a C > Go file is negligible. > > A house is much heavier than a tent, but it also has a much stronger > foundation. > > -rob
Re: [9fans] gcc not an option for Plan9
For example, looking at what go install does wrt what a few mkfiles would do for the same go source is illustrative of what I'm trying to say. I've never seen a mkfile that builds a transitive dependency graph given only the source code, downloads the relative dependencies from the network, builds all the dependencies, and installs the result. Yes mk could do that, but it would need a lot of help, and that help is not going to materialize. Why use mk when the source code has all the information you need to build the program? I was a big fan of mk, and it (or make, depending) is still used to help bootstrap the Go installation, but honestly I do not miss writing mkfiles one bit. -rob
Re: [9fans] gcc not an option for Plan9
Yes, they are necessary for reflection. Fmt uses reflection - and uses it well, as rminnich has attested. On Sat, Mar 23, 2013 at 12:31 PM, erik quanstrom wrote: > On Sat Mar 23 15:30:40 EDT 2013, robp...@gmail.com wrote: >>so, assuming demand loading, this is more of a >>disk space issue rather than a memory issue? >> >> It's only an issue on mailing lists and discussion groups. > > i was hoping to know if the symbols are used for reflection. > > - erik >
Re: [9fans] gcc not an option for Plan9
If go install is slow on Plan 9, it's because Plan 9's file system is slow (which it is and always has been), and because go install does transitive dependencies correctly, which mk does not. -rob
Re: [9fans] gcc not an option for Plan9
On Mar 23, 2013, at 8:33 PM, Rob Pike wrote: > Why use mk when the source code has all the > information you need to build the program speed. You have a fast and nice compiler. I only copy a std mkfile to each dir with go source. I dont write them.
Re: [9fans] gcc not an option for Plan9
I just did a go install, after a clean, of the biggest binary I'm working on, using my pokey old mac laptop. It took 0.9 seconds, most of which was spent in 6l and not the go tool. It could be faster, but it's plenty fast enough. The public won't use mk or make. If you want to succeed in the world, you need to find a more modern way to build software. It's been clear for a long time that that is not a relevant criterion for this community any more, and although it makes me sad I have moved on. I regret responding to this thread, and will move on there, too. -rob
Re: [9fans] gcc not an option for Plan9
might be, but I was also thinking on macos x, not just 9. On Mar 23, 2013, at 8:37 PM, Rob Pike wrote: > If go install is slow on Plan 9, it's because Plan 9's file system is > slow (which it is and always has been), and because go install does > transitive dependencies correctly, which mk does not. > > -rob
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 8:23 PM, ron minnich wrote: > I'll happily pay the price of bigger binaries for things such as the %v > format. > > I don't write hello, world that often, or even care about its size when I do. Hello world was just an example, please don't make a straw man out of it. If you want real programs which are bigger that I (we) actually use that will be (much) bigger in go: ls, cp rm mv cat acid, I can go on. Small programs are useful and important. There is a price to pay, and if you get something useful out of it, it may be a fair price to pay, as I said in my other e-mail, I was just stating a fact, binaries are bigger and for example replacing the minimal sets of commands of the system, this can make the minimal system at least 5 times bigger easy. > I have a hard time worrying about 1M binaries on $200 machines with > 12 GB/s memory bandwidth and 4G memory. > It's 2013. > A lot of my friends have cheap phones that run out of memory all the time. There is not a one size fits all in engineering, there are compromises and uses. Higher level programming means paying the cost of bigger binaries, that may be ok for some uses and not for others. I like writing go code, it is fun, and has a fairly high level of abstraction while letting you access the system easily (I am looking at you Java). As I said, at least from me, it was not a complaint, just a statement of a fact. I have spent quite some amount of time lately getting go working on arm in Plan 9 because I value the language. G.
Re: [9fans] gcc not an option for Plan9
with mkfiles you can never have something like http://godoc.org. in fact, it would be very difficult to make something like godoc for any other language without major support from the authors or volunteers. what godoc.org does is amazing -- when you type in a query for something that looks like a go package it will attempt to download it and generate the package documentation from the source code on the fly. no interaction from the author or website maintainer need to happen, all is done by the go tool, usually with enough speed that not much waiting is involved. all the package needs to do is abide by a few rules in naming imports. try it for yourself (these packages will surely not be in the index): http://godoc.org/code.google.com/p/goxscr/qcs http://godoc.org/code.google.com/p/goxscr/deco http://godoc.org/code.google.com/p/goxscr/palette http://godoc.org/code.google.com/p/goxscr/rorschach http://godoc.org/code.google.com/p/goxscr/spirograph the stuff that falls out of such a tool is even more impressive. here's an import graph for one of the xscr programs: http://godoc.org/code.google.com/p/goxscr/moire?view=import-graph here's the one for godoc: http://godoc.org/code.google.com/p/go/src/cmd/godoc?view=import-graph
Re: [9fans] gcc not an option for Plan9
I used noweb, and web before that, long before go was conceived. In fact, I was a huge fan of that. Knuth literate programming was fun. it was tiny compared with godoc tool. Although the go tool is tiny compared with eclipse or even the old code warrior. I like the language, and worked to get it running on our systems. Its nice how the go tool does some of the things it does, although there are other things it does that I prefer to do with other tools. I was just mentioning some facts about it I dont like. On Mar 23, 2013, at 8:58 PM, andrey mirtchovski wrote: > with mkfiles you can never have something like http://godoc.org. in > fact, it would be very difficult to make something like godoc for any > other language without major support from the authors or volunteers. > > what godoc.org does is amazing -- when you type in a query for > something that looks like a go package it will attempt to download it > and generate the package documentation from the source code on the > fly. no interaction from the author or website maintainer need to > happen, all is done by the go tool, usually with enough speed that not > much waiting is involved. all the package needs to do is abide by a > few rules in naming imports. > > try it for yourself (these packages will surely not be in the index): > > http://godoc.org/code.google.com/p/goxscr/qcs > http://godoc.org/code.google.com/p/goxscr/deco > http://godoc.org/code.google.com/p/goxscr/palette > http://godoc.org/code.google.com/p/goxscr/rorschach > http://godoc.org/code.google.com/p/goxscr/spirograph > > the stuff that falls out of such a tool is even more impressive. > here's an import graph for one of the xscr programs: > http://godoc.org/code.google.com/p/goxscr/moire?view=import-graph > > here's the one for godoc: > http://godoc.org/code.google.com/p/go/src/cmd/godoc?view=import-graph
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 09:56:19AM +, Steve Simon wrote: > I wonder if the new gcc will be written in cfront compatible > c++ - that would work... ? I guess the answer is: no, since the compiler has to be C++ 2003 compatible. But I guess too that your mention of cfront was a joke... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
Yup Sent from my iPhone On Mar 23, 2013, at 12:17 PM, Rob Pike wrote: > It's pointless to complain about the size of "hello world". It's not a > real program. In Go's case it's larger than a C binary because the > libraries (and the presence of a runtime) are capable of much more > under the covers, but by the time you write a real program in Go > you'll find the ratio of Go binary to C binary isn't nearly so large; > the incremental cost to the binary of a Go source file compared to a C > Go file is negligible. > > A house is much heavier than a tent, but it also has a much stronger > foundation. > > -rob >
Re: [9fans] gcc not an option for Plan9
> If you want real programs which are bigger that I (we) actually use that will > be (much) bigger in go: > > ls, cp rm mv cat acid, I can go on. > > Small programs are useful and important. here's a representative set. the programs are identical in behaviour and arguments to the Plan 9 set. the size is as reported by du, in kilobytes: 1456 ./date/date 1460 ./cat/cat 1564 ./cleanname/cleanname 1564 ./tee/tee 1736 ./echo/echo 1764 ./cp/cp 1772 ./uniq/uniq 1780 ./cmp/cmp 1780 ./freq/freq 1780 ./wc/wc 1792 ./comm/comm > binaries are bigger and for example replacing the minimal sets of commands of > the system, this can make the > minimal system at least 5 times bigger easy. if that was a real issue you were trying to solve there are things you can do to help yourself. most notably sticking everything in a single binary and invoking the right function based on your argv0. it took me less than 15 minutes to convert the above code to work as a single binary and most of that was in handling clashing flags (it would've been a non-issue if I had used flagsets when writing the original programs). size at the very end: $ date > test.txt $ ln -s $GOPATH/bin/all cat $ ln -s $GOPATH/bin/all wc $ ./cat test.txt Sat Mar 23 17:32:42 MDT 2013 $ ./wc test.txt 1 6 29 test.txt $ du -k $GOPATH/bin/all 1888 /Users/andrey/bin/all the size of the original binaries on plan9 is 588k. what was a factor of 30 is now a factor of 3. all tests still pass and it took less time to complete than writing this email. there's an even better solution, but it won't work on plan9 because the go tool is slow there :)
Re: [9fans] gcc not an option for Plan9
I recall one guy at the labs(!) who would ruthlessly avoid printf because it dragged in too much stuff. I think he ran out of people to argue with 30 years ago. On 24 Mar 2013 10:47, "andrey mirtchovski" wrote: > > If you want real programs which are bigger that I (we) actually use that > will > > be (much) bigger in go: > > > > ls, cp rm mv cat acid, I can go on. > > > > Small programs are useful and important. > > here's a representative set. the programs are identical in behaviour > and arguments to the Plan 9 set. the size is as reported by du, in > kilobytes: > > 1456 ./date/date > 1460 ./cat/cat > 1564 ./cleanname/cleanname > 1564 ./tee/tee > 1736 ./echo/echo > 1764 ./cp/cp > 1772 ./uniq/uniq > 1780 ./cmp/cmp > 1780 ./freq/freq > 1780 ./wc/wc > 1792 ./comm/comm > > > binaries are bigger and for example replacing the minimal sets of > commands of > > the system, this can make the > > minimal system at least 5 times bigger easy. > > if that was a real issue you were trying to solve there are things you > can do to help yourself. most notably sticking everything in a single > binary and invoking the right function based on your argv0. it took me > less than 15 minutes to convert the above code to work as a single > binary and most of that was in handling clashing flags (it would've > been a non-issue if I had used flagsets when writing the original > programs). size at the very end: > > $ date > test.txt > $ ln -s $GOPATH/bin/all cat > $ ln -s $GOPATH/bin/all wc > $ ./cat test.txt > Sat Mar 23 17:32:42 MDT 2013 > $ ./wc test.txt > 1 6 29 test.txt > $ du -k $GOPATH/bin/all > 1888 /Users/andrey/bin/all > > the size of the original binaries on plan9 is 588k. what was a factor > of 30 is now a factor of 3. all tests still pass and it took less time > to complete than writing this email. > > there's an even better solution, but it won't work on plan9 because > the go tool is slow there :) > >
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 10:15:20AM -0700, Rob Pike wrote: > Much of which is symbols. Plus, a a simple computer has gigs of memory. > > Yes, it's remarkable how much bigger programs are now than they were > 20 years ago, but 20 years ago the same things were being said. I > understand your objection - I really do - but it's time to face the > future. The smart phone in your pocket is roughly 100 times faster > than the machine Plan 9 was developed on and has 1000 times the RAM. > Computers are incredibly powerful now, and the technologies of today > can use that power well (as I claim Go does) or poorly (as some others > do), or ignore it at the risk of obsolescence. > > -rob > Ah, yes, the old "put more ram in your macbook" argument. Some guy bought an iphone, so we should immediately throw away any computers that are not at least iphones. This saves valuable programmer time, because they don't have to optimize things instead of doing important work like providing sixteen SQL libraries. To the future! khm
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 12:29:36PM -0700, Rob Pike wrote: >so, assuming demand loading, this is more of a >disk space issue rather than a memory issue? > > It's only an issue on mailing lists and discussion groups. > > -rob > Also in university campuses and web programming shops, which are the only other two places Go is discussed. khm
Re: [9fans] gcc not an option for Plan9
On Sat, Mar 23, 2013 at 12:43:24PM -0700, Rob Pike wrote: > > The public won't use mk or make. If you want to succeed in the world, Oh good, is this where we find out we've all been using the wrong version of 'success'? Not everone has your goals. Still. > > I regret responding to this thread > Agreed.
[9fans] gcc
I regret that you regret responding, and hope that you will relent. It's always refreshing to hear from curmudgeons with quite a few more clues than oneself. I'm not sure if I'm the public exactly, but I do find mk and make too labour-intensive for my tastes. I'm now an IDE kind of guy, having started out using Fortran IV on a 300 baud teletype as a contemporary of Barmy Shoestring, and having moved on to Microsoft Visual Studio, which, in its 2008 incarnation, the last good one, I actually liked. So shoot me. But I've also learnt to value the terseness of the command line, and have been, in many ways, vastly more productive using tips on this list, and also from "The Unix Programming Environment". Each to their own - there is no one set of tools that suits everyone. Xcode increasingly works for me. And how many of the youth have read Fowler? > Date: Sat, 23 Mar 2013 12:43:24 -0700 > From: Rob Pike > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Subject: Re: [9fans] gcc not an option for Plan9 > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > I just did a go install, after a clean, of the biggest binary I'm > working on, using my pokey old mac laptop. It took 0.9 seconds, most > of which was spent in 6l and not the go tool. It could be faster, but > it's plenty fast enough. > > The public won't use mk or make. If you want to succeed in the world, > you need to find a more modern way to build software. It's been clear > for a long time that that is not a relevant criterion for this > community any more, and although it makes me sad I have moved on. > > I regret responding to this thread, and will move on there, too. > > -rob >
