0xABADC0DA

13 ms·

61.
by 0xABADC0DA 14y ago
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
62.
by 0xABADC0DA 14y ago
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 sai
63.
by 0xABADC0DA 14y ago
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 inst
64.
by 0xABADC0DA 15y ago
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 tha
65.
by 0xABADC0DA 15y ago
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 readin
66.
by 0xABADC0DA 15y ago
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 menti
67.
by 0xABADC0DA 15y ago
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 t
68.
by 0xABADC0DA 15y ago
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
69.
by 0xABADC0DA 15y ago
> 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 exasperate
70.
by 0xABADC0DA 15y ago
> 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
71.
by 0xABADC0DA 15y ago
> 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 l
72.
by 0xABADC0DA 15y ago
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 th
73.
by 0xABADC0DA 15y ago
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 i
74.
by 0xABADC0DA 15y ago
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.
75.
by 0xABADC0DA 15y ago
"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 'peop
76.
by 0xABADC0DA 15y ago
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
77.
by 0xABADC0DA 15y ago
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 g
78.
by 0xABADC0DA 15y ago
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 sh
79.
by 0xABADC0DA 15y ago
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.
80.
by 0xABADC0DA 15y ago
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
81.
by 0xABADC0DA 15y ago
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 p
82.
by 0xABADC0DA 15y ago
> 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 dict
83.
by 0xABADC0DA 15y ago
> 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 algo
84.
by 0xABADC0DA 15y ago
> 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.
85.
by 0xABADC0DA 15y ago
> 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 argumen
86.
by 0xABADC0DA 15y ago
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 des
87.
by 0xABADC0DA 15y ago
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 th
88.
by 0xABADC0DA 15y ago
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
89.
by 0xABADC0DA 15y ago
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
90.
by 0xABADC0DA 15y ago
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 devel

More ›