[dpc_pw]

> I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal.

Yes, I wasn't talking about real-time/performance consideration. The root post was along the lines of "Rust is nice, but I like productivity of a GC". I'm saying deterministic destruction is more productive for the developer and Rust makes a great high-level language.

Regarding stuff like non-blocking deallocation etc. You can still do it in Rust if so you desire. In the a destructor, enforced by the type, you can use nice abstractions, etc. and eg. defer deallocations, or draw memory from an arean. I think eventually Rust will just have more or less standardized type for GCs and graphs with explicit roots etc.

But sure, it is all still very new here, so if one is writing a real-time trading or OS, maybe they should stick to C/C++.

> But I honestly wonder about the size & longevity of your C/C++ semi-production code - semi, because it is C/C++

In C I worked on code powering embedded chips (mostly radio communication, kernel modeules) and eg. real-time hypervisor powering some high-end cars. In C++ eg. some high-perf data management stuff (data dedupilcation, encryption, etc.) in a SV unicorn. I actually would describe myself as C (as opposed to C++ person), but I know my around modern C++ quite well - i just really don't like working with it.

> I somehow can't see another complex language solving more problems net-net.

I don't think Rust is actually that complex. It is definitely bigger than C, but I think it's much smaller than C++. And it is sane. Thinks play well together in it, I think I could get a new dev productive with Rust in a week or up to a monthy, and as long as you avoid `unsafe` in Rust they will produce a decent code with ease. In C++ you're either an "expert" or you're debugging segfaults. ;)

[wyatwerp]

I truly was curious about your C/C++ code - good for you that it was less C++ and more C! I don't know any masochists, so I don't know anybody who likes to work in C++ (even with just composition and generics), or even any reluctant "expert". I get away from segfaults because I am on server & can get away by more static copying of data (it pales in comparision to what alternatives offer).

I can see why you think Rust is tractable; you have worked on fairly complex stuff like automobile base software (AutoSAR, was it?). I am probably not as good at it as you are, so the cognitive load of designing at that scale with borrow-checking seems prohibitive. I hope there is a way to slice the problem which makes for less cognitive load.

[dpc_pw]

> AutoSAR, was it?

Just a real-time hypervisor for Tegra underlying Nvidia Automotive platform. MISRA C, ISO 26262. Bleh. :D

> so the cognitive load of designing at that scale with borrow-checking seems prohibitive

I have multiple 1k - 10k line Rust projects on github, and I hardly ever deal or think about lifetimes. I just randomly opened a project of mine on github, opening some major files and there's literally 0 explicit lifetime annotations anywhere.

People hang up on lifetimes because they are unfamiliar, but for someone that gets some understanding and accepts "ways of Rust" (mostly avoiding cyclical graphs, using IDs instead of pointers, etc.), there are not an issue. Only when designing some weird zero-cost abstractions in performance-critical APIs, trying to avoid any copying, one has to annotate some lifetimes in non-trivial ways. Usually you can just ask someone on IRC and they will give you an answer. :D

The mental overhead is actually way lower than in C (or most languages for that matter). After a while you get used to relying on compiler to check the mundane stuff and focus only on the higher level problems. It's quite relieving actually.

[wyatwerp]

MISRA C? Cool!

About the design model for programming in Rust, I guess only making the time to try writing something in Rust can answer the question. It is interesting how the steepness of the Rust learning curve could actually be a hook to get people to try it, which is all any well-designed language would need to gain adherents.

Back to critical systems programming, does MISRA C have a "certified" compiler like CompCert C or something? If so, Rust usage in such a niche must be a long way away - even if one could "certify" the Rust compiler code, how would one "certify" the million+ lines of C++ in LLVM!