It really can't. Quite the opposite. Writing C-like Java is already doomed from the start. Java is faster than C when it comes to OOP. Unless you product is a highly complex OOP nightmare, C will always beat Java to the curb.

GC is not free. The problem with GC is that you pay asynchronously, while allocations are essentially free. But this asynchronous cost is very very hard to measure and to control. Java does not offer the mechanism C/C++ offer for native resource management. It also doesn't do complex optimizations, most notably vectorization. Number crunching performance will always suck in Java. Even if they add all the optimizations in the world, the simple fact remains: Java as a language simply does not allow you to express code in a performant way. That leave the compiler at a double disadvantage. It needs to essentially "convert Java to C++ and guess the most performant interpretation" (we are decades away from this), and it needs to do that within milliseconds (because its a JIT).

It just makes no sense to talk about this. Use Java for the 99% of your product that is not a hotpath, use C for the remaining 1% where you need pure performance. Simple as that.

* Everyone hates ads. You can try to shove it down their throats anyway by being a monopoly, but eventually this won't work anymore, since there is too much competition that doesn't rely on ad revenue and too many companies trying to block ads.

* Google doesn't have a solid revenue stream besides ads. And it's unclear how they are gonna get one. At least not in the magnitude they need to survive.

* Google faces strong competition on all fronts and all of them, except perhaps Facebook, don't count ad revenue as primary source of income. This puts Google at a substantial disadvantage, amplified by the first point: EVERYONE freakin hates ads

I mean we did a whole 200 years of scientific research. Of course, there is little else to discover. Humans are smart after all.

There are only a "few" obvious questions left:

* Can we generate a black-hole? If so how? If not, where is the proof?

* Can we move faster than light? If so how? If not, where is the proof?

* Are wormholes real? If so how? If not, where is the proof?

* Can we travel backwards in time and if so, how do we do it?

* Where did the universe come from?

* What is outside of the universe? I.e. where does it expand into?

* Are there other universes? Where is the evidence? Can we build a machine to go there? How do we build this machine?

* Can we prevent the sun from dying?

* Or let's start with the basics. How can we predict the weather of tomorrow reliably? How can we prevent our earth from becoming uninhabitable?

* Is the silicon really the best we can do for computers?

But sure, we are done with physics. Let's just bathe in our glory and praise ourselves as gods lol.

Humans are experts at forgetting that "Mathematics does not proof anything outside of mathematics". All we have are models. Are we at the end of our models? Perhaps? But all that means is that we need better models and perhaps even different mathematics.

The best thing universities can do is to instill an understanding of soft skills in people. They should come out of university knowing:

* How important soft skills are

* That they are the differentiator between senior and junior

* How to best learn them (don't hunt highest pay, hunt highest experience gain)

* etc.

That alone isn't sufficient. Germany is built on private insurance (on top of something similar to Canada's government insurance) and it works just flawlessly. Usually they pay everything, you don't need to do anything. You skip all lines at the doctor, can directly go to specialists without asking anyone, etc. And on top of that private insurance in Germany is considerably cheaper than government insurance, while providing like 10 times the benefits.

If I had to name one thing I really miss from Germany, it's private health insurance. This was just like being in heaven.

This is basically a red flag for mismanagement. Even startups can't work this way. You either need to hire engineers who have enough experience to make the right trade-offs under high pressure, or you will likely not survive the long race after initial MVP and funding. However, a lot of startups are not funded for the long run either, but rather to quickly make money for founders and potentially be bought by some large fish, who stamps out competition and replaces the product anyway. So there is that.

Is it? Over the two years they saved, this is about the salary for 100 engineers. Can you replace and maintain all the cloud aspects that AWS provides you with (I mean the ones you actually use) with 100 engineers? Maybe, if they are good engineers (which is kinda implied by the 300k salary tag in the calculation). If it's worth it, remains to be seen. Definitely nothing for any medium sized company.

Dropbox is huge and has a relatively simple, highly optimized use-case, for which cloud perhaps doesn't offer too much. This is NOT the norm. For most companies, no matter the size, building their own cloud is a no go.

> those features are killed off and vanish from the face of the earth?

Don't use Google Cloud then ;).

> but if we consider the absurd premium charged by cloud providers for their services...

Do you have any data on backing this up? This "absurd premium" includes the salaries of engineers to develop it, maintain it, do DevOps, keep the hardware/data centers, do marketing, etc. etc. There is of course a margin, these companies aren't doing it as a social service... That margin is highly variable from service to service and also between cloud providers. Some may not have a margin at all, others may run at a loss. There is not easy "uh everything is overpriced". Most companies will have a VERY hard time providing the offering at the price of large cloud providers. And the simple "back of the envelope" calculations often miss all the work & cost that needs to be done, but you don't know about...

> Well, those "others" doing the work can be employed by your company and you still save money.

