For reference, these are Drew's thoughts on Rust (specifically, as a replacement to C): https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
It's a few years old but it's not out of date. I think his critiques are fair, and I think it's unsurprising that he doesn't want to invest his time in the Rust ecosystem. His issues aren't that the language isn't robust, it's mainly to do with its size and complexity, and I don't blame him for not wanting to fight that fight with the Rust community who are probably not going to change course at this point.
I don't really get why "size and complexity" is considered a bad thing. Why am I supposed to think smaller languages are better? The development machine you're working on can handle it in all likelihood, and the resulting binaries can be reduced to a reasonable size like with C.
C has a consistent & stable ABI.
This is laughable. There is nothing consistent about the C abi. https://gankra.github.io/blah/c-isnt-a-language/
Most of his other arguments boil down to "it's new and it's developing fast and I don't like that for some reason".
The only real argument here IMO is Rust lacking an official spec, which is being worked on supposedly, the rest is just his gut feelings and opinions.
I don’t really get why “size and complexity” is considered a bad thing. Why am I supposed to think smaller languages are better?
I don't think its an either or thing. It all depends on the problem. Embedded systems with limited resources and hard-realtime requirements (thinking of CNC controllers, robotics, avionics, nuclear control systems, etc) must shed all this complexity as a rule. Application software (the vast majority of code anyone sees and interacts with) on the other hand benefits from all these abstractions which allow for rapid cross-platform development.
While Rust might be a better fit for hard-realtime systems than C++, it still has a lot more overhead in binary size than C, and it is stunted by the difficulty in producing compiler toolchains for the various esoteric microcontrollers which dominate this space.
You can make Rust binaries as small as you'd like basically: https://github.com/johnthagen/min-sized-rust
You can also run it on stuff like Arduino: https://creativcoder.dev/rust-on-arduino-uno
It's probably not the ideal tool for those jobs but it's also far from the worst. It very much tries to go by the C++ maxim "you pay for what you use", albeit imperfectly. I just don't see any dealbreakers here that would warrant yet another language in this space, at least none that couldn't be solved by fixing or expanding what Rust already offers.
Would love to spend some free time (when I eventually get some) working on/tinkering with a OS that actually makes sense and is nice to use but idk where to start / if any existing projects are good candidates
Seriously though I don't get *nix nerds preoccupation with dynamic linking, things are different than in the fucking 90s.
Storage space is dirt fucking cheap and you could probably make the kernel a bit smarter so it detects when the same sets of symbols get loaded and thus reduce RAM usage and cache misses.
I've heard this argument a few times but has it ever happened in practice? I guess the static lib would need to be marked as read only and page aligned by the compiler/linker so that the OS can see that multiple processes are using the exact same page and combine them
Something like that. I haven't also really seen anybody actually do it, just talk about it I think. Forgot how the technique is called and I'm not able to google it.
Also maybe you wouldn't need to hunt down specific pages of memory but rather just hash all the memory regions marked as executable in the process and just make sure to map them to the same physical memory.
It seems it's not as close as I remembered it, this is the only mention of it I can find right now: https://doc.rust-lang.org/stable/reference/#what-the-reference-is-not
So basically the answer is "we'll get there eventually". I can understand it not being a huge priority, official specs are only useful if you want to have multiple compiler implementations, which I don't think is super important right now anyway.
For reference, these are Drew's thoughts on Rust (specifically, as a replacement to C): https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
It's a few years old but it's not out of date. I think his critiques are fair, and I think it's unsurprising that he doesn't want to invest his time in the Rust ecosystem. His issues aren't that the language isn't robust, it's mainly to do with its size and complexity, and I don't blame him for not wanting to fight that fight with the Rust community who are probably not going to change course at this point.
I don't really get why "size and complexity" is considered a bad thing. Why am I supposed to think smaller languages are better? The development machine you're working on can handle it in all likelihood, and the resulting binaries can be reduced to a reasonable size like with C.
This is laughable. There is nothing consistent about the C abi. https://gankra.github.io/blah/c-isnt-a-language/
Most of his other arguments boil down to "it's new and it's developing fast and I don't like that for some reason".
The only real argument here IMO is Rust lacking an official spec, which is being worked on supposedly, the rest is just his gut feelings and opinions.
I don't think its an either or thing. It all depends on the problem. Embedded systems with limited resources and hard-realtime requirements (thinking of CNC controllers, robotics, avionics, nuclear control systems, etc) must shed all this complexity as a rule. Application software (the vast majority of code anyone sees and interacts with) on the other hand benefits from all these abstractions which allow for rapid cross-platform development.
While Rust might be a better fit for hard-realtime systems than C++, it still has a lot more overhead in binary size than C, and it is stunted by the difficulty in producing compiler toolchains for the various esoteric microcontrollers which dominate this space.
You can make Rust binaries as small as you'd like basically: https://github.com/johnthagen/min-sized-rust
You can also run it on stuff like Arduino: https://creativcoder.dev/rust-on-arduino-uno
It's probably not the ideal tool for those jobs but it's also far from the worst. It very much tries to go by the C++ maxim "you pay for what you use", albeit imperfectly. I just don't see any dealbreakers here that would warrant yet another language in this space, at least none that couldn't be solved by fixing or expanding what Rust already offers.
Ooh thanks for that link, very interesting read
deleted by creator
deleted by creator
deleted by creator
Would love to spend some free time (when I eventually get some) working on/tinkering with a OS that actually makes sense and is nice to use but idk where to start / if any existing projects are good candidates
Seriously though I don't get *nix nerds preoccupation with dynamic linking, things are different than in the fucking 90s.
Storage space is dirt fucking cheap and you could probably make the kernel a bit smarter so it detects when the same sets of symbols get loaded and thus reduce RAM usage and cache misses.
deleted by creator
deleted by creator
I've heard this argument a few times but has it ever happened in practice? I guess the static lib would need to be marked as read only and page aligned by the compiler/linker so that the OS can see that multiple processes are using the exact same page and combine them
Something like that. I haven't also really seen anybody actually do it, just talk about it I think. Forgot how the technique is called and I'm not able to google it.
Also maybe you wouldn't need to hunt down specific pages of memory but rather just hash all the memory regions marked as executable in the process and just make sure to map them to the same physical memory.
deleted by creator
Can't we do shared memory pages now, so the old argument of "dynamic linking saves RAM" doesn't matter as much?Nvm space_comrade said what I was thinking of
I haven't heard about Rust working on an official spec, got a link?
It seems it's not as close as I remembered it, this is the only mention of it I can find right now: https://doc.rust-lang.org/stable/reference/#what-the-reference-is-not
So basically the answer is "we'll get there eventually". I can understand it not being a huge priority, official specs are only useful if you want to have multiple compiler implementations, which I don't think is super important right now anyway.