Doesn’t C++ also support having multiple allocators within one program, though? That would still be an ability C++ has that Rust technically doesn’t (yet) even once stable Rust 1.28 is released.
That’s not quite the same thing but a first, necessary step in the right direction. Custom allocators allow “Per Class” allocators to be used, not just changing what the default allocator will be.
In Rust, you can use “Custom Allocators” with a crate if you want (see https://doc.rust-lang.org/1.9.0/book/custom-allocators.html); however, you cannot override the allocator used by another crate that you use except by changing the default/global allocator.
When talking about full “Custom Allocators” one is usually referring to something like this: https://github.com/rust-lang/rust/issues/42774
- If you mean heap and stack - yes
- it is not possible to work with arbitrary memory adresses (on the safe level at least ) in Rust. That means there are much more unreacheble memory areas from Rust.
I would not consider that an accurate statement. You can reach any address from Rust just as “safely” as you can from C. In addition, Rust makes it much easier to wrap such accesses in safe abstractions that would prevent misuse of arbitrary addresses.
of course yes - but
1 at the cost
2 many languaches claim to do so… (C++ , for example)
What cost are you referring to?
wrapping, as you just posted over
Wrapping, will in most cases, have zero run-time cost (depending on how you wrap things).
Another yes (but not everywere), yet plus steep learning curve (must be taking in the account ).
From C’s viewpoint everything looks just as simple as to get from and to put…
Rust doesn’t stop being low-level just because it is harder to learn.
Not only that, but, I’m not 100% sure that Rust is harder to learn than C.
of course not , but i state that it is both- lowlevel and hardtolearn (but C is just more lowlevel and not so complex itself). More over, i really believe that It is very good point to learn and practice some of C just prior to any Rust
Rust is indeed supports low-level, but I’d personally argue that it is not “harder” to learn than C.
In fact, I find Rust far more intuitive and helpful in teaching me than I’ve ever found C.
C may be a “simple” tool, but to use it correctly, without (accidentally) causing crashes, segfaults, race conditions or Undefined Behaviour *shudder*) is far harder than in C.
As one of my favourite quote-of-the-weeks put it: The Rust Compiler is strict-but-helpful, whereas the C compiler will happily run into the minefield for you/with you
hehe i’m afraid you are (intentionally or not) mixing up with the notions “to learn (teach) the language” and “to learn(teach) programming with the language”. The second is indeed much more complex (actually the first notion can be considered just as the part of the second), I talk just about the first, and moreover do it (as much as possible) with connection to the topic (lowlevellness).
By “different types of memory addresses” do you mean cache-aware allocation? Or do you mean something more radical like 8051-style memory? For those of you who don’t know, the 8051-family of microcontrollers can have up to 5 different regions of memory. It’s not just that there are speed differences; you need different instructions to access different regions. The first 128 bytes are basically registers, the first 256 bytes (yes, they overlap) can be used like a stack, 16 bytes in the middle of that 256 can be addressed bit-wise, and there are two different types of higher memory that can be indirectly addressed.
Rust has no support for that kind of awareness in its allocators, AFAIK. But then, pure C doesn’t either. All of the decent 8051 C compilers add extensions to the C language to deal with it.
Please, please PLEASE can we just abandon 8051 already? Aren’t ARM and MIPS and RISC-V cheap enough already?
This thread is arguing about vaguely-defined term based on second-guessing someone’s incomplete second-hand statement.
It doesn’t seem productive…
You (as many on this thread) are diving into details. But there is very very simple answer upon the topics question. It trivially comes from understanding of von Neumann’s architecture - if a computer system comprises it then any programming can be considered as readings (and writings) bits from memory cells (and to). From that viewpoint C lang more lowlevel (and capable at low level for some tasks) than Rust…because It allows very simple and less restrictive manipulations with arbitrary memory access.
From that same viewpoint, a hand-grenade is more “low level” than a pistol, because it can explode in more directions (including into my face).
The liberty to shoot yourself in the foot is not really a selling point for C, in my personal opinion
But I agree with Kornel, the original (vague) question on low-levelness has been discussed well past usefulness. Lets move to other, more productive threads. (Still, some excellent points were made, I’m bookmarking several of the posts in this topic )
If anyone has any cool tangents and/or new issues they want to discuss based on something in this thread, the “reply as linked topic” is hidden in the top right corner of every post:
Click the post timestamp --> “+ New Topic”.
This will automatically link that post into the start of a blank new topic.
hehe for 20 years of C ,C++ teaching (along with other courses) i’m pretty tired of them so i hate any thought of advertaising or as you say “selling”. I just put out the answer to the question - simple, honest, and strightforward… One thing i agree with you - the blahblah… should be over unless you find some mention worthy arguments upon the topic
I will add to this discussion that if you have previous C/C++ experience as well as Haskell experience, then Rust will be easy(ier) to learn. This is because in many ways, Rust can reach as low as C can, while also almost reaching as high as Haskell can. Haskell knowledge will help you understand features such as traits, iterators, and the type system better, while C and C++ will help you appreciate how computer architecture works and the notion of lifetimes and the perils of getting the lifetimes of objects wrong.
@HadrienG hopefully Haskell can help some math-inclined folks move away from Fortran when Haskell gains good built in support for nested data parallelism and linear types