5 ms·

Rust is a serious contender is this space, and closing the gap quickly.

by randomint64 3y ago

pjmlp 3y ago
Including introducing new features on 6 weeks basics, just wait until Rust also gets 40 years of history.
- pornel 3y ago
  You know this is a red herring. Frequency of the release cycle is orthogonal to the amount of changes or even how long the changes are in development.
  - pjmlp 3y ago
    Just wait until Rust gets 40 years old. Pity I won't be no longer around to check on it, given average human life expectancy.
    - pornel 3y ago
      I can't wait for C++64. But "just wait until Rust will repeat C++'s mistakes" is just pure speculation. Language evolution doesn't have to make the language worse. Java, JS, C#, or Ada are pretty old now, and have been doing fine. Rust is well prepared for a 40-year lifespan with its edition system.
      - pjmlp 3y ago
        You quite clearly are unware of the evolution pain points to move past Java 8, .NET Framework 4.8, and how the Java community embraces Java 20, or the C# one sees C# 12, and the rate they are adding new features. As for JS, everyone knows the mess of the Web ecosystem and frontend development. Ada is doing just fine, as most vendors are still adopting Ada 2012. Ada Core and PTC are the only ones with the latest version, from 7 remaining vendors.
        pornel 3y ago
        But the ecosystem lagging years behind the latest version is a separate problem, and one that ironically the 6-week release cycle of Rust helps with: there are no major upgrades to fear, and small frequent releases make the ecosystem move with the compiler instead of having time to ossify and choose to stay on an old version (the same way nobody chooses to stay on an old Chrome, but people used to stick to good'ol versions of IE and Netscape).
        pjmlp 3y ago
        Lagging behind is only one issue, I explicilty mentioned the drama of newer updates that make many unconfortable given the rate that they now are coming with changes for the sake of it, just go read the comments on the C# 12 features announcements for a taste of it.
- tialaramex 3y ago
  It's true, improvements to Rust ship on a six week cycle, the next will be Rust 1.69. Nice. I was inspired to improve a compiler diagnostic earlier this year†, I benefit from that improvement already in the stable compiler today. Whereas if you "miss the train" with standard C++ you've got three years to wait each time, and of course the Powers That Be can ensure that oops, you just missed the train again... Of course Rust's improvements are actually compatible, not only by fiat, but because Rust's automation extensively tests each of these six weekly releases against the vast field of Free Software out there written in Rust. Now maybe this is secretly happening for C++ and they're just very bad at it. Or, as seems more likely, it's not done, the results are the same either way, new C++ versions require extensively manual testing to upgrade your software before you can take advantage without too much fear. † Rust knows that characters like 'A' aren't necessarily one byte, and it deliberately doesn't coerce them to fit in a byte, you'd need to convert them, so let ch: u8 = 'A'; won't compile. But ASCII characters can fit in a byte, so there is syntax to write that b'A'. My change means that the compiler will explicitly suggest you modify that earlier mistake to let ch: u8 = b'A'; which works, however it knows not to recommend nonsense like let ch: u8 = b'£'; the pound currency symbol isn't in ASCII so you keep the same diagnostic just explaining what's wrong with no suggestion.
  - pjmlp 3y ago
    Again, wait until Rust gets 40 years of history deployments, distributed from the tiny 8 CPU, to HPC workloads and FPGAs, or stuff running on Mars. I doubt very much that Rust editions and backwards compatibility history will be able to survive 40 years with such diverse use cases, without introducing accidental complexity and corner cases along the way. This assuming that we can still use Rust and not Crab , as if Rust also doesn't have its own show of politics.
    - tialaramex 3y ago
      Rust is not designed for 8-bit CPUs like Tiny8. The smallest usize is allowed to be is 16 bits. In practice on these very tiny devices high level languages are total overkill. Grace's original "compiler" concept makes sense, but today's assemblers are more than sufficiently capable. You can literally memorise what all the individual memory locations (actually Tiny8 just admits they're registers, it's not as if it would make sense to also have registers when you only have 256 bytes of RAM) are used for which means even the idea of variable names is of doubtful value. I don't know if it's practical to write a conforming C++ "freestanding" compiler for Tiny8, but I can't imagine it'd be any more useful than Rust would be if you did. The reason there isn't stuff on Mars running Rust is mostly that it takes a long time both to get stuff approved for that kind of application and to send things to Mars. Still I'm sure in 40 years there will have been Rust on Mars because why not and I doubt it'll have significant impact on Rust syntax. There already are inelegant decisions which cannot (for compatibility) be revoked, but they're much less numerous and egregious at this point in Rust's life than similar problems were in standard C++. If you want one to point at, for some reason, I suggest comparing ASCII predicates like char::is_ascii_lowercase(&self) -> bool with the non-ASCII ones like char::is_lowercase(self) -> bool Because char is Copy, the latter design would be more elegant, and allows e.g. "C++".contains(char::is_uppercase) which is true, whereas the ASCII variant means we need the more awkward looking "C++".contains(|c: char| c.is_ascii_uppercase()) going via a lambda but alas the way we got here didn't allow that to happen.

Rust is a serious contender is this space, and closing the gap quickly.

pjmlp 3y ago

Including introducing new features on 6 weeks basics, just wait until Rust also gets 40 years of history.

pornel 3y ago
You know this is a red herring. Frequency of the release cycle is orthogonal to the amount of changes or even how long the changes are in development.
- pjmlp 3y ago
  Just wait until Rust gets 40 years old. Pity I won't be no longer around to check on it, given average human life expectancy.
  - pornel 3y ago
    I can't wait for C++64. But "just wait until Rust will repeat C++'s mistakes" is just pure speculation. Language evolution doesn't have to make the language worse. Java, JS, C#, or Ada are pretty old now, and have been doing fine. Rust is well prepared for a 40-year lifespan with its edition system.
    - pjmlp 3y ago
      You quite clearly are unware of the evolution pain points to move past Java 8, .NET Framework 4.8, and how the Java community embraces Java 20, or the C# one sees C# 12, and the rate they are adding new features. As for JS, everyone knows the mess of the Web ecosystem and frontend development. Ada is doing just fine, as most vendors are still adopting Ada 2012. Ada Core and PTC are the only ones with the latest version, from 7 remaining vendors.
      - pornel 3y ago
        But the ecosystem lagging years behind the latest version is a separate problem, and one that ironically the 6-week release cycle of Rust helps with: there are no major upgrades to fear, and small frequent releases make the ecosystem move with the compiler instead of having time to ossify and choose to stay on an old version (the same way nobody chooses to stay on an old Chrome, but people used to stick to good'ol versions of IE and Netscape).
        pjmlp 3y ago
        Lagging behind is only one issue, I explicilty mentioned the drama of newer updates that make many unconfortable given the rate that they now are coming with changes for the sake of it, just go read the comments on the C# 12 features announcements for a taste of it.
tialaramex 3y ago
It's true, improvements to Rust ship on a six week cycle, the next will be Rust 1.69. Nice. I was inspired to improve a compiler diagnostic earlier this year†, I benefit from that improvement already in the stable compiler today. Whereas if you "miss the train" with standard C++ you've got three years to wait each time, and of course the Powers That Be can ensure that oops, you just missed the train again... Of course Rust's improvements are actually compatible, not only by fiat, but because Rust's automation extensively tests each of these six weekly releases against the vast field of Free Software out there written in Rust. Now maybe this is secretly happening for C++ and they're just very bad at it. Or, as seems more likely, it's not done, the results are the same either way, new C++ versions require extensively manual testing to upgrade your software before you can take advantage without too much fear. † Rust knows that characters like 'A' aren't necessarily one byte, and it deliberately doesn't coerce them to fit in a byte, you'd need to convert them, so let ch: u8 = 'A'; won't compile. But ASCII characters can fit in a byte, so there is syntax to write that b'A'. My change means that the compiler will explicitly suggest you modify that earlier mistake to let ch: u8 = b'A'; which works, however it knows not to recommend nonsense like let ch: u8 = b'£'; the pound currency symbol isn't in ASCII so you keep the same diagnostic just explaining what's wrong with no suggestion.
- pjmlp 3y ago
  Again, wait until Rust gets 40 years of history deployments, distributed from the tiny 8 CPU, to HPC workloads and FPGAs, or stuff running on Mars. I doubt very much that Rust editions and backwards compatibility history will be able to survive 40 years with such diverse use cases, without introducing accidental complexity and corner cases along the way. This assuming that we can still use Rust and not Crab , as if Rust also doesn't have its own show of politics.
  - tialaramex 3y ago
    Rust is not designed for 8-bit CPUs like Tiny8. The smallest usize is allowed to be is 16 bits. In practice on these very tiny devices high level languages are total overkill. Grace's original "compiler" concept makes sense, but today's assemblers are more than sufficiently capable. You can literally memorise what all the individual memory locations (actually Tiny8 just admits they're registers, it's not as if it would make sense to also have registers when you only have 256 bytes of RAM) are used for which means even the idea of variable names is of doubtful value. I don't know if it's practical to write a conforming C++ "freestanding" compiler for Tiny8, but I can't imagine it'd be any more useful than Rust would be if you did. The reason there isn't stuff on Mars running Rust is mostly that it takes a long time both to get stuff approved for that kind of application and to send things to Mars. Still I'm sure in 40 years there will have been Rust on Mars because why not and I doubt it'll have significant impact on Rust syntax. There already are inelegant decisions which cannot (for compatibility) be revoked, but they're much less numerous and egregious at this point in Rust's life than similar problems were in standard C++. If you want one to point at, for some reason, I suggest comparing ASCII predicates like char::is_ascii_lowercase(&self) -> bool with the non-ASCII ones like char::is_lowercase(self) -> bool Because char is Copy, the latter design would be more elegant, and allows e.g. "C++".contains(char::is_uppercase) which is true, whereas the ASCII variant means we need the more awkward looking "C++".contains(|c: char| c.is_ascii_uppercase()) going via a lambda but alas the way we got here didn't allow that to happen.