Wow. That's a really insightful post. Thanks for sharing it!
1 Like
I was addressing your claim that "C-lang was designed to follow [the relevant idiosyncrasies of the underlying machine model and OS architecture models] as much as possible." I believe my link demonstrates that this isn't true.
As for memory models generally being inherited from C, you are absolutely correct, although in theory I think that compilers could probably make better use of Rust-style immutability (which can't be cast away without unsafe) than of const to implement some of the recommendations from the article.
1 Like
One thing that has plagued me for years with using C++ in a multi-threaded environment is that it lacks immutability. Since it was created in the age of single threaded apps, the contracts that it provides are only sufficient for that.
For example, if you have a call like:
void do_something(const uint8_t* buffer);
This provides the promise that the function will not update the contents of the buffer. But there is no way, really, to make a promise to the function that the caller will not change the buffer while the function is running. The caller may have spawned a thread which also has write (non-const) access to the buffer.
Newer languages invented in the generation of the multi-core, including Rust, generally provide a way to make that contract go both ways.
4 Likes
he he actually it is not my claim it is posed by ssokolow i quoted it to show my disagreement with (author whom i answered). to be more correct i put in the words other sense. hmmm. please check the subj of my posts before misjudjing. yet my posts were strictly with context joe232 trouble- i never mean abstract talks or any common discussion. So my posts to others (except joe232) just clarified my position.
Yes, your post I quoted contains quotes from ssokolow. No, the bit I quoted is not one of those quotes.
if so ... my initial sentense was " I believe that C lang is optimal for beginner’s low to middle level programming tasks (more over - it is native for most of hardware pieces ). " I mean just what i do - "it is native for most of hardware pieces". So "for most of hardware pieces" is not equal to "for every of hardware pieces ". Please be careful with your fancies. They are not of mine and they are weakly related to my thoughts .
I did not say that the article applies to all hardware.
Beginners are likely to be using their PCs, which are x86, Itanium, or, more likely, x86_64. These are all subject to the critique in the article I posted.
Do you have some other piece of hardware in mind that isn't...?
It feels like you are trying to prove that my post was irrelevant to yours, and complaining that I am representing you unfairly, rather than trying to make the conversation as productive as possible.
3 Likes
If they have Itanium I'd be really surprised! 
Wasn't that a niche server architecture that never really took off?
Sorry for the digression.
1 Like
Actually, considering the OP is talking about robotics and game development, it's not that far fetched to throw Itanium in there. I recently had the displeasure of dealing with Itanium for the first time in years--those weird things (as well as UltraSPARC) are used as servers for things like robotics. Granted, the environment was likely niche, but anyone who was around during UltraSPARC being widely used by Sun for HTTP(S) applications probably understands why they'd repurpose them for this. (Presumably it's a knock-on effect from having started on the platforms though.)
I'd also argue it's just as likely a beginning would be on an ARM processor these days. Not because I think everyone should be developing for phones or tablets (ugh, developing on phones and tablets), but because of things like the Raspberry Pi. It's not like ARM's assembly maps particularly well either, so compilation from C, C++, Rust, D, Go, or whatever else into the assembly language isn't super helpful either.
So if we sample from beyond x86/x86_64 (different but samey enough) and Itanium, we start to reach really weird conclusions about "which is better". But I think we're forgetting something pretty crucial here: there's a side beyond what we write and how easy it is to write it.
Realistically, since we could argue that C++ is (almost?) always going to have a model similar to what LLVM outputs (and you might even be using Clang or MSVC via Clang), and Rust will do the same because it's built on LLVM (until cranelift takes over, or unless someone goes crazy and writes a hobby compiler for a specific architecture). The difference shouldn't be large. So in terms of raw power, and raw control, two paths diverged in a yellow wood?
I was going to comment about how most ASM doesn't map well to the underlying hardware but someone beat me to it (well, for x86, ARM is a whole other kettle of nightmares). Yay hardware iteration and moving goalposts for backwards compatibility?
And you can cast away const.
C++ is very interesting but very frustrating and very big.
To be fair, you can unsafe-away immutability in Rust too. There are some valid reasons (like the borrow checker failing on you), it's just not always a good idea. (Almost) anything else crazy/insane you can do in C/C++, I'm pretty sure you can in Rust. I specify almost because I'm yet to get remotely safe hotpatching working in Rust. But having said that, Rust telling you you shouldn't (and making it harder to do it) is a good thing, because it prevents hard to diagnose weird errors that arise in places that otherwise make no sense/are hard to debug.
1 Like