5 ms·

My thought exactly. But that's C++, a bolted-on mess of crap whose redeeming features are (a) roughly the same execution performance as C and assembly, and (b)

by asah 2y ago

My thought exactly. But that's C++, a bolted-on mess of crap whose redeeming features are (a) roughly the same execution performance as C and assembly, and (b) it's safer and higher productivity than C or assembly. At this point, it feels like a matter of time before Rust replaces C/C++.

dgfitz 2y ago
There are decades and decades of code written in cobol that run the modern banking system. Multiply that code base size by like, 78.3, and you’re possibly in the same galaxy as the all the c++ codebases out there that will be maintained for the next 50 years. Rust may eat the lunch of c++ moving forward, the language will never go away.
- larodi 2y ago
  Abso-fkn-lutely! Stable computing protocols of all sorts don’t go away overnight and that is something everyone in IT should absolutely get used to. I expect C/C++ to live long beyond 2050.
- DowsingSpoon 2y ago
  >the language will never go away Just like COBOL! Seriously, _just like COBOL_. The language will fade in importance over time. C++ will be relegated to increasingly narrow niches. It will eventually only be found in "legacy" systems that no one wants to spend to rewrite. No one young will bother at all to learn C++ at all. Then, in a few decades, they'll be pulling folks like you and me out of retirement to maintain old systems for big bucks.
  - timewizard 2y ago
    I doubt this analysis. The base of computing where C++ is used is exponentially larger than the base where COBOL was used. In particular the compilers we currently use are written in it.
    - DowsingSpoon 2y ago
      You definitely make a good point. My thought was that large legacy projects would slowly migrate to a different language. The news of the recent introduction of Rust in Linux has me optimistic something similar will eventually happen in other places too. (not necessarily with Rust, specifically) The keyword here is Eventually. I’m thinking this is years away for GCC and LLVM. If the new language has good interop with the old then this doesn’t have to be painful either. A while back, I was working on a large Objective-C code base which was slowly moving to Swift. We quickly got to a point where new code was written in Swift by default. In only a couple of years, we had a code base which used Objective-C pretty much only in the dark corners where code churns slowly.
akkad33 2y ago
C++ is safer than C? How?
- JTyQZSnP3cQGa8B 2y ago
  You can write whole applications that compiles to the same assembly code without using any kind of memory management thanks to the destructors, smart pointers, and all the objects of the STL.
  - flohofwoe 2y ago
    This just pushes the problem into the C++ stdlib, which has plenty of memory-corruption issues too but just calls it 'undefined behaviour' (see things like dangling std::string_view, missing range checks in containers or iterator invalidation). In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' (instead of directly poking around in random data). Different approach, but not any less safe than C++.
    - vlovich123 2y ago
      > In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' "In Rust that's just pushing the problem to the borrow checker and codegen which has plenty of memory corruption issues too but just calls it "bugs". In C++ you avoid those issues by reducing dynamic memory allocations to a minimum, and using checked APIs as 'safety boundaries' instead of directly poking around random arrays. Different approach but not any less safe than C++". Both statements are pretty ridiculous. It's pretty clear that moving up in terms of the safe abstractions that are possible makes your code safer because the safety is there when you reach for that kind of programming paradigm & the programming paradigms you need are typically a property of the problem domain rather than the language (it's it's the intersection of "how is this problem solved" and "what tools does the language give you"). In C it gives you few tools and you either twist into a pretzel trying to stick to that or you write our own tools from scratch every time and make the same but different mistakes over and over. No language is perfect and all will guide you to different takes on the same problem that better suit to its paradigm, but there are intractable parts that will force you to do things (e.g. heap allocation and more involved ownership semantics are not uncommon). Moreover C very limited ability to manage your own codebase to define API boundaries - the only tool is opaque types with a defined set of functions declared in 2 different files.
