0xABADC0DA

No, Microsoft wrote a 'different book' -- .NET

What Google did was remove a chapter here and there and add a couple of their own chapters -- in this book analogy, clearly copyright infringement.

The actual quotes used in the slides is "you form an API using those parts of speech in the same way I'd write a technical paper using, you know, nouns, verbs, objects, so on." In other words, you couldn't copyright java.lang package name itself (an adjective say) but you could copyright the collection of everything in it (as like technical paper).

I'm astounded that this is in Google's slides. Slide 12 basically says the Java API, taken as a whole, is copyrightable.

Finally got around to reading the slides from both sides... wow Google slides are so weak. Their four points:

- Sun gave Java language to the public

They basically just say APIs and programming languages are the same thing, and Ellison said the programming language is free for everybody, therefore the APIs are too. Their quoting an expert saying that an API is like a technical paper is bizarre, since technical papers are clearly copyrightable... Google basically agreed (slide 12) that an API is copyrightable.

- Google built Android using free and open technologies

Basically saying other people did it and Sun didn't sue, so it's ok for us to do it. Also another defense that, ok maybe they did what Oracle claims, but even so it's no big deal. The 'me too' and 'meh' defenses.

- Sun publicly approved Android's use of Java

The defense is that Sun approved the announcement of Android as a Java-based platform, which Google says it isn't. So Sun didn't approve of Android.

- Google made fair use of the Java language APIs in Android

The defense is that Sun was incompetent so Google had the right to go it alone without Sun's approval or license. Seriously?! Their quote to support this from Ellison even talks about licensing Java to phone carriers -- why would they do this if Java was free? Their own evidence presented undermines their argument.

Meanwhile the Oracle presentation is chock full of damning quotes and evidence from Google's own people. Google better have some serious kung-fu in the trial part, because the opening statements are a disaster for them.

The point is that it is threading/simultaneous execution that is the big deal. A language designed around some 'concurrency not parallelism' slogan has missed the boat... concurrency was never the problem that needed to be solved.

For instance in golang the only support the language has for simultaneous execution is a threadsafe queue -- that's all. And the runtime libraries only have variations on mutex that you even have to manually create locks and manually remember to unlock them. This is extremely weak sauce for a 'concurrent' language.

Single-threaded concurrency was never the problem to begin with and it's used everywhere, in specific forms. Even C has it... for instance in your example printf formats to a buffer and writes at some later time, which is concurrent in that the next numbers can be created and formatted before the first is printf operation is complete.

