Also achievable, and far more easily, with a tracing GC. Do you know all those people worrying about memory safety in Lisp decades ago? Me neither.
But the compiler does quite a bit more than just allow for performant memory safety. It enforces rules around mutability and handling errors which are usually only seen in functional languages.
None of these things are special about Rust. The special thing is that Rust can do these things with less computer resources while asking more of the programmer.
And this is a general truth. Type systems add friction and force programmers to deal with details from the very beginning. In the long term this might often be a good thing, but it certainly isn't ergonomic.
In Rust, I agree, but I find coding in C#/F# which are decently typed, but with GC, is much faster for me than using e.g. Python. Typescript is much easier than Javascript.
Lack of types usually leads to worse auto completion, errors maybe only found on some edge cases which I didn't try and a huge slow down if I need to add a feature when I've forgotten about the code, since they provide a lot of documentation where you know that it's not stale.
I wouldn't use python at all if it didn't have pandas.
At this point I only use python for pandas and matplotlib, or for sending small psuedocode snippets to coworkers
I get where you are coming from but I would argue that there is a bit of a perception issue here. You can surely write fast in typed languages but you also have to write more and think more.
But I fully agree with the benefits. Errors, changing/refactoring and documentation.
I wonder if we can have the best of both worlds some day. Prototype dynamically and then add types and abstraction progressively in the same language and code base. In theory this is doable with Lisps, but only in a self-imposed, possibly unstructured way.
That's not necessarily true. It lets you do it without a tracing GC, which is marketing genius. Whether or not it's more performant depends. A lot.
> It enforces rules around mutability
These are more needed due to achieving memory safety in the absence of a tracing GC. I like its rules for this; I'm just saying that they're a necessary consequence.
> and handling errors
I prefer exceptions myself. But one can write library types that force the user to handle error cases in other languages. It's not as nice as when sum type support is baked in, of course.
Rust is not alone in this. I think Pony is a good example.
Embedded devices, depends on the use case, PTC, Aicas, MicroEJ, Astrobe have plenty of happy customers.
Same applies to OSDEV, Midori did not have any big problems powering a couple of Microsoft systems before the powers to be decided it wasn't going to be a Windows replacement.
I will believe that when I see the performance under load with my own eyes, and when I can convince myself that the code is not more cumbersome than manual memory management would be.
You somewhat need the option to atleast manage some memory very very manually. And of course, the GC needs to work without allocating memory (ie, true in-place GC) otherwise you're going to blow of your kneecaps of fairly spectacularly (this goes double when you need to initialize memory management, which can't rely on a memory allocator being present or free memory being available)
The only thing missing is having companies like Apple and Google are doing with their mobile OSes, "my way or nothing".
Usually those that have enjoyed GC aware OSes know what they were capable of, and those that never have, think they know how bad they were.
l1 = [1, 2, 3];
l2 = l1;
l2.push(0); // Oops, I also modified l1, was it expected?* Calls to C functions (which can't be checked for safety)
* Cycles or mutable access which can't be checked for safety by the compiler
* Performance-sensitive code, which ignores bounds checking (again, which can't be checked for safety by the compiler)
The point of `unsafe` is to fence in the memory danger into the smallest possible points.