deleted 2y ago
[deleted]
flohofwoe 2y ago
Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). > it's safer and higher productivity than C or assembly Debatable - in C and even more so in assembly, the unsafety is at least directly in your face, while in C++ it's cleverly diguised under C++ stdlib interfaces (like dangling std::string_views, all the iterator invalidation scenarios etc... meaning that memory corruption bugs may be much harder to investigate in C++ than in C (or even assembly) - which in turn affects productivty (e.g. what's the point in writing higher level buggy code faster when debugging takes much longer). > it feels like a matter of time before Rust replaces C/C++ It may replace C++, but C will most likely outlive at least C++, and I wouldn't be surprised if Rust too - even if just as C API wrappers to allow code written in different modern languages to talk to each other ;)
- kibwen 2y ago
  > Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). I've never seen any users who avoid using Rust's stdlib on principle. The closest thing is the use of the parking_lot crate over the standard Mutex types, but that's getting better over time, not worse, as the stdlib moves closer to parking_lot in both implementation and API. Other than that, there's only been one "wrong" API that needed to be deprecated with a vengeance (mem::uninitialized, replaced by mem::MaybeUninit). Especially compared to C++, the fact that Rust doesn't have a frozen ABI means it's free to improve the stdlib in ways that C++ can only dream of. While I do wish that the Rust stdlib contained some more things (e.g. a standard interface to system entropy, rather than making me pull in the getrandom crate), for what it provides the Rust stdlib is quite good.
  - vlovich123 2y ago
    Ironically c++ as well refused to define an ABI. That’s not why the language is bad. It’s the lack of editorial tools within the language the standard body has so it has no evolution path and thus ossifies under its own inertia. It’s amazing they still haven’t done anything about it.
  - accelbred 2y ago
    I avoid the Rust stdlib. The stdlib uses panics and dynamic memory allocation, neither of which are great for embedded usecases or writing software adhering to safety-critical coding practices. no_std is common for embedded targets, and IIRC the linux kernel couldn't use stdlib because of panics.
poincaredisk 2y ago
Rust is a C++ replacement, but not a C replacement, for many C use cases. Language that may replace C is Zig.
- pwdisswordfishz 2y ago
  What are those use cases?
readyplayernull 2y ago
I find the C vs C++ battle amusing after having lived in the 90s and the Pascal/Delphi vs C/C++ holy wars.
justin66 2y ago
> At this point, it feels like a matter of time before Rust replaces C/C++. I expect Rust's successor might have a shot at replacing C++. By the time C++ was as old as Rust, it had conquered the world. If Rust coulda, it woulda.
- caspper69 2y ago
  I think you're right. As soon as you start writing big(ger) software in Rust, its lacking ergonomics really become apparent. .as_mut().unwrap().unwrap().as_mut().do_stuff() gets really old after a while. And I am not convinced that borrow checking is the panacea that it's made out to be. Region-based memory management can accomplish the same safety goals (provided there's a sane concurrency model), without forcing people into manually opting into boxing and/or reference counting on a per-reference basis. Throw into that the pain of manual lifetime management (it's not always elided, and when it needs to change, it's painful), I honestly believe it's far more reasonable to ask programmers to throw shit into two or three arenas and then go hog-wild with references than it is to expect them to deal with the tediousness of the way Rust does things. We are just cargo-culters (no pun intended).
- jayd16 2y ago
  I don't think that's fair. There's a lot less blue ocean these days. C++ could expand into virgin territory where Rust (or any new language) needs to fight against momentum.
  - deleted 2y ago
    [deleted]

by asah 2y ago

dgfitz 2y ago

There are decades and decades of code written in cobol that run the modern banking system. Multiply that code base size by like, 78.3, and you’re possibly in the same galaxy as the all the c++ codebases out there that will be maintained for the next 50 years. Rust may eat the lunch of c++ moving forward, the language will never go away.

larodi 2y ago
Abso-fkn-lutely! Stable computing protocols of all sorts don’t go away overnight and that is something everyone in IT should absolutely get used to. I expect C/C++ to live long beyond 2050.
DowsingSpoon 2y ago
>the language will never go away Just like COBOL! Seriously, _just like COBOL_. The language will fade in importance over time. C++ will be relegated to increasingly narrow niches. It will eventually only be found in "legacy" systems that no one wants to spend to rewrite. No one young will bother at all to learn C++ at all. Then, in a few decades, they'll be pulling folks like you and me out of retirement to maintain old systems for big bucks.
- timewizard 2y ago
  I doubt this analysis. The base of computing where C++ is used is exponentially larger than the base where COBOL was used. In particular the compilers we currently use are written in it.
  - DowsingSpoon 2y ago
    You definitely make a good point. My thought was that large legacy projects would slowly migrate to a different language. The news of the recent introduction of Rust in Linux has me optimistic something similar will eventually happen in other places too. (not necessarily with Rust, specifically) The keyword here is Eventually. I’m thinking this is years away for GCC and LLVM. If the new language has good interop with the old then this doesn’t have to be painful either. A while back, I was working on a large Objective-C code base which was slowly moving to Swift. We quickly got to a point where new code was written in Swift by default. In only a couple of years, we had a code base which used Objective-C pretty much only in the dark corners where code churns slowly.

akkad33 2y ago

C++ is safer than C? How?

JTyQZSnP3cQGa8B 2y ago
You can write whole applications that compiles to the same assembly code without using any kind of memory management thanks to the destructors, smart pointers, and all the objects of the STL.
- flohofwoe 2y ago
  This just pushes the problem into the C++ stdlib, which has plenty of memory-corruption issues too but just calls it 'undefined behaviour' (see things like dangling std::string_view, missing range checks in containers or iterator invalidation). In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' (instead of directly poking around in random data). Different approach, but not any less safe than C++.
  - vlovich123 2y ago
    > In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' "In Rust that's just pushing the problem to the borrow checker and codegen which has plenty of memory corruption issues too but just calls it "bugs". In C++ you avoid those issues by reducing dynamic memory allocations to a minimum, and using checked APIs as 'safety boundaries' instead of directly poking around random arrays. Different approach but not any less safe than C++". Both statements are pretty ridiculous. It's pretty clear that moving up in terms of the safe abstractions that are possible makes your code safer because the safety is there when you reach for that kind of programming paradigm & the programming paradigms you need are typically a property of the problem domain rather than the language (it's it's the intersection of "how is this problem solved" and "what tools does the language give you"). In C it gives you few tools and you either twist into a pretzel trying to stick to that or you write our own tools from scratch every time and make the same but different mistakes over and over. No language is perfect and all will guide you to different takes on the same problem that better suit to its paradigm, but there are intractable parts that will force you to do things (e.g. heap allocation and more involved ownership semantics are not uncommon). Moreover C very limited ability to manage your own codebase to define API boundaries - the only tool is opaque types with a defined set of functions declared in 2 different files.

deleted 2y ago

[deleted]

flohofwoe 2y ago

Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). > it's safer and higher productivity than C or assembly Debatable - in C and even more so in assembly, the unsafety is at least directly in your face, while in C++ it's cleverly diguised under C++ stdlib interfaces (like dangling std::string_views, all the iterator invalidation scenarios etc... meaning that memory corruption bugs may be much harder to investigate in C++ than in C (or even assembly) - which in turn affects productivty (e.g. what's the point in writing higher level buggy code faster when debugging takes much longer). > it feels like a matter of time before Rust replaces C/C++ It may replace C++, but C will most likely outlive at least C++, and I wouldn't be surprised if Rust too - even if just as C API wrappers to allow code written in different modern languages to talk to each other ;)

kibwen 2y ago
> Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). I've never seen any users who avoid using Rust's stdlib on principle. The closest thing is the use of the parking_lot crate over the standard Mutex types, but that's getting better over time, not worse, as the stdlib moves closer to parking_lot in both implementation and API. Other than that, there's only been one "wrong" API that needed to be deprecated with a vengeance (mem::uninitialized, replaced by mem::MaybeUninit). Especially compared to C++, the fact that Rust doesn't have a frozen ABI means it's free to improve the stdlib in ways that C++ can only dream of. While I do wish that the Rust stdlib contained some more things (e.g. a standard interface to system entropy, rather than making me pull in the getrandom crate), for what it provides the Rust stdlib is quite good.
- vlovich123 2y ago
  Ironically c++ as well refused to define an ABI. That’s not why the language is bad. It’s the lack of editorial tools within the language the standard body has so it has no evolution path and thus ossifies under its own inertia. It’s amazing they still haven’t done anything about it.