But the reason almost nobody uses any of the general forms of this concurrency (coroutines, fibers) is because the general case of this is as useless as it is easy to do. For instance there are plenty of C coroutine libraries (including Russ' libtask) and they work fine. The reason nobody uses them is the because the situations where this is called for are precious few.

The other day on reddit Ian of gccgo even butted into a conversation about 1:1 threads vs m:n threads, but could not muster up an answer as to what conditions m:n threads (ala goroutines) would be called for. Simultaneous execution (threads for example) was always the hard part and any talk about concurrency that isn't about simultaneous execution is just tilting at windmills.

For instance:

http://www.cnn.com/2011/TECH/mobile/05/12/google.maps.androi...

Or:

http://en.wikipedia.org/wiki/Google_Maps

> It is annoying because it is incorrect

Maybe some English professor, technical writer, or journalist reading this can chime in and explain how so. It seems to be the standard practice and I intend to use the best grammar and construction that I am capable of, as bad as that may be. This isn't Twitter.

I suppose you fail to see the irony in complaining about me writing "Google Go" because "Go" is an unsearchable name and then answering how to search for it with a custom search engine, needed because the name is unsearchable. Not to mention that ctrl-f doesn't support regular expressions so no ctrl-f "\<Go\>".

I only use that construction with ambiguous or unsearchable names (for instance I would also say Google Maps). I don't think I am along in using this form and I feel it is appropriate to refer to Google Go this way.

Frankly I fail to understand why this bothers you so much, as it clearly does. I would expect Google Go advocates to be delighted to have Google's good reputation for engineering imparted onto this language.

It's amazing how nonchalant they are about this 'oh sure we'll fix it in a year or so' when the garbage collector is basically all there needs to be in a Google Go runtime

Some comments were asking why early Java's GC wasn't this bad even though it was conservative. The reason is that Java can't take references to fields of an object, so the data mistaken as a pointer has to actually point to an object header. In Google Go you can take a reference to a field, locking the whole object, so the faux pointer can point to any field as well (or in this probably any location in the object). Not exactly the wisest choice in semantics, as they are seeing now that it complicates the GC.

Ok I understand that you can switch to a larger stack to call C code, although as I said you can't "just call normal C function directly". You can even discount the cost to acquire it by having it stick with the thread using it (no locking, alloc, etc after the first use).

That might be ok for Rust where many 'tasks' might be computational only and never call a C function. But with Google Go, I think they said "we want to have a million threads each reading a socket" or some other arbitrary limit which isn't possible in 32-bit using system threads (even with segmented stack).

Does Rust do it's own threading, and if so what are the advantages you perceive to doing so?

> I think with the increasingly desperate tone in your writing, its not hard for people to realize that you're just hating on Go, and at least the responses to your misinformation are educational, and often interesting.

I get exasperated is because you guys rarely ever back up your claims. For instance, the response I get to what changed is 'things'. What things? Did synchronization between threads get 100x more expensive? Does unpredictable blocking like from page faults no longer happen? Are real time and consistent scheduling no longer important? What 'nature of problems' changed?

> You're not taking into account the fact that the C code cannot be allowed to block the main loop of the program; as is true in any event driven system.

Why can't the C code block? Because they do their own M:N threading and segmented stacks. Why do they do that? To run on 32-bit without complications. That's exactly the point I've been making.

Why in 2009+ care about a 32-bit implementation? Like I said originally, good question.

> Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information.

The links for Ingo and Ulrich worked, these are enough of an indictment of M:N threading. What's changed in the last decade? OS gurus tried M:N threading and it failed. Java tried 'green threads' and it failed, and now Google Go devs are trying the same thing. Guess what's going to happen?

> Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads

Erlang was written in Prolog and the desktop VM was single-process until several years ago. That's not a good example implementation to base a design on for a new language. Meanwhile the good things like separate heap/gc per 'thread' weren't copied. /forehead

> did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop.

I don't think I know of another language that locks another thread, transfers control to it, and then finally calls the C function. That's crazy talk -- why they say "down the rabbit whole" in that comment. Most languages do some type checking (for instance error on passing a BigInteger > uint32_t to a function taking uint32_t) and marshall the arguments then call the C function. Maybe they need to pin an object or convert it to a C-friendly form (make a struct that describes properties of the object). But yeah in general the C interop is very simple in most languages.

> And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript...

I don't say "Google Dart" because Dart isn't an unsearchable, ambiguous name for a programming language. I do say "Apple Blocks" because 'blocks' is unsearchable in the context of programming languages. You can't blame me for Google choosing a terrible name.

Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted?

> There are many more system resources associated with threads, most of them are more important than mere virtual address space consumption, like context switch time and thread creation time.

I think you should read the M:N scheduling links. I'll leave it at that.

> Calling C code is very fast and it's trivial to do from Go, http://golang.org/doc/articles/c_go_cgo.html. Segmented stacks are available in some C implementations as well.

http://golang.org/src/pkg/runtime/cgocall.c

Read the comment at the top. Hardly trivial.

> It's not Google Go, it's simply Go, there's not a single Google reference on the page and that's intentional. Looking at your previous posts I see you have an obsession with Google. ... In short, you have absolutely no idea about what you are talking about and you spread malignant misinformation.

Shoot the messenger. Maybe I post from a different account when I am critical of Microsoft, or Apple. Why would that matter to you?

Or in other words "you're wrong because I said so. upvotes please!".

Thread count vs stack space is a well-known tradeoff in 32-bit. It doesn't take a rocket scientist to know this is the reason for segmented stacks in Google Go even if there's no smoking gun (wayback didn't archive the golang site for a long time due to a misconfigured robots.txt).

From the horse's mouth:

http://golang.org/doc/go_faq.html#goroutines

When they say "system resources" they mean stack space. It's limited in 32-bit because a stack large enough to be useful takes up too many virtual address space. For instance an 8 MiB stack takes up 1/512 of the 32-bit address space so you can only have max 512 threads, but in 64-bit you can have 33 million (current CPUs limited to 2^48 address space)

So they segment the stack in Google Go to get more than some small number of threads. Even though Linux (edit: the kernel) only uses 4k or 8k per thread some OSes have severe limits, so they compound the segmented stack problem (making C interop slow and cumbersome) with userspace threading (M:N). A collection of links why that's a bad idea:

http://www.kegel.com/c10k.html#1:1

Eventually they'll concede that this wasn't a good idea, but I wouldn't bet on when.

It's not an advantage at all.

Google Go uses syscalls directly because its threads ("goroutines") were designed for a 32-bit architecture so their solution to not running out of virtual address space was to use small stacks that can grow. But that means it can't just call normal C function directly because there may not be enough stack, so they have to reinvent libc on every platform they port to. Meanwhile virtually every desktop is 64-bit and even ARMs will soon be 64-bit.

Why design a new language around 32-bit computers? Good question.

"JavaScript is part of the web now." It wasn't before? It's acceptable to have completely blank pages with no content, JavaScript 'or else'?

"It's because people like interactive content". And Google put '+' into everything because 'people like social', not some plan to compete with Facebook.

"some conspiracy to DRM their corporate advertising blog." Because clearly I was talking about a single blog.

"proxying works fine for SPDY" A SPDY -> HTTP proxy. When there's a SPDY-to-SPDY caching proxy and no man-in-the-middle you might say it works fine.

...that's a lot of spin from a Google employee. Maybe I hit pretty close to the mark.

They are making their properties require scripting, they threatened that javascript "would be replaced" with something that can support massive codebases (dart), and they have new protocols that use a persistent connection that can't really have a proxy between you and Google (Spdy).

I'm sure some of these came about organically, but they all contribute to moving from a publishing model (web 'pages') to an application model. Basically Google is making the web into an application, but like modern DRM in games, you have to be 'online' signed into google all the time to use it.

Make it personal 1:1 with google by killing proxies (require TLS like in Spdy), kill pages by requiring scripting. Result is a Ubisoft for the web. This is I think pretty clearly the destination that Google is pushing towards.

So you have a group of trolls that all upvote each other's comments. Unless the system also penalizes upvotes then they get disproportionally too much karma. And if the system does penalize upvotes then somebody that always posts really great posts gets too little visibility because his upvotes look trollish (ie maybe they come from the few people that really recognize an expert in a small domain). It seems that an automated system is always going to promote mediocrity.

I'd like to see anonymous upvotes, but when you downvote you have to leave a comment or it says 'downvoted by UserName' (maybe only for negative-karma comments).

It turns a downvote from 'I disagree' to 'I disagree and everybody else you should too'. You have to be willing to risk your own karma to take away somebody else's.

For instance the way HN works now afaik, somebody could post 'me too' comments to get enough karma to downvote, then turn around, downvote all posts supporting some idea they dislike, and there would be no way for other posters to correct this or know it was happening.

It makes them 69x the size of Microsoft in contributions to humanity and 270x the size of MS in dignity. I feel that Red Hat contributes more to OSS than all the big software companies combined, even including Apple.

I find gcc usually spends about 80% of the total compile time in optimization with -00 as a baseline (which despite being 'no optimization' actually does some optimizations). This is just C code.

Optimization takes a massive proportion of compile time these days. This is something the Google Go designers didn't understand because they had been programming for decades using a mostly unoptimizing compiler (for plan 9).

You are correct, the paper does not compare to compression with a null prefix. In haste I read it wrong, since it was not too far off from calculations I had done previously in a reddit discussion where I found ~100 bytes saved using the prefix dictionary. Thanks for being persistent and I'll see if I can rerun their data using a null prefix before the next Spdy thread, but I doubt it will show more than 200 bytes total savings per connection, which doesn't change anything IMO.

> So, just for Google alone that change could save on the order of 100GB of traffic per day

So say $150 dollars/mo? Or 0.00002% of their profit/year. Come on.

> I don't think the paper provides statistics on how much a prefix dictionary saves over not having one at all.

The paper compares plain, deflate, and deflate + prefix dictionary. Prefix is only a benefit on the first request and response, adding up to 121 on average in their test.

> I was under the impression that even though TLS has the idea of built-in compression, in practice, that is never actually used.

This is determined mostly by the browser. Most browsers in TLS ClientHello send an empty compression algorithm list since they will use encoding headers (which let the servers cache the compressed data). A browser using Spdy could indicate it supports deflate to enable compression.

> Also, you claim that Google is basing this protocol on assumptions and you imply that they do not understand the value of metrics. I strongly disagree with this sentiment

Watch the tech talk video the other guy posted and drink when they say 'we assume' or to that effect. These guys do testing to confirm their assumptions. Take a look at when a questioner asks about high packet loss and how they hand-wave away Spdy being crippled by high packet loss.

> because SPDY headers are length-prefixed for ease of parsing. It compresses better when the prefix is included in the dictionary; such that {0x00,0x00,0x00,0x07,o,p,t,i,o,n,s,} would compress to one byte, not 5

No, wrong, that's not how compression works. Deflate uses lz to compress runs and repeats like \0\0\0 and it uses huffman to better encode it to bits.

Here's a clue for you, compressing "\0\0\0\7options" using deflate:

    spdy prefix: 7 bytes
    w/o repeats: 6 bytes
    w/o any counts: 6 bytes

The first is the rfc draft dictionary, the second is that with only the first occurrence of each count, and the third with on \0\0\0 at the start and no other counts.

Not even to mention there is limited space in the prefix due to the window size and it sliding, so not only are the counts basically useless but they use space that could be used for other data.

I take it back... these people don't just lack rigor, they are clueless bordering on incompetent. As just an implementer I can accept that you don't completely understand the issues and are excited to work on the implementation, but as protocol designers from Google the work done with Spdy is just unacceptably bad.

> Browsers won't keep SPDY connections open forever in the hopes of someday reusing them; the "initial connection" case will happen quite frequently in a normal browsing session.

This is what boggles my mind about Spdy, the dissonance. On the one hand Spdy is great because it does a bunch of requests on the same TCP connection, but on the other hand Spdy is great because it saves 100 bytes per connection and that's a big deal because there are going to be so many connections made? It doesn't make sense.

Spdy is great because it has compression, but on the other hand Spdy is great because it requires SSL which already has compression. Huh?

> I suggested the hopefully very common case of sending a very small request and getting back a very small 304. ... The whole exchange consists entirely of headers ... That would make 121 bytes closer to a 30-40% savings.

On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things.

> (Also, I'd love to see a reference for your figures on expected bytes saved through the prefix dictionary.)

http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf

The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal.

> And when the entire exchange consists of a few hundred bytes (which the server can answer with a 304 Not Modified), that seems like a substantial win. What argument do you have against doing this?

Turn this around. What's the argument for doing it? "The gain using our proposed initial dictionary is seen only for the first header". This is completely counter to the goal of Spdy to keep connections open and reuse them; the longer connections are used the less the initial dictionary matters.

Even just visiting one page, average say 500 KiB, it save on average 121 bytes total. That's 0.02% reduction in size. This seems like a "substantial win"?

Meanwhile how many version of the dictionary are there so far? 5? 10? And they propose that it will evolve over time, so that will just keep growing with software everywhere having dozens of legacy dictionaries.

> Also, HTTP pipelining requires answering requests in order, while SPDY doesn't, allowing the server to respond to requests as data becomes available.

This is why metrics are important. By ignoring pipelining because of perceived problems, the authors are basing their protocol on assumptions. This assumption is that in the real world the 'head of line blocking' is a significant factor. Judging by 0.02% average gain from prefix dictionaries, I don't give them the benefit of the doubt that their assumptions are correct. But I see that Chrome 17 has some type of pipelining support, so maybe they will actually test this someday.

> If I request a page generated by an expensive CGI, the server can go ahead and send me the CSS and JavaScript it knows all pages will reference ...

Yes if the very first request is an expensive CGI this may be some marginal benefit. I think even the Spdy designers claimed this was less than 1% and sometimes a loss. This happens very often, that the first page requested from a site has some really slow loading CGI? I think the site is broken.

There are some problems in HTTP pipelining. Nevertheless Firefox and Opera have pipelining implementations that work and are significantly faster than HTTP with keepalive. It's enabled by default in Opera.

The point being that they've designed this new protocol based on their assumptions and hunches. Same lack of rigor is present throughout the whole spec -- take a look at how much redundancy is in the prefix dictionary for instance.

Still has a prefix dictionary. The benefit of the prefix dictionary over starting from scratch is extremely marginal (about a hundred bytes on the first request).

Still making claims comparing to HTTP without pipelining. After how long they still haven't even compared to pipelining (because Chrome doesn't do pipelining, is Firefox is banned at Google or something?)

Still has server push. Read the spec at how complicated this is, all to save one one-way trip.

Still hardcodes parts of HTTP into the protocol.

...gross.

I believe this is one step in transitioning away from 'pages' to something more like apps, where they load and you interact with them through UI and state instead of links. They've already made it basically a requirement to have JavaScript enabled on their sites (for instance Google + is just a blank page without JS), and if you read the Dart leaked memo they seem deathly afraid of smartphone/tablet apps.

Seems believable to me anyway... for instance I read mail almost entirely on my phone now and never log into the gmail.com. Since I'm not using their mail app I never see their ads.

This is kind of neat to get named arguments in C as well.

Instead of calling:

    foo_init(1, 'a', 1.0);

You can write:

    foo_init(.arg1=1, .arg3=1.0, .arg2='a');
    foo_init(.arg3='c');
    // etc

edit: didn't see this in the blog comments, wasn't trying to steal credit ;-P

Spdy is not great.

For instance header compression using a shared prefix dictionary saves only a handful (~100 bytes) over TLS compression -- worthless, not to mention it's already had several versions of the prefix dictionary.

Spdy developers didn't even test against HTTP tunneling, which in practice as seen in current Firefox and Opera works just as well. The 'head of line blocking' is not a big deal in practice.