marta_morena_28

> "but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs."

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.

That's all well and good. However it still doesn't address three key factors:

* 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

Amusing. It's like a cavemen saying "Yep, we are done. We made fire ourselves, what else could there possibly be?"

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.

Confirmation bias to the fourth power. A person just told you that an average truck of which you see plenty on the roads, does a couple thousand times the damage of a car and your response is: "Let's get all the cars of the road because a bicycle does no damage at all compared to cars"

I would argue: There is NO shortcut for experience. But not all experience is created equal. Telling someone HOW to do things right (we are talking soft skills, for hard skills its a bit different), is not helpful. You need to expose them to situations where they have weaknesses, and then coach them how to overcome the problems they face. I.e. there is a fine line between "telling people what to do", which is ineffective short-term and contraproductive long-term; and "exposing people to situations that make them behave wrong", which is the most effective learning tool, that doesn't have drawbacks, outside of the short-term (because you know that this person will not do the job right, but you also know they are not going to do it wrong another time, plus they will learn how to recognize other similar situations and avoid making this mistake there as well).

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.

Probably, but that's still about 10 million people with private insurance, which is 1/3 of Canada's population. The point is, private insurance doesn't have to be a nightmare. That is not the only factor. Actually I think private insurance generally had the potential to be much better than public insurance. However there seem to be a number of additional factors that make US private insurance such a nightmare.

> Privatizing seems to make for too much economic specialization

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.

Any company that wants to survive long-term doesn't do that. So go work for those instead. Companies who treat code this way aren't software companies, and they ain't gonna stick around for the long-run. They just use software for some end, and given their apparent lack of attention to detail, they will go out of business pretty soon. That is the majority, unfortunately.

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.

> 75 million dollar price tag is also huge.

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?

Does it? What if the US had Iran's military and Iran had US' military?

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.

Bias finds its way into every corner. And no, it's not safe unless you do some extensive analysis of the certificate in question. Is this actually a valid/genuine certificate, besides the timestamp? A normal user will have a hard time verifying that.

You don't need to know much about security to write safe programs. Most of the work is done by others. You need to know how to avoid common pitfalls (i.e. yeah, if your service uses 3rd party code to parse customer provided data and your colleague suggests using this awesome C++ library for it, maybe some alarm bells should go off).

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.

That doesn't make any sense whatsoever. You do not hire someone because he knows about a certain technology. You hire people because they will provide long term value to your company and are able to adapt a rapidly changing technology space.

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?

Fixing an issue around being unable to pay with a credit card is likely anything but a 30 min issue, unless there is some triviality happening, like a config issue. But even then you need to add tests for this. A day or two is the absolute minimum and that would be if this is just a config issue. If it's not, then think of weeks.