You're a lot more restricted on FB but you also can't host your online store, or really anything except: messages, groups, events, photos and videos.
C++ could probably be more regulated for certain scenarios, but if people don't paint self-hosted blogs as evil, why paint C++ that way ?
Your argument seems a lot more valid for Python, Java, as AFAIK in those languages you can't access raw memory.
Do you have a specific example?
I think you'll have to make "can do" more precise for this question to have a meaningful answer. All mentioned languages are Turing complete and thus equivalent on that level.
> you can't access raw memory.
I can wrap a file in a ByteBuffer in java and the JVM will (make a best effort to) perform native I/O on that. Does that pass as "access raw memory"? If not, you'd have to explain how this is different from the abstract machine that C++ is defined on.
Sure, in Java you can't escape the garbage collector, but in C++ you also formally invoke UB if you violate the object lifetime requirements (even though will generally work due to this part of the standard still being... work in progress, let's say).
I actually agree, I was just arguing with the point of the above comment which implicated you can't do lots of things in Rust that you can in C++. I don't know what the author was referring to, so I can't be more specific.
> I can wrap a file in a ByteBuffer in java and the JVM will (make a best effort to) perform native I/O on that. Does that pass as "access raw memory"?
I was referring to directly accessing the memory "owned" by local variables (the stack), the bytecode of the program itself (on von Neumann architecture), etc. It was a counterpoint in that implication that every other language (akin to publishing systems) had no limitations where Rust had. But I don't think that's actually a problem as (if that's ever needed) you can FFI to another language that can do that stuff and (as you said) all those languages are turing complete.
Sorry if it sounded like I was attacking Java & Python, for most applications I don't think the "runtime" limitation isn't a problem and comparing them to facebook is still hyperbolic.
At that point, a different language might be better anyway.
My experiences with C++ (I dust it off every year because of something that needs doing that nobody else wants to touch) are that I've usually dipped into C++ specifically for some combination of:
1. Invoking API's that have been around for a long time, usually meaning OS API's
2. Hand-optimized performance sensitive code where, for example, you're auditing every runtime memory allocation that has to be done in the inner loops
3. Modifying legacy code that's written in C++
In all of those cases you have to dip into unsafe territory regularly, so you end up with pretty much what Rust does with safe/unsafe, but with less in the way of the language helping you to ferret out your memory handling bugs. Every time I do it, even if I don't think I've created memory handling bugs, and even when my tools don't catch anything, I always leave with a low grade fear that my code will end up in a CVE somewhere.
There are operating systems written in rust. If that is possible, then anything else is possible too.