4 ms·

We need memory safety but Rust is not the answer. It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breat

by akagusu 8mo ago

We need memory safety but Rust is not the answer. It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breath, and is controlled by a foundation that is controlled by big tech corps. What could go wrong?

pjmlp 8mo ago
It has a partial spec. https://ferrous-systems.com/blog/ferrocene-25-11-0/ https://ferrous-systems.com/blog/ferrocene-25-11-0/ Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.
- snovymgodym 8mo ago
  > Lets not forget not having a formal spec apparently wasn't an issue for C C emerged in the 1970s when there weren't many other options, and it was rapidly propagated because US antitrust laws forced AT&T to inexpensively license Unix (and by extension C) to universities and research institutions. That was half a century ago. I am a supporter of Rust adoption, but the line of reasoning that "C didn't need X, so Rust shouldn't either" is fundamentally flawed. The time difference between today and C's public emergence is the same as the time between C's emergence and the 1920s. The field of computing is radically different today and any language that wishes to see wider adoption now must play by a completely different set of rules than those of 50 years ago.
  - pjmlp 8mo ago
    There have been options since JOVIAL in 1958, as there have been OS written in high level language a decade before C came to be invented. C has to thank its adoption by being freely available with UNIX, that AT&T was forbidden to take commercial advantage of, for many years, the only reference implementation was whatever cc does.
    - snovymgodym 8mo ago
      > There have been options since JOVIAL in 1958 Yeah, pedantically speaking there were other options but not for the average person. Languages like PL/I and JOVIAL were locked away in corporate institutions behind exorbitant licensing fees. Discoverability was limited as there was no WWW and there was no concept of open source. If you were an established company, then sure you could pay IBM $20000 for PL/I and be done with it. But if you were a founder building something new, then you were stuck with what was available and familiar, and if you went to a university in the USA after the mid 1970s and learned anything about computers then Unix and C is what you knew. It just so happens that such companies were the ones who created much of the modern computing landscape, so C came along for the ride. But anyway, > C has to thank its adoption by being freely available with UNIX, that AT&T was forbidden to take commercial advantage of, for many years, the only reference implementation was whatever cc does. This is exactly my point. The path that C took to wide adoption cannot be replicated by a modern language, so any drawing parallels along the lines of "Well C didn't need a formal standard" are not useful. It's like thinking that you can be an internationally successful superstar by greasing up your hair and playing rockabilly music just because Elvis did it in the 1950s. The world has changed and Rust will need to play a different game than C did.
      - pjmlp 8mo ago
        There were no average persons writing operating systems in those decades. Rust already did, it takes safety seriously, guess why Multics got an higher security score than UNIX?
budgefrankly 8mo ago
> changes too fast The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions. It's absolutely not changing too fast > depends on third party libraries that change faster than I can breath No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies. Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.
- johnny22 8mo ago
  the proof is right there in all the discussion about rust in the linux kernel too.
  - pornel 8mo ago
    Not sure if you mean proof of changing too fast …or not fast enough? Linux has a wishlist of features they want for kernel development, and Rust has been working towards adding them. Here's the paradox: Rust is very careful about compatibility and stability, the stable releases are changing slowly. But the Rust for Linux project wants to use the newly prototyped features right away, so they depend on not-yet-released features from unstable nightly versions of Rust.
    - LeFantome 8mo ago
      > the Rust for Linux project wants to use the newly prototyped features right away > they depend on not-yet-released features from unstable nightly versions of Rust This is not true. Since kernel 6.11 they have specified a minimum version that is already stable. The strategy for the Rust kernel is to use the version of Rust that ships with Debian Stable. That is very far from using "the newly prototyped features right away". https://rust-for-linux.com/rust-version-policy https://rust-for-linux.com/rust-version-policy Of course, the kernel continues to inform Rust evolution. But you do not need an unstable version of Rust to compile Linux.

by akagusu 8mo ago

pjmlp 8mo ago

It has a partial spec. https://ferrous-systems.com/blog/ferrocene-25-11-0/ https://ferrous-systems.com/blog/ferrocene-25-11-0/ Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.

snovymgodym 8mo ago
> Lets not forget not having a formal spec apparently wasn't an issue for C C emerged in the 1970s when there weren't many other options, and it was rapidly propagated because US antitrust laws forced AT&T to inexpensively license Unix (and by extension C) to universities and research institutions. That was half a century ago. I am a supporter of Rust adoption, but the line of reasoning that "C didn't need X, so Rust shouldn't either" is fundamentally flawed. The time difference between today and C's public emergence is the same as the time between C's emergence and the 1920s. The field of computing is radically different today and any language that wishes to see wider adoption now must play by a completely different set of rules than those of 50 years ago.
- pjmlp 8mo ago
  There have been options since JOVIAL in 1958, as there have been OS written in high level language a decade before C came to be invented. C has to thank its adoption by being freely available with UNIX, that AT&T was forbidden to take commercial advantage of, for many years, the only reference implementation was whatever cc does.
  - snovymgodym 8mo ago
    > There have been options since JOVIAL in 1958 Yeah, pedantically speaking there were other options but not for the average person. Languages like PL/I and JOVIAL were locked away in corporate institutions behind exorbitant licensing fees. Discoverability was limited as there was no WWW and there was no concept of open source. If you were an established company, then sure you could pay IBM $20000 for PL/I and be done with it. But if you were a founder building something new, then you were stuck with what was available and familiar, and if you went to a university in the USA after the mid 1970s and learned anything about computers then Unix and C is what you knew. It just so happens that such companies were the ones who created much of the modern computing landscape, so C came along for the ride. But anyway, > C has to thank its adoption by being freely available with UNIX, that AT&T was forbidden to take commercial advantage of, for many years, the only reference implementation was whatever cc does. This is exactly my point. The path that C took to wide adoption cannot be replicated by a modern language, so any drawing parallels along the lines of "Well C didn't need a formal standard" are not useful. It's like thinking that you can be an internationally successful superstar by greasing up your hair and playing rockabilly music just because Elvis did it in the 1950s. The world has changed and Rust will need to play a different game than C did.
    - pjmlp 8mo ago
      There were no average persons writing operating systems in those decades. Rust already did, it takes safety seriously, guess why Multics got an higher security score than UNIX?

budgefrankly 8mo ago

> changes too fast The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions. It's absolutely not changing too fast > depends on third party libraries that change faster than I can breath No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies. Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.

johnny22 8mo ago
the proof is right there in all the discussion about rust in the linux kernel too.
- pornel 8mo ago
  Not sure if you mean proof of changing too fast …or not fast enough? Linux has a wishlist of features they want for kernel development, and Rust has been working towards adding them. Here's the paradox: Rust is very careful about compatibility and stability, the stable releases are changing slowly. But the Rust for Linux project wants to use the newly prototyped features right away, so they depend on not-yet-released features from unstable nightly versions of Rust.
  - LeFantome 8mo ago
    > the Rust for Linux project wants to use the newly prototyped features right away > they depend on not-yet-released features from unstable nightly versions of Rust This is not true. Since kernel 6.11 they have specified a minimum version that is already stable. The strategy for the Rust kernel is to use the version of Rust that ships with Debian Stable. That is very far from using "the newly prototyped features right away". https://rust-for-linux.com/rust-version-policy https://rust-for-linux.com/rust-version-policy Of course, the kernel continues to inform Rust evolution. But you do not need an unstable version of Rust to compile Linux.