11–20 of 344 posts
> So rather than bothering to begin, you wrote an email. This is where Theo appears to me to be quite different to eg Linus. He plays the man, not the ball, with personal attacks.
Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils
Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, environment... as safe as it was never compromised. OpenBSD compiles everywhere where C code works, Rust/Cargo works where it's supported and it will takes decades to catch-up on some architectures.
Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils
And Go: https://github.com/ericlagergren/go-coreutils Does he really not know this or is he ignoring them to make a point?
But it will not stop _everyone_ from adopting better languages, and their efforts will eventually surpass the older, less secure systems.
When there's feature parity, each and every new exploit will be called out: "this wouldn't have happened in our system'. And that is a good thing. There _are_ better alternatives to C.
As for the point about how nobody is working on replacements, that's wrong. There's (partial) replacements for most coreutils written in rust, and a whole kernel has been under active development for years now.
Earlier quoted context omitted.
That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.
Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
Earlier quoted context omitted.
That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.
Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils
And Go: https://github.com/ericlagergren/go-coreutils Does he really not know this or is he ignoring them to make a point?
The points made against switching to newer languages are valid. It will cost time, it will cost effort, it will take many years of work to convince stubborn maintainers to switch. But it will not stop _everyone_ from adopting better languages, and their efforts will eventually surpass the older, less secure systems. When there's feature parity, each and every new exploit will be called out: "this wouldn't have happen…
Earlier quoted context omitted.
That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.
This seems like a bit of a trite point unless many rust developers are actually working inside i386. Though the compiler itself might not work very well in i386. Not many people are whining about our C compiler toolchains not fitting into our microcontrollers.
Trite point? OpenBSD supports 1386[1] if they pull a rust compiler into base and start rewriting things in rust, then they can't support 1386. Dropping a supported platform is not a "trite point".