[kazinator]

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.

[felurx]

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.

[kazinator]

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?

Or, else, what is your point?

[112233]

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.

[kaba0]

Both JS and python are safe from races and corruption, unless you very explicitly go out of your way. JS has no parallelism, and python has the GIL.

Leaks are not a security concern (besides DOS attacks).

[felurx]

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.

[SAI_Peregrinus]

The latter device is very easy to make with a power cord and some wire cutters & strippers though.

[felurx]

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.

[kazinator]

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.

Making safe things unsafe: rusterfuck.