5 ms·

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-optimism". I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years. With that in mind, "the onus on anti-Rust people is now to demonstrate a better language to rewrite in first, rather than just sitting in the status quo waiting for the steamroller driven by a crab to very slowly run them over." just doesn't make much sense to me. If the status quo is fine, there's no "onus", there's no difficult decision to be made, there just isn't any rewrite. The anti-Rust people will probably be fine by doing ... nothing.

tormeh 2y ago
I don't think anyone believes there will be no C++ codebases in the future - that's crazy talk. What could happen in a decade or two is that there'll be no _new_ C++ codebases. Popular languages are retired to legacy status from time to time, and C++ is completely outclassed by Rust.
- bayindirh 2y ago
  People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere. FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written. What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++. Thinking that C++ will just fade to black is wishful thinking.
  - kosolam 2y ago
    Since C++ still evolves and changes, I guess greenfield C++ projects in the future can limit themselves to a subset of the newer improved language thereby C++ will continue living by that way as well.
    - bayindirh 2y ago
      C++ already passed that line with C++17 and newer iterations. Not only it evolves way faster starting with C++17, the modern code looks sufficiently different that it needs relearning some parts of C++ from start. I've written my biggest project with C++11, and C++14 was just out back then. Now, I plan to reimplement that project (and improve it), again with C++, but I need to look at so-called "modern C++" to do it correctly and in a more future-proof way. ...and I'm glad I have to do that, because while I love (old school) C++, seeing it evolve makes me happy. Because systems evolve, software scale evolve, and most importantly hardware and ways to get maximum performance from it evolve. There's no need to write old-school C++ anymore. All these features are developed for a reason, they shall be used.
    - steveklabnik 2y ago
      The C++ community is talking about evolving in the following ways in this space: 1. contracts 2. profiles 3. successor languages 4. borrow checking The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.
      - kosolam 2y ago
        I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.
        ryandrake 2y ago
        "Subset language" is already an option. The developer can choose a safe(r) subset of C++ to constrain themselves to. Many (most?) C++ shops already do this, and go to varying lengths to enforce that only their blessed subset is used. We don't really need a committee to create a new "subset language" to accomplish this.
        steveklabnik 2y ago
  - pklausler 2y ago
    What new scientific applications are being written in Fortran?
    - aragilar 2y ago
      Fluid dynamics codes are still being written in Fortran. Notably, there are still improvements happening in the Fortran space, and there's been a bit of revival of sorts. There are still features in Fortran that make it nicer to write in than C++ (and while I'd hoped rust might be a good Fortran replacement, I feel rust has taken a different path, and remains no better than C++).
      - pklausler 2y ago
        New CFD codes? Links?
pjc50 2y ago
> I have a C++ service running in production Is it on a network (or other) security boundary, exposed to attack from the Internet? Is it deployed on millions of machines worldwide? _Those_ are the primary targets for replacement, because the networked environment is a very hostile place, and people are fed up with the consequences of that. Regular announcements of "sorry all your private data has been leaked lol". Constant upgrade treadmill to fix the latest CVEs. (the poster child for this was really Shockwave Flash, later owned by Adobe, which had so many RCE exploits everyone united behind Apple killing it off. Even if this meant obsoleting a whole era of media and games which relied on it. That wasn't rewritten, it was just killed.)
- fxtentacle 2y ago
  I'd guess most services where performance matters are in the background. And this particular C++ service is only accessible over internal LAN, to be used by other back-end servers. I agree with you that if ha-proxy and nginx didn't exist yet, they would be prime candidates for being implemented in Rust. But now that they already exist and reliably work, I'm not sure there is enough pain for them to get replaced anytime soon. BTW the last ha-proxy CVE was them differing from the HTTP spec and accepting the # character in additional URL components, which is something that probably no compiler could have flagged.
  - ttfkam 2y ago
    > I'm not sure there is enough pain for them to get replaced anytime soon. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... https://blog.cloudflare.com/pingora-open-source https://blog.cloudflare.com/pingora-open-source
    - fxtentacle 2y ago
      That sounds like a great project :) but 1. "Pingora is Not an Nginx Replacement" https://navendu.me/posts/pingora/ https://navendu.me/posts/pingora/ 2. you still put it behind ha-proxy https://github.com/cloudflare/pingora/issues/132 https://github.com/cloudflare/pingora/issues/132 3. https://github.com/cloudflare/pingora https://github.com/cloudflare/pingora says "Pingora keeps a rolling MSRV (minimum supported Rust version) policy of 6 months." so for anyone who dislikes the "constant upgrade treadmill", this won't help much. So my summary would be that Pingora is a great Rust library which one day might be used for replacing nginx and/or ha-proxy. But the main advantages of Pingora - which are the reason why CloudFlare is using it now - have nothing to do with Rust. Obviously, a software architecture designed in 2022 can take advantage of modern hardware in a way that an architecture from 2004 cannot. (Yes, nginx is that old). Intel's TBB library brought "work-stealing" to C++ around 10 years ago. The other big improvement in Pingora is moving from multi-process to multi-threading pools. Again, C++ had thread pools for years. So Pingora is probably great and it's written in Rust. But the business benefits that it brings aren't coming from Rust. They are coming from the fact that it's a modern architecture.

