I am still ok with plain and simple C for cross-CPU code, for now. c++ is lost in grotesque and absurd complexity (that's why gcc move to c++ was one of the biggest mistake in software, ever).
I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers.
Linus T. (more likely the guys pulling the strings of the linux fondation financing) green lighted rust in the kernel, I bet this is some horrible gcc extended rust, not core and simple rust (hope they have the decency to compile linux rust code with the rust compiler written in rust). A long time ago, I had a look at rust syntax and was disappointed by the strings hardcoded in the syntax and all that "package" management system hardcoded in the syntax, but most syntax looked like a re-arranged C. Were they able to keep it that simple? (no grotesque objet orientation or those horrible templates or garbage collector or hardcoded weird and expansive memory allocation model).
The pb is C syntax is too already too complex. I wonder if rust suffers from the same issue, hope they "fixed" C: only sized types, no integer promotion, no implicit cast (except for void*), compile-time/runtime casts (without that horrible c++ syntax), only 1 loop keyword, no enum/typedef/_generic/etc, etc.
I don’t know what you mean by strings embedded in Rust syntax nor package management (unless you mean crates and modules, which are basically just namespaces; the only “package management” is done by higher-level tools like Cargo).
To answer your other questions: no, Rust has neither garbage collection, nor templates. I don’t know what you mean by hardcoded weird and expansive memory allocation model; Rust’s is basically the same as C++’s.
Why don’t you take the time to read a Rust tutorial rather than just assuming everything bad you can imagine about it and asking people to correct you?
When did I say rust is actually C++? I said its memory allocation model is the same: normally done in containers or smart pointers, but malloc and free are still available under the hood if you really need them.
Many other things about rust are extremely different from C++.
So rust has heavy memory allocation implicit in the syntax (not meant only for the stack). I remember now I did not want that (like those horrible c++ new/delete).
Thx to have refreshed my memory about rust syntax.
the syntax implicit expensive free is the same issue than the syntax implicit expensive allocation. I clearly recall when I read early rust specs that I did not want that (and more).
Additionally, I wonder if they fixed the other C issues, namely removing integer promotion, implicit casts (but different explicit casts for compile-time and runtime), enum, _generic, typeof, 1 loop keyword is enough, no switch, goto is not harmful, have only sized primitive types, change extern/static... Hopefully, rust does not have object-orientation.
And you can bet, you will find a bunch of sickos not writting simple and core rust for linux... but rust with tons of extensions only in 1 or 2 compilers like the "C" from linux which is actually the C from gcc and nothing else (clang and icc playing catchup).
I should re-read the language syntax specs though. But I guess, I would drop that reading if I encounter a definitive nono again.
Rust changed drastically before 1.0, so depending on when you read this, it may be 100% irrelevant.
> namely removing integer promotion,
Rust does not do integer promotion.
> implicit casts
Rust does not do implicit casts (often called "coercion")
> enum
Rust's enums can do what C's enums do, but are more powerful by default, you can add arbitrary data to them, not just a synonym for some integers.
> _generic
Rust has a full generic system. Very different than _generic.
> 1 loop keyword is enough
Rust has loop for infinite loops, while, and an iterator-based for loop. There's no do/while.
> no switch
Rust has 'match', which is like a switch but extra powerful, especially when combined with features like enums.
> goto is not harmful
Rust does not have goto. It would be harmful for the kinds of static analysis Rust does. Rust does have named break though, which can do many (but not all) of the things you'd do with goto.
Additionally due to RAII and the way errors work on Rust, you don't need goto for error handling like you would in C.
> have only sized primitive types,
Not 100% sure what you mean by this.
> change extern/static
I don't know what this means.
> Hopefully, rust does not have object-orientation.
It depends on what you mean by OOP, but in general, the answer is "no". There's no classes, no inheritance. You can do dynamic dispatch, but it's fairly rare.
> But I guess, I would drop that reading if I encounter a definitive nono again.
Given what you said about destructors, that hasn't changed, so sounds like you'd stop.
It's very unlikely you would ever have to use something like C++'s new/delete in Rust unless you are doing something like re-implementing the Vec class.
I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers.
Linus T. (more likely the guys pulling the strings of the linux fondation financing) green lighted rust in the kernel, I bet this is some horrible gcc extended rust, not core and simple rust (hope they have the decency to compile linux rust code with the rust compiler written in rust). A long time ago, I had a look at rust syntax and was disappointed by the strings hardcoded in the syntax and all that "package" management system hardcoded in the syntax, but most syntax looked like a re-arranged C. Were they able to keep it that simple? (no grotesque objet orientation or those horrible templates or garbage collector or hardcoded weird and expansive memory allocation model).
The pb is C syntax is too already too complex. I wonder if rust suffers from the same issue, hope they "fixed" C: only sized types, no integer promotion, no implicit cast (except for void*), compile-time/runtime casts (without that horrible c++ syntax), only 1 loop keyword, no enum/typedef/_generic/etc, etc.