[flagged]
With Rust, only the unsafe blocks are in scope. The point of Rust is not to eliminate unsafe code, but to make it not scale with the size of your program. There is no good reason for those to be coupled.
We’ve sent rockets into space running C/C++ and assembly. And that was long before C++11 rolled around.
I’m wondering because: man Rust is an ugly language. C is not perfect either, but it’s still pretty close to what it was FIFTY YEARS AGO.
Fast forward to now, and all we’ve come to is Rust? I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.
Another thing: why do we write pseudocode and not design languages to look like pseudocode? With Rust and modern C++ compile times you’d think the machine is parsing prose and turning it into assembly…
many of those who ended up as Rust developers came from C and C++, seeing improvement from what they were using.
languages have been designed more and more to allow for higher level behaviours, in Rust's case, although not pursuing psuedocode, generally allows for very high level abstractions. regardless the computer still has to run things, languages are typically deterministic in their handling and psuedocode leaves much undetermined, unfully specified.
Just playing devils advocate it seems higher level behaviours don’t belong in a low level language.
in some respects, rust is not all the way there for high-level work, but great strides have been made to make it pretty darn close.
a talk from dioxus on the state of high-level rust: https://www.youtube.com/watch?v=Kl90J5RmPxY
having a single language to do your work in, although i personally don't subscribe to it (and am a fan of clojure, guile, C, C++, Rust, Zig, ... all without this feeling to be a contradiction for me) minimizes cognitive overhead and also reduces the quantity of interfaces you need to concern yourself with to manage interoperability. the borrow checker and type system to a seasoned rust user are not a bother regardless of the work they're doing, so it's not like that presents a unique problem.
avoiding garbage collection, avoiding the CLR, whatever overhead comes with it and the joys of .NET Core or overheads of clojure + jvm compiles can certainly be worth it (a clojure project of mine spent 33% of its runtime on java+clojure compilation!)
the lower level work being performant means that your well-designed interfaces can also run well.
No, because what people don't realize is there is a constant influx of people who are new to C and don't know how to use it and how to fix memory related issues, so you can't just train everyone to not do them -- newbies by definition are untrained. The only winning move is to encode best practices into the compiler to make it hard for newbies to load the footguns, and only put them behind a bunch of warnings and features that experts can navigate.
I think that period has arguably already come and gone. C and C++ have been the most popular systems languages for decades. I think it's clear that mere popularity is not sufficient to produce memory-safe software with those languages. If anything, those languages are experiencing somewhat of a renaissance these days and it's these more recent developments that end up producing improvements with regard to memory safety.
> I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.
Bit of a nitpick, but I think you meant "latter" instead of "former".
That aside, there's more to picking a language to use than just memory safety and the ability to perform "unsafe" operations. Take your pick from more technical reasons (zero-overhead FFI to C, low-level control over data structures/operations/runtime, etc.) and more "soft" reasons (language affordances/features, ecosystem, etc.).
> Another thing: why do we write pseudocode and not design languages to look like pseudocode?
Perhaps COBOL might be what you're looking for? :P
As with many things, language design is full of tradeoffs, particularly when you want to produce something that is not too unfamiliar to a certain audience. IIRC another factor is that languages that want to work well for "experts" will tend to favor different points on the design spectrum. Consider APL-family languages - those are completely incomprehensible to anyone not familiar with them, but that same terseness is highly valued by proficient practitioners and is something pseudocode-like (or even "regular" code-like!) could never replicate.
It’s just interesting that ALL of these languages have a C compatible interface built into the language. That’s an interesting fact and says something about C that no other language can really claim. Nor will any other language claim that any time soon.
I’m not looking for anything in particular. It’s just that I’ve seen and used a lot of languages over the years, and I’m not wholly sold on the “memory safety” of Rust when something like Python can just put the performance sensitive parts in C and have safety for everything else.
Most languages are memory safe.
> Most languages are memory safe.
As I said, there's more to Rust than just memory safety. If memory safety were the only thing Rust offered then I think it wouldn't have garnered nearly as much attention as it has. It's memory safety on top of everything else that makes it as interesting as it is.