tormeh 2y ago

I don't think anyone believes there will be no C++ codebases in the future - that's crazy talk. What could happen in a decade or two is that there'll be no _new_ C++ codebases. Popular languages are retired to legacy status from time to time, and C++ is completely outclassed by Rust.

bayindirh 2y ago
People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere. FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written. What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++. Thinking that C++ will just fade to black is wishful thinking.
- kosolam 2y ago
  Since C++ still evolves and changes, I guess greenfield C++ projects in the future can limit themselves to a subset of the newer improved language thereby C++ will continue living by that way as well.
  - bayindirh 2y ago
    C++ already passed that line with C++17 and newer iterations. Not only it evolves way faster starting with C++17, the modern code looks sufficiently different that it needs relearning some parts of C++ from start. I've written my biggest project with C++11, and C++14 was just out back then. Now, I plan to reimplement that project (and improve it), again with C++, but I need to look at so-called "modern C++" to do it correctly and in a more future-proof way. ...and I'm glad I have to do that, because while I love (old school) C++, seeing it evolve makes me happy. Because systems evolve, software scale evolve, and most importantly hardware and ways to get maximum performance from it evolve. There's no need to write old-school C++ anymore. All these features are developed for a reason, they shall be used.
  - steveklabnik 2y ago
    The C++ community is talking about evolving in the following ways in this space: 1. contracts 2. profiles 3. successor languages 4. borrow checking The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.
    - kosolam 2y ago
      I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.
      - ryandrake 2y ago
        "Subset language" is already an option. The developer can choose a safe(r) subset of C++ to constrain themselves to. Many (most?) C++ shops already do this, and go to varying lengths to enforce that only their blessed subset is used. We don't really need a committee to create a new "subset language" to accomplish this.
      - steveklabnik 2y ago
- pklausler 2y ago
  What new scientific applications are being written in Fortran?
  - aragilar 2y ago
    Fluid dynamics codes are still being written in Fortran. Notably, there are still improvements happening in the Fortran space, and there's been a bit of revival of sorts. There are still features in Fortran that make it nicer to write in than C++ (and while I'd hoped rust might be a good Fortran replacement, I feel rust has taken a different path, and remains no better than C++).
    - pklausler 2y ago
      New CFD codes? Links?

pjc50 2y ago

> I have a C++ service running in production Is it on a network (or other) security boundary, exposed to attack from the Internet? Is it deployed on millions of machines worldwide? _Those_ are the primary targets for replacement, because the networked environment is a very hostile place, and people are fed up with the consequences of that. Regular announcements of "sorry all your private data has been leaked lol". Constant upgrade treadmill to fix the latest CVEs. (the poster child for this was really Shockwave Flash, later owned by Adobe, which had so many RCE exploits everyone united behind Apple killing it off. Even if this meant obsoleting a whole era of media and games which relied on it. That wasn't rewritten, it was just killed.)

fxtentacle 2y ago
I'd guess most services where performance matters are in the background. And this particular C++ service is only accessible over internal LAN, to be used by other back-end servers. I agree with you that if ha-proxy and nginx didn't exist yet, they would be prime candidates for being implemented in Rust. But now that they already exist and reliably work, I'm not sure there is enough pain for them to get replaced anytime soon. BTW the last ha-proxy CVE was them differing from the HTTP spec and accepting the # character in additional URL components, which is something that probably no compiler could have flagged.
- ttfkam 2y ago
  > I'm not sure there is enough pain for them to get replaced anytime soon. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... https://blog.cloudflare.com/pingora-open-source https://blog.cloudflare.com/pingora-open-source
  - fxtentacle 2y ago
    That sounds like a great project :) but 1. "Pingora is Not an Nginx Replacement" https://navendu.me/posts/pingora/ https://navendu.me/posts/pingora/ 2. you still put it behind ha-proxy https://github.com/cloudflare/pingora/issues/132 https://github.com/cloudflare/pingora/issues/132 3. https://github.com/cloudflare/pingora https://github.com/cloudflare/pingora says "Pingora keeps a rolling MSRV (minimum supported Rust version) policy of 6 months." so for anyone who dislikes the "constant upgrade treadmill", this won't help much. So my summary would be that Pingora is a great Rust library which one day might be used for replacing nginx and/or ha-proxy. But the main advantages of Pingora - which are the reason why CloudFlare is using it now - have nothing to do with Rust. Obviously, a software architecture designed in 2022 can take advantage of modern hardware in a way that an architecture from 2004 cannot. (Yes, nginx is that old). Intel's TBB library brought "work-stealing" to C++ around 10 years ago. The other big improvement in Pingora is moving from multi-process to multi-threading pools. Again, C++ had thread pools for years. So Pingora is probably great and it's written in Rust. But the business benefits that it brings aren't coming from Rust. They are coming from the fact that it's a modern architecture.