I do. I've interviewed twice and gotten offers twice (and declined twice). That's what I said in my post. I'm claiming no greater (but no less) knowledge than having gone through the interview process.
Are you implying that because you went through a couple of good interviews with them, and because one director who works at Google said that they don't hire this way, it doesn't happen?
That's the worst logic ever.
I'm blaming Google for doing this, and you take it to imply that I said you work at Google? Maybe you didn't accept those offers from Google. It still doesn't mean those things didn't happen at Google - and it is extremely shameful that you resort to defending them.
Congratulations, what you have done is just free PR for Google. I'd rather listen to everyone else than you.
They were finally getting to have a fully built out environment - which could lead to better end user packaging, stripping down a library to its bare essentials.
For instance: what have jpackage achieved for a distribution like RedHat? Does anyone's Java App even pick up these RPM based dependencies for Classpath? Heck no.
Every known large scale Java application pretty much bundles a bunch of JARs. (Probably not logstash - but only one exception)
It is very clear that JDK9 will not be as awesome as it was originally supposed to be. Deeply disappointed.
> I don't think some people realize the value of a hard day's night.
What do you mean by a hard day's night? AFAIK this expression was invented by the Beatles for their eponymous song and means something like "a rough day". But that doesn't really make sense in the context of your comment so I'm wondering if there's some usage that I (and a quick googling) am unaware of.
No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster.
If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.
If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data.
I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how.
I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
“However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.”
That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services.
That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.
Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling!
I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.
Fact that it supports mathematics so well is quite handy. Question is though, does it allow me to develop my game without people needing to download additional plugins?
Oh sorry, I think we have a miscommunication. What i mean is, doesn't compile Scale to java? So doesn't that prevent people from playing the game in their html5-enabled browser in case they don't have a java plugin or sth similar?
Real mature, Google.