Yeah, if your company is really big, then yes. If your revenue is below 100 million, there isn't even room for any discussion on this: Don't run your own cloud, it's not gonna work. Most of the "cons" I see are about misunderstandings of the offerings and failure to navigate the pricing models and picking the cheapest offerings that do the job. If you fail to do even that, how on earth are you going to run your own cloud?

https://developer.apple.com/documentation/coreml

Apple has always been good at running ML on device, as opposed to Google's approach of sending everything to the cloud, then mining all your data, selling it, tracking it, etc. One example is iPhotos, which implements feature detection on-device, while Google implements it in the cloud.

https://www.imore.com/no-apples-machine-learning-engine-cant...

Or for Google: https://www.theringer.com/2017/5/25/16043842/google-photos-d...

(Reading this makes me wanna puke)

The wars conducted by US are questionable at best and a poor example of how developed nations should behave. However, looking at the worst sides of a developed nation and comparing them to the best sides of a dictator state, isn't quite adding up.

Advanced security knowledge is not needed for developing software. What you need is a security team that reviews the work your developers produce. That's it.

> bad algo can almost always be rewritten, leak cannot be reverted.

And while a bad algo can be rewritten, bad software often can not. Bad programmers are a disaster for scalable software projects. A leak can not be reverted, but so can't the product you didn't ship because you hired the wrong people. Or the company who goes bankrupt because you weren't able to ship a product.

Building software with security engineers instead of software engineers is like trying to win a Formula One race with Fighter Jet pilots.

Reversing a binary tree on a whiteboard is certainly a bad question to ask. But I would argue, for all intends and purposes still a miles better indicator about future potential than if someone knows how/why TLS work. Yeah you can read that in a book. I can google it. Useless for interviews.

If you are hiring for a position that requires you to implement TLS, sure go for it. But that is not the rule. And what are you going to do after he has implemented TLS? Will he be able to work on something completely different?

So while I would always use statically typed languages for anything that needs to be reliable, I do not see how this is in any way a necessity. You CAN write reliable programs without type safety, you just have to test things you normally wouldn't have to test (i.e. the lack of type safety introduces a whole bunch of null-pointer style scenarios where you get something your code totally didn't expect but has to deal with).

As for performance. Statically typed languages are usually faster, mostly because we do not have the technology yet to make dynamically typed ones as fast (in the general case). Not because there is something inherently different about them.

However, I imagine the technology to make them on par with statically typed languages will take another few decades. Mainly because untyped languages need sophisticated transformations to be fast. That is the job the human normally does for the compiler in typed languages. Things just fit together and play nicely. With dynamic languages, your get one big spaghetti soup with no structure and now the compiler has to figure out the "intended" types and compile for different estimated function signatures, etc. all while honoring the JIT-style performance considerations (fast startup, low overhead during runtime). This is a gargantuan task that probably will require advanced machine learning before it really takes off.

This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Like seriously, I don't even know what articles like this are talking about. Types are not your enemy, they surface issues early. Yeah you can whip something up in Python and JS, but ultimately you DO have to deal with types, except now you don't have a compiler doing this job anymore, you have to do it yourself... Somehow.

The only thing typed languages need is something like `dynamic` from C#, which automatically boilerplates untyped access with reflection, without cluttering your code. I.e. duck typing is one of the things some languages like Java need to get better at. But the situations in which I yearn for this are far and few between.

You don't think about types, unless you are new to typed languages... It's really that simple. I never have to think about types. Perhaps its subconcious, but its definitely not slowing me down, its making things faster through robust refactoring, auto-complete and welll doh: TYPE SAFETY!

Curious. To me this is the worst thing you could ever do. Talking via streams to say `cat file.txt | grep ERROR | wc -l` is cool. But you could do SOOO much more, if programs would actually output structured data streams. You could connect standalone applications much in the same way as Visual Scripting, where you plug inputs and outputs together and mix them with operators (think of Unreal Engine's Blueprint, just for command line tooling).

It's a true shame that Linux did not develop a well defined CLI metaformat that defined exactly what parameters are there, what's their documentation, their completion, what outputs does a program produce based on the parameters you provide, etc. You could do true magic with all this information. Right now you kinda still can, but it is very brittle, a lot of work and breaks potentially with each version increment.

I think it stems from the design failure to build your app around a CLI. Instead, you should build your app around an API and generate the CLI for that API. Then all properties of structured data streams and auto-explore CLI shells come for free.

Woot? So you are buying a new Fiat Punto and compare it to the latest spec of a Koenigsegg? What are you even doing?

What we need to know is how these perform against previous MacBooks and potentially Microsoft Surface and Dell XPS. those are competitors.

And to be clear: If you are unable to solve these common algorithmic questions that companies like Microsoft ask, then that's not the right place for you to work. This is a tangent, but there are literally thousands of companies that won't require you to solve these problems. The thing is, at Microsoft & co. you don't just do this in an interview. You do it at your job too. We do foundational work in many teams and we need to solve algorithmic problems practically every week. If you are unable to code yourself out of a DP problem or scared of NP completeness and approximation algorithms, then maybe find a different job instead of complaining about the interview process?