0xABADC0DA

> The people responsible are representatives (in one way or another) of the United States of America. Land of the free. Home of the brave.

I don't get this at all... Harvard fellow uses MIT's network surreptitiously to violate the terms of service to download a nonprofit's entire database and then give it away for free, putting them out of business. Gets busted and charged with crimes. Where's the problem here?

Ok the prosecutor may have been overzealous, but we do have an adversarial system and it was Swartz's bad decisions that brought the hammer down. They didn't plant drugs on him. He wasn't doing it to feed his family. Sorry to all the people here that knew him personally, and to whom this is a personal tragedy, but this is not the kind of travesty of justice that you are making it out to be.

If you think you can do asyncMap in Google Go, without casts and without manually collecting multiple return values, by all means show us the code. I would find that really interesting.

Even so why would you write that boilerplate code out each time?

Something like this would work even better:

    result = src.asyncMap { |e| dowork(e) };

Except Google Go returns several values instead of tuples, so you can't just collect all the results as-is. And with no generics it would be annoying to actually use e and the result, since they would need casts. Too bad.

In IE10 the JavaScript is multithreaded... there's a separate thread for JS parsing, compiling, and garbage collection. As far as I know this is the only browser with a threaded JavaScript VM. So the skipping frames is probably because the rendering can be done independently from running JavaScript, and the core in use is probably some quirk like the benchmark creating a few objects on a timer, causing the GC to run on another thread -- that kind of thing can be fixed pretty easily, either by tweaking the benchmark (if it were publicly available) or by Microsoft fixing IE.

I haven't actually used IE10 yet, but I think you'll find this new architecture makes overall browsing more responsive and smoother than Chrome.

The real problem is the software libraries are just as hard.

Take OpenSSL for example... it's almost easier to learn the crypto than to figure out the API. Here's a good one: an SSL read/write operation can fail with more than one error, and if you don't clear or loop through all the errors then the next operation will fail because of the previous errors -- even if it succeeded. Or just try getting it to work with non-blocking sockets, you finally believe it is working and surprise it fails only once the network gets saturated. Or hours later when it renegotiates the crypto.

And you still have to know all the crypt terms to use it. What's a PEM? A BIO? PKCS? DHparams? What's "ASCII armor"? X509? Did SSL_library_init() add weak algorithms? Why do I have to know this just to create a secure connection?

Most of blame for crypto problems belongs to the libraries not the developers using them.

The only actual proper thing in this whole affair was Apple's lawsuit. As Samsung was copying them right down to the shape of the charger Apple felt they had a real case. They lost, but disputes are supposed to be settled in court when the parties can't come to an understanding.

- Samsung slavishly copying Apple's designs

- The Judge issuing a order designed to embarrass Apple

- Apple posting a snarky letter of the law notice

- Hacker News posters like in this thread

...these things are childish and immature. Grow up.

> Sure you can. Spawn a child process ...

This is exactly what I was talking about. You can't even admit facts like that Java has dynamic loading and a security model and that Google Go does not. You're simply delusional in this respect.

> > On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go.

> Depending on what you mean by "do" ...

Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't.

These may not be the wisest or most useful of features for "systems" programming, but you have to admit that there are real things Java can do that Google Go cannot.

I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh".