f2f

you're being deliberately obtuse. the uniformity in plan9 didn't mean everything spoke the same protocol, but that every resource could be shared everywhere. you wouldn't want your tv tuner card to talk ascii, but with 9p and a plan9 kernel you could access any tv tuner on the office network as if it was connected to your own machine. indeed on any other network that gave you could login to. that is the part that's sorely missed.

and every single one of those was profitable from day 1!

but the existence of the proposals assumes there were internal discussions, which is counter to the argument that go devs don't care about generics. had anything good come out of that it would've been published in the open. as it stands, the negatives outweigh the positives. hopefully the new discussion will change that, or an entirely new proposal will make everyone see the light.

"The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future."

This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity... Pick one of the four proposals you like :)

no, it wasn't. the go compilers initially came from Plan 9, which hasn't seen any C++ code ever :)

it seems to me that the Go package can easily slot in golang.org/x/unix, where all the extra syscalls not present in the fixed stdlib syscall package go. that's a minor point. if pledge becomes widespread in usage it will get its spot there.

yes, in this case i am language warring for no reason. i'm an unapologetic go devotee but i like rust just the same. i wish people would just get on with things and write software, rather than comment on minutiae on message boards.

Hyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare).

Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.

> Operating systems perform context switches on I/O.

which are very cheap :)

here's the link to the page: http://mirtchovski.com/p9/ocaml/

This is cool. I've written two or three implementations of 9p in the past, the more the merrier :) In the other direction, I ported Ocaml's interpreter to Plan 9. Wish there were more people using it back in the day, but that's what you get from a dying operating system...

9P is cool though. Simple, elegant, working.

the Clive[1] system uses a fork of the Go language which allows readers to close channels (I think it's the most significant difference between the languages, if not the only one):

http://syssoftware.blogspot.com/2015/06/lsub-go-changes.html

--

1: http://lsub.org/ls/clive.html

unless you're dealing with sufficiently large integers computing the intersect between a line and a plane with any robustness is impossible on modern computers with float or double. sometimes when you intersect meshes that have nearly coplanar faces, the intersection might shoot vertices near some infinity because of division inaccuracy.

someone should read Hoare's CSP paper and spend more time thinking, less time making graphs.

I think the term the title was looking for is "Kafkaesque" :)

> What crypto libraries need is usage

openssl is by far the most widely used tls library out there. still, occasionally our collective hearts bleed. what's even worse is you get forks of openssl for each vendor that wants to abide by this government's policy or that. in effect, you have a single bad codebase multiplied n-fold. where's the economy of scale there?

if you're arguing that "with many eyes all bugs are shallow", this has been disproven. if you're arguing that java's tls implementers were crap, well, that's fine. doesn't mean go's are.

you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html

Go's crypto wasn't rolled out by amateurs.

if you want to see the type checker in action see this short tutorial on go analyze:

https://golang.org/lib/godoc/analysis/help.html

> So based on that [3], open source then.

nortel networks. no bugs in the last few years.

yes, it is clearer the Go way. things are up-front and obvious, easier to document, and less error-prone.

although your contribution in snark is much appreciated, you're incorrect.

it's sarcasm. based on the trend we need at least 7 people to be mad about generics in 2016. or, mad enough to write a blog post about it.

COBOL.

This needs more visibility. It appears to be a previously unseen document in UNIX's history (at least judging by it appearing couple of days ago on the TUHS site, and not a couple of decades).

since when is the mainframe not cool?

to run it through its paces try giving it the goroutines output of a large server. https://http2.golang.org/goroutines is a good example.

unfortunately its color palette is tailored to dark terminals: http://i.imgur.com/WqNVjfh.png

also unfortunate is that we've now lost path information and i can't just right-click to open the relevant line in the source. win some, lose some :)

Lovely, I'm going to read. When I was doing my thesis I was adamant that I'd talk about Plan 9. The literature survey kept pointing at Sprite and Amoeba as the two systems that had the most similar goals at the time.

Since then I keep thinking that the term "system" refers to a distributed system of components, something that has grown beyond the single hardware OS paradigm ever since networks were invented. I have a little bit too much trouble understanding why people would not consider Go a "systems language" only because they think a system is a single hardware entity...

his latest book: http://www.gopl.io/

    "finally! it's so ridiculously easy now that everyone will start using it and 
    the world will be roses and meatballs from now on!"

said no one ever.

even the plan9 guys who were the first to do it with alef and libthread didn't feel like they'd solved concurrency in C.

try " fmt.Printf("%.50f\n", .1+.2)"