- accelbred 2y ago
  I avoid the Rust stdlib. The stdlib uses panics and dynamic memory allocation, neither of which are great for embedded usecases or writing software adhering to safety-critical coding practices. no_std is common for embedded targets, and IIRC the linux kernel couldn't use stdlib because of panics.

poincaredisk 2y ago

Rust is a C++ replacement, but not a C replacement, for many C use cases. Language that may replace C is Zig.

pwdisswordfishz 2y ago
What are those use cases?

readyplayernull 2y ago

I find the C vs C++ battle amusing after having lived in the 90s and the Pascal/Delphi vs C/C++ holy wars.

justin66 2y ago

> At this point, it feels like a matter of time before Rust replaces C/C++. I expect Rust's successor might have a shot at replacing C++. By the time C++ was as old as Rust, it had conquered the world. If Rust coulda, it woulda.

caspper69 2y ago
I think you're right. As soon as you start writing big(ger) software in Rust, its lacking ergonomics really become apparent. .as_mut().unwrap().unwrap().as_mut().do_stuff() gets really old after a while. And I am not convinced that borrow checking is the panacea that it's made out to be. Region-based memory management can accomplish the same safety goals (provided there's a sane concurrency model), without forcing people into manually opting into boxing and/or reference counting on a per-reference basis. Throw into that the pain of manual lifetime management (it's not always elided, and when it needs to change, it's painful), I honestly believe it's far more reasonable to ask programmers to throw shit into two or three arenas and then go hog-wild with references than it is to expect them to deal with the tediousness of the way Rust does things. We are just cargo-culters (no pun intended).
jayd16 2y ago
I don't think that's fair. There's a lot less blue ocean these days. C++ could expand into virgin territory where Rust (or any new language) needs to fight against momentum.
- deleted 2y ago
  [deleted]