f2f

I feel this document really captures the feeling that OS researchers had at the turn of the century:

http://herpolhode.com/rob/utah2000.pdf

On one hand you had Windows NT taking over commercial space, on the other you had the Linux juggernaut gathering speed. There was not much left for the niche players.

Glad to see Minix survives still.

Not anymore. You're two years out of date

DMD isn't faster than the go compiler anymore

Quit whining.

"at least" is there for a reason.

"microthreads", channels, and the select statement predate go at least by a couple of decades in Alef, Plan9's libthread, Limbo, Newsqueak, etc.

> lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc..

channels work just fine in a single-cpu context. concurrency is not parallelism.

the go side of that paper should be accompanied by this link, always:

http://blog.golang.org/profiling-go-programs

no such large go shops exist.

gofmt already uses elastic tabstops.

+1 so hard my keyboard almost broke

Every language needs this except lisp and python :)

Note that the one trick gofmt has over say indent is that it truly understands go syntax. It's not just a pretty printer

Great news! This will finally bring Amoeba into the mainstream!

> But perhaps this has changed in recent versions of go?

it hasn't. i meant 'if you build go with CGO_ENABLED=0' but was unclear.

if you build with CGO_ENABLED=0 then you'll have fully static go binaries on osx (but TLS won't work)

pleased to make your acquaintance.

too bad, it can't be changed now. that would require editing a number and recompiling!

this is the fat-tree connection diagram for one of the cabinets of a CM-5. it was posted on a wall at one of the national labs in the US which had the pleasure of working with a CM-5 around the time War Games was in theatres. People still gushed about how nice that machine was to program 10-15 years later. SyCortex tried to do something similar with their computers, unfortunately they failed and with them the last interesting connector architecture...

http://i.imgur.com/jHtf4QB.jpg

<T>. they know who they are.

is this trying to solve a particular problem or just pandering to the "... but generics!" crowd of trolls?

because it doesn't look like it's solving anything, it feels positively ugly, and there's no way we'll every shut those people up no matter how hard we try. there's no generics solution that will do that.

thankfully go's authors don't usually favour the internet's opinion on these matters, or we'd be dealing with something even uglier now.

I think they should hold a bake sale.

the server (mqttsrv) needs GOMAXPROCS>1 for any appreciable changes in the results, otherwise we're just measuring contention in the client.

i ran on a 2-core intel desktop running linux.

loadtest for 100 500 750 1000, X*Y below means X = loadtest GOMAXPROCS and Y = mqttsrv GOMAXPROCS:

  1x1 80735 67696 67068 66585
  2x1 64380 76531 31346 43268
  4x1 77613 73794 72759 43263
  8x1 77813 64197 32899 46960

  1x2 71641 72521 72715 72695
  2x2 103711 102944 104210 39619
  4x2 73171 23803 90537 46204
  8x2 96624 49698 33714 45729

  1x4 69418 74088 34364 38935
  2x4 88805 102847 113740 108829
  4x4 102406 108110 34672 120161
  8x4 109022 124726 121642 46765

  1x8 62336 68238 71297 68754 
  2x8 104833 115276 118170 44617
  4x8 122292 126075 126101 121306
  8x8 108826 125098 124765 47713

edit: s/pingtest/loadtest/ in the explanation above.

i see no mention of "concurrency" in that article. i see that the go programs make heavy use of goroutines so why were they run in "single threaded" mode? just testing their mqttsrv with various levels of GOMAXPROCS rewards with immediate benefits. here are some numbers for pingtest and loadtest in Go for varying levels of GOMAXPROCS for them and the server:

(pingtest/mqtt gomaxprocs) vs pingtest, reporting "elapsed time":

  1x1  5.8s
  2x1  6.0s
  4x1  6.0s
  8x1  6.1s
  16x1 6.1s

  1x2  5.5s
  2x2  3.5s
  4x2  3.4s
  8x2  3.5s
  16x2 3.5s

  1x4  5.4s
  2x4  3.6s
  4x4  3.3s
  8x4  3.4s
  16x4 3.7s

same thing but for loadtest, reported value is "messages/sec":

  1x1  75521
  2x1  76523
  4x1  77477
  8x1  74613
  16x1 73678

  1x2   71439
  2x2  100571
  4x2   93426
  8x2  108938
  16x2  97593

  1x4   71390
  2x4   87426
  4x4   98746
  8x4   99320
  16x4 119692

  1x8   64413
  2x8   87445
  4x8  102953
  8x8  120720
  16x8 106842

(note that the loadtest doesn't look like it takes long enough to be meaningful in its default)

as always with benchmarks, caveat emptor, but in my opinion go does just fine.

literally prior art:

http://research.swtch.com/qart

and this one has the benefit of allowing you to make a qr code with your face on it :)

that's a problem for those using 0 to terminate a string. if you don't there's no issue. you can read DMR's historical perspective on choosing 0 as a string terminator here: http://cm.bell-labs.com/who/dmr/chist.html (critique section)

even the C guys have moved on though, as Go (co-designed by Ken Thompson) illustrates.

excerpt from the author on go-nuts: "Writing in Go continues to be the best part of an all-around very interesting project."

go's goroutines are coroutines :)

i was referring to recent examples such as python 3.0, perl 6, or even, say, apache 2.0. eventually they were usable, but the blood sweat and tears involved did not make for cute blog posts such as the one we're commenting on.

eventually, within the context of the `go vet` tool, the http://godoc.org/code.google.com/p/go.tools/go/types package may be used to analyze interface conversions ("I said I expected interface type A, but I'm using it as interface type B", which is unusual for go programs). i think that answers "yes" to your second question, but I'm not on the go team, so take my opinion with a grain of salt.

short of disallowing interface-to-interface casts, it is indicative of an error and should be vetted as such. the particular case I described earlier was covered by the Go 1.0 guarantee, so it had to be documented rather than fixed.

it wasn't accidental -- it was written on purpose by a programmer (a conversion from Writer to WriteCloser). it was immediately acknowledged as an error and eventually may be caught by the standard code examining tool "vet".