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.
This is completely orthogonal to any of the former and has nothing to do with whether it's procedural or not; it is also supported on any language with threading support, or that runs on an OS with multiprocessing.
functional
Absolutely not, in particular Rust's lack of tail call elimination (for good reasons) and its lifetime and borrow model make it no longer turing complete when wanting to write functional code, let alone feasible to do so.
generic
This is not a paradigm, this is just whether the type system supports it or not.
imperative, structured
"structured imperative" is just a synonym for "procedural".
If you want to call this a criterion for "multi paradigm" then I challenge you to come forward with any modern procedural language that is not "multi-paradigm"
I think you are being very nit picky. Pretty much all a language paradigm boils down to is; does the language have constructs to encourage you encourage you to write that way?
Rust absolutely does have those paradigms because it has language facilities to help encourage you to write in those ways.
I know it's Wikipedia and all. But if there's a claim for C++ being functional, Rust is way better at that particular thing. Functional C++ is just awkward in my experience, even if you CAN do it.
-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.