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?

"Core ML optimizes on-device performance by leveraging the CPU, GPU, and Neural Engine while minimizing its memory footprint and power consumption."

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)

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.

Statically typed languages only eliminate SOME things you'd otherwise have to test. In the end, you can eliminate almost anything besides logical errors, however, those are unfortunately a pretty big portion of bugs :D.

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.

> Two decades ago, it was widely argued that dynamic programming languages were more productive because you didn't have to spend time dealing with type signatures. The only reason, then, to use a statically typed language, was for better performance.

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!

> This is the idea that programs will all talk together via unstructured streams of text.

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.

> If you want to convince me about the graphics/ML capabilities, compare it to a 3090 RTX using running Vulkan/Cuda.

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.

I am pretty sure they did, unless he got hired at some VP/Distinguished Engineer level.

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?

Yeah, they only put the fan in MBP to annoy people, of course. It has zero use. Go order the Macbook Air and have fun. Maybe you can fry your breakfast eggs on it too.

Hah, good to know. However, unless you are talking to people from the same domain, it's usually a better approach to spell out things instead of relying on terminology. Concepts and ideas translate much better across domains than terminology.

Oh I am sure judging by how excellent MacBook Pros cool things, having passive cooling will make no difference at all. I mean, during summer I put my MacBook on a large ice block that I freeze over night, this way I can maintain acceptable build & development speeds during the day. Should work the same for the MacBook Air. No?

Not just that. At 5nm there will also be yield problems. I.e they will put the best yield into high end and the worst yield into low end.

This is incredibly vague. There is no "set of rules" that just magically works without thought.

There is just SOOOO much that can go wrong. But one general rule crystallizes itself pretty quickly:

DO NOT EVER MUTATE STATE!

I.e. when you write concurrent code that builds on state mutation, you are opening Pandorra's box. If you want concurrency that people can understand and maintain, write immutable, functionally pure code (same data in, same result out, no exceptions). That is relatively easy to police and enforce, while still flexible enough to solve most use cases. It may however, not be the most performant.

The way the house and senate looks, this is going to be one long 4 years of gridlock. That's the only meaningful thing republicans can do now. Block everything. Make Democrats look as bad as humanly possible, then campaign for a second Trump term (or whoever is not imprisoned at that time, maybe he can tweet-lead the country from prison as well).

For X-Rays? This technology is sure decades away from commercialization, but it could be the way forward in a time when conventional silicon has reached its physical limits.

I wonder why people always think just one step ahead. Science is about incremental advances EVERYWHERE to eventually allow for something completely new. If everyone had your attitude we would still beat each other with wooden rods and use candles to light our houses, because you know... The de Broglie wavelength of light is just tooooo large.

There are probably alternative market segments for your approach. The AWS CLI is generated from the API, not the GUI. That is not CLI first either, but it follows the GIT approach of the CLI being effectively an API.

AWS is big and it keeps getting bigger. However that is not an argument for simplification. AWS does not add features because they don't know what else to do. They add all these features because they fulfill customer demand. Yes, you can come up with a dumbed down version of a cloud and wrap it in a beautiful CLI first approach. This might even work, you know, until people start picking up on it, feature requests come in... And then you are faced with either sticking to your original mission and serving a niche market, or breaking your promise for the potential gains in expanding your market share.

By building a CLI first approach, you need to be very good at positioning yourself in the market and picking the untapped potential. At either side, there be dragons and if profitability gets the better of you, that might very well be end of it.

I would rather have a CLI that wraps AWS or in general existing clouds behind a simple, friendly interface for common use cases. But of course you can't earn money with that.

And you can spend that time thinking about how not to use a message broker... And maybe just use lower level MANAGED services, like SQS or SNS.

Yeah if you somehow manage to freeze all other scientific progress, you would be right. Otherwise, our children will likely never know what cancer even is, aside from history books.

Give it another 10 years or so and we will be able to target any kind of cancer cell and destroy it. A harder task might be to prevent cancer, but in the end it doesn't really matter. It will be like the common cold.