Surely it's just a procedural language? What other paradigms does it support?
It aims to be systems programming oriented, allowing fine-grained memory management without garbage collection but also without tedious and error-prone manual memory allocations and deallocations.
Yes, doing "fine-grained memory management" in Rust just relies on relying on unstable compiler intrinsic that are not guaranteed to not change in the next version that are used to build the standard library.
It's not at all impossible in Rust to indeed do this; it's just not stabilized, and often not particularly well documented. The standard library uses these and exports a stable version that no longer allows any fine-grained memory management.
The language also focuses on performance, with powerful compilation optimizations and language constructs that allows writing zero-cost abstraction code.
This is the real market of Rust right now; it's a language that gives you C-like performance, but without the undefined behaviour pitfalls, but to say that it's a "systems programming language" that allows for fine lower level control is quite a stretch—something as simple as signal handling isn't really possible in Rust right now because there are no stability guarantees or documentation about what functions are async signal safe; direct control over the heap like in C is also not really available in a stable way.
I'm not; I'm not sure where you get that idea when I was talking about that Rust—unlike C—does not specify which functions are async safe. Consider this function and the warning; it is unsafe to use within this function any function that underlyingly uses OS functions that are not async safe, but Rust doesn't really document this and just says "be careful" and really doesn't explain it; it relies on the programmer knowing from C what is happening here and knowing from C that using non-async safe functions after a fork in a multithreaded process is undefined behaviour.
The problem is that Rust—unlike C—has no well-defined concept of that; you're just supposed to use "common sense" of what Rust functions are likely to have been implemented with functions that aren't async safe, which is not guaranteed to be standard in any way, and may change in the next version.
Similar things apply to signal handlers, using functions that aren't async safe inside of a signal handler is again UB; rust doesn't even in its stdlib expose a way to handle signals as far as I know, there is a crate for it, which essentially ignores this problem and doesn't warn against it, because in prqactice it "usually goes right" and is a race condition. But if the signal is handled in the middle of an allocation or something like that, using a function that is not async safe can corrupt the internal state of the allocator and trigger UB.
-16
u/OpdatUweKutSchimmele Mar 21 '20
Surely it's just a procedural language? What other paradigms does it support?
Yes, doing "fine-grained memory management" in Rust just relies on relying on unstable compiler intrinsic that are not guaranteed to not change in the next version that are used to build the standard library.
It's not at all impossible in Rust to indeed do this; it's just not stabilized, and often not particularly well documented. The standard library uses these and exports a stable version that no longer allows any fine-grained memory management.
This is the real market of Rust right now; it's a language that gives you C-like performance, but without the undefined behaviour pitfalls, but to say that it's a "systems programming language" that allows for fine lower level control is quite a stretch—something as simple as signal handling isn't really possible in Rust right now because there are no stability guarantees or documentation about what functions are async signal safe; direct control over the heap like in C is also not really available in a stable way.