Problem is, it can't go where you need it to go without any concerns. There are problems doing that whether you ignore them or not. I should be able to plug whatever I want into an electrical socket and not have to worry about whether it'll start a fire, but I can't.
This is a solved problem. There are situations when the solutions don't work, but they are subject to the 90/10 rule. Or 99/1 or whatever is applicable.
There are almost no application domains in which you need to conform to some insane borrowing protocol for the entire software.
Your analogy is stupid beyond belief; and terms of the safety of the circuit itself that is behind the outlet, yes I can plug in anything without worrying there will be a fire in the wall. I live in the first world, where we have electrical codes and circuit breakers.
I think there might be a misunderstanding here:
The analogy works precisely in that you can't plug in anything dangerous because the electrical codes make it so that dangerous things don't exist, and because circuit breakers protect you from malfunctioning stuff.
You can't plug a device that pulls 10kW into a plug and have it work, because the circuit breaker stops you from overloading your circuits.
You can't plug in a device that attaches the live to your left hand and the neutral to your right, immediately stopping your heart, because such a device is forbidden by electrical codes, and everyone who makes electrical devices has to follow these.
Are you saying that memory management under which I can confidently any object anywhere in the program without any puerile borrowing protocols isn't safe?
Yes it is not safe. Just because you do not access undefined memory in an untyped GC language like javascript or python does not mean you can enforce that program invariants are maintained. You still get resource leaks, races, corruption etc. just without a crash (which makes it arguably worse because the defect is not immedeately apparent) Encoding program invariants cannot have "correct" solution, because you must balance expressivenes with compile time decidability.
I'm not saying that borrowing protocols are the _only_ way to get memory-safe programs. But aside from that, yes exactly. How memory management in C/C++/... works is not inherently safe, otherwise we wouldn't have all the memory-related bugs we have. Of course, you can write memory-safe code, but adherence to borrowing protocols can guarantee that your code is memory-safe, or at least reduce the risk by a lot.
And you can use `unsafe` in Rust, code up all sorts of memory-unsafe stuff and have it blow up in your face.
In both cases, it should be clear to you that you are behaving in a possibly dangerous manner, that you should know what you're doing and that you are responsible for not endangering others with whatever you're doing.
In a sane language, you can hook up objects in a graph structure with cycles and pass the whole thing (or any portion thereof) wherever you want without having to abandon safety.
A new conception of software freedom: free from the constraints or considerations of reality. Where it’s not the code that’s unsafe, it’s the thinking about and addressing its safety that’s harmful. Kill your gods but don’t let the compiler ever figure it out!
Lol I’m not a Rustacean, I’m amazed I’ve gotten any Rust to even compile some of the times I’ve tried. I was riffing on probably poorly fit sayings, but definitely not as a Rust partisan.
Yeah; I'm pretty sure parts of firefox have already been rewritten in rust. And there's a project at google to start adding rust to chromium too[1].
> Ownership is completely inadequate for operating systems.
The linux kernel is adding rust support as a first class language. In time I wouldn't be surprised if large parts of the linux kernel were written in rust. Obviously linux will always have a lot of unsafe code, but unsafe is part of rust too. Its surprising how infrequently you need it.
Big tech companies do use many languages. Sometimes smaller one as well. I deal directly with at least 5 at the moment. C++ is in this set but no Rust so far as I do not have business case for it. But do some reading to be aware.
>"What other recent language is used by all large tech companies."
What on earth constitutes "recent" language and where did you se me mentioning "resent"? Anyways, does C++17 qualify? What about PHP8, ECMAScript of latter editions, newer versions of C#, Java etc. etc. ?
If I understand your thinking correct let me help you with your question: what native high performance language with no GC, memory / lifetime management and with the stable release after 2015 is used by all large tech companies. Nice try.
Also what FAANGs do with their choice of tech is their own worries. They have needs that will never be encountered by majority of the rest of the world's programming.
Yes and no. The aggressive marketing is successfully entrenching it to future generations so whether it’s successful with the current gen of c++ programmers or even GC languages like Java doesn’t really matter imo.