5 ms·

> I think c++, the language, is ready for the modern world. However, c++, the community, seems to be struck at least 20 years in the past. Good point. A langua

by jll29 1y ago

> I think c++, the language, is ready for the modern world. However, c++, the community, seems to be struck at least 20 years in the past. Good point. A language that gets updated by adding a lot of features is DIVERGING from a community that has mostly people that still use a lot of the C baggage in C++, and only a few folks that use a lot of template abstraction at the other end of the spectrum. Since in larger systems, you will want to re-use a lot of code via open source libraries, one is inevitably stuck in not just one past, but several versions of older C++, depending on when the code to be re-used was written, what C++ standard was stable enough then, and whether or not the author adopted what part of it. Not to speak of paradigm choice to be made (object oriented versus functional versus generic programmic w/ templates). It's easier to have, like Rust offers it, a single way of doing things properly. (But what I miss in Rust is a single streamlined standard library - organized class library - like Java has had it from early days on, it instead feels like "a pile of crates").

pjmlp 1y ago
Just give Rust 36 years of field use, to see how it goes.
- timschmidt 1y ago
  36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?
  - pjmlp 1y ago
    Because it is counting since CFront 2.0, the first official release with industry use in UNIX systems. So that would be Rust 1.0, released in 2015, not 2006, putting it down to a decade. And the point still stands when looking at any long enough ecosystem still in use, with strong backwards compatibility, not only the language, the whole ecosystem, eventually editions alone won't make it, and just like those languages, Rust will gain its own warts.
    - timschmidt 1y ago
      Fair enough. I can cop to getting the CFront date wrong. Still, a decade since 1.0 is non-trivial. > eventually editions alone won't make it, and just like those languages, Rust will gain its own warts. That's possible. Though C++ hasn't had editions, or the HLIR / MIR separation, the increased strictness, wonderful tooling, or the benefit of learning from the mistakes made with C++. Noting that, it seems reasonable to expect Rust to collect less cruft and paint itself into fewer corners over a similar period of time. Since C++ has been going for 36 years, it seems Rust will outlive me. Past that, I'm not sure I care.
      - pjmlp 1y ago
        C++ editions are -std=something, people keep forgeting Rust editions are quite limited in what they actually allow in grammar and semantic changes across versions, and they don't cover standard library changes. IDEs are wonderful tooling, maybe people should get their heads outside UNIX CLIs and MS-DOS like TUIs. Then there is the whole ecosystem of libraries, books, SDKs and industry standards.
        timschmidt 1y ago
        I'm not sure who in your mind is forgetting that, or what the rest of your comment means to communicate. Who are you speaking to who hasn't explored all those things in depth? I see Rust's restrictions as a huge advantage over C++ here. Even with respect to editions. Rust has always given me the impression of a language designed from the start to be approximately what C++ is today, without the cruft, in which safety is opt-out, not opt-in. And the restrictions seem more likely to preserve that than not. C/C++ folks seem to see Rust's restrictions as anti-features without realizing that C/C++'s lack of restriction resulted in the situation they have today. I only maintain a few projects in each language, so I haven't run into every sort of issue for either, but that's very much how it feels to me still, several years and several projects in.
        pjmlp 1y ago
        Many of the members of the Rust Evangelism Strike Force, as main audience. That is to whom it is targeted for, given the usual kind of content that some write about. I agree that Rust is designed to be like C++ is today, without the cruft, except all languages if they survive long enough in the market, beyond the adoption curve, they will eventually get their own cruft. Not realizing this, will only make that 30 years from now, if current languages haven't yet been fully replaced by AI based tools, there will be that language designed to be like Rust is in 30 years, but without the cruft. The strength of C++ code today is on the ecosystem, that is why we reach for it, having to write CUDA, DirectX, maybe dive into the innards of Java, CLR, V8, GCC, LLVM, doing HPC with OpenAAC, OpenMP, MPI, Metal, Unreal, Godot, Unity. Likewise I don't reach for C for fun, the less the merrier, rather POSIX, OpenGL, Vulkan,....
  - d_tr 1y ago
    Rust 0.1, the first public release, came out in January 2012. CFront 1.0, the first commercial release, came out in 1985. The public existence of Rust is 13 years, during which computing has not changed that much to be honest. Now compare this to the prehistory that is 1985, when CFront came out, already made for backwards compatibility with C.
    - timschmidt 1y ago
      I grew up with all the classic 8 bit micros, and to be honest, it doesn't feel like computing has changed at all since 1985. My workstation, while a billion times faster, is still code compatible with a Datapoint 2200 from 1970. The memory model, interrupt model, packetized networking, digital storage, all function more or less identically. In embedded, I still see Z80s and M68ks like nothing's changed. I'd love to see more concrete implementations of adiabatic circuits, weird architectures like the mill, integrated FPGAs, etc. HP's The Machine effort was a rare exciting new thing until they walked back all the exciting parts. CXL seems like about the most interesting new thing in a bit.
      - qznc 1y ago
        Today a byte is 8 bits. That was not always the case back then, for example.
        timschmidt 1y ago
        > I grew up with all the classic 8 bit micros Meaning that all the machines I've ever cared about have had 8 bit bytes. The TI-99/4A, TRS-80, Commodore 64 and 128, Tandy 1000 8088, Apple ][, Macintosh Classic, etc. Many were launched in the late 70s. By 1985 we were well into the era of PC compatibles.
        bluGill 1y ago
        in 1985 PC compatibles were talked about, but systems like VAX, and mainframes were still very common and considered the real computers while PCs were toys for executives. PCs had already shown enough value (via word processors and spreadsheets) that everyone knew they were not going away. PCs lacked things like multi-tasking that even then "real" computers had for decades.
mgaunard 1y ago
A lot of people using C++ don't actually use any libraries. I've observed the opposite with Rust. People choose C++ because it's a flexible language that lets you do whatever you want. Meanwhile Rust is a constrained and opinionated thing that only works if you do things "the right way".
- tialaramex 1y ago
  > People choose C++ because it's a flexible language that lets you do whatever you want. You went on a bit too long. C++ lets you do whatever. Whether you wanted that is not its concern. That's handily illustrated in Matt Godbolt's talk - you provided a floating point value but that's inappropriate? Whatever. Negative values for unsigned? Whatever. This has terrible ergonomics and the consequences were entirely predictable.
  - mgaunard 1y ago
    It's just strong typing. You can do it in C++ too.

by jll29 1y ago

pjmlp 1y ago

Just give Rust 36 years of field use, to see how it goes.

timschmidt 1y ago
36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?
- pjmlp 1y ago
  Because it is counting since CFront 2.0, the first official release with industry use in UNIX systems. So that would be Rust 1.0, released in 2015, not 2006, putting it down to a decade. And the point still stands when looking at any long enough ecosystem still in use, with strong backwards compatibility, not only the language, the whole ecosystem, eventually editions alone won't make it, and just like those languages, Rust will gain its own warts.
  - timschmidt 1y ago
    Fair enough. I can cop to getting the CFront date wrong. Still, a decade since 1.0 is non-trivial. > eventually editions alone won't make it, and just like those languages, Rust will gain its own warts. That's possible. Though C++ hasn't had editions, or the HLIR / MIR separation, the increased strictness, wonderful tooling, or the benefit of learning from the mistakes made with C++. Noting that, it seems reasonable to expect Rust to collect less cruft and paint itself into fewer corners over a similar period of time. Since C++ has been going for 36 years, it seems Rust will outlive me. Past that, I'm not sure I care.
    - pjmlp 1y ago
      C++ editions are -std=something, people keep forgeting Rust editions are quite limited in what they actually allow in grammar and semantic changes across versions, and they don't cover standard library changes. IDEs are wonderful tooling, maybe people should get their heads outside UNIX CLIs and MS-DOS like TUIs. Then there is the whole ecosystem of libraries, books, SDKs and industry standards.
      - timschmidt 1y ago
        I'm not sure who in your mind is forgetting that, or what the rest of your comment means to communicate. Who are you speaking to who hasn't explored all those things in depth? I see Rust's restrictions as a huge advantage over C++ here. Even with respect to editions. Rust has always given me the impression of a language designed from the start to be approximately what C++ is today, without the cruft, in which safety is opt-out, not opt-in. And the restrictions seem more likely to preserve that than not. C/C++ folks seem to see Rust's restrictions as anti-features without realizing that C/C++'s lack of restriction resulted in the situation they have today. I only maintain a few projects in each language, so I haven't run into every sort of issue for either, but that's very much how it feels to me still, several years and several projects in.
        pjmlp 1y ago
        Many of the members of the Rust Evangelism Strike Force, as main audience. That is to whom it is targeted for, given the usual kind of content that some write about. I agree that Rust is designed to be like C++ is today, without the cruft, except all languages if they survive long enough in the market, beyond the adoption curve, they will eventually get their own cruft. Not realizing this, will only make that 30 years from now, if current languages haven't yet been fully replaced by AI based tools, there will be that language designed to be like Rust is in 30 years, but without the cruft. The strength of C++ code today is on the ecosystem, that is why we reach for it, having to write CUDA, DirectX, maybe dive into the innards of Java, CLR, V8, GCC, LLVM, doing HPC with OpenAAC, OpenMP, MPI, Metal, Unreal, Godot, Unity. Likewise I don't reach for C for fun, the less the merrier, rather POSIX, OpenGL, Vulkan,....
- d_tr 1y ago
  Rust 0.1, the first public release, came out in January 2012. CFront 1.0, the first commercial release, came out in 1985. The public existence of Rust is 13 years, during which computing has not changed that much to be honest. Now compare this to the prehistory that is 1985, when CFront came out, already made for backwards compatibility with C.
  - timschmidt 1y ago
    I grew up with all the classic 8 bit micros, and to be honest, it doesn't feel like computing has changed at all since 1985. My workstation, while a billion times faster, is still code compatible with a Datapoint 2200 from 1970. The memory model, interrupt model, packetized networking, digital storage, all function more or less identically. In embedded, I still see Z80s and M68ks like nothing's changed. I'd love to see more concrete implementations of adiabatic circuits, weird architectures like the mill, integrated FPGAs, etc. HP's The Machine effort was a rare exciting new thing until they walked back all the exciting parts. CXL seems like about the most interesting new thing in a bit.
    - qznc 1y ago
      Today a byte is 8 bits. That was not always the case back then, for example.
      - timschmidt 1y ago
        > I grew up with all the classic 8 bit micros Meaning that all the machines I've ever cared about have had 8 bit bytes. The TI-99/4A, TRS-80, Commodore 64 and 128, Tandy 1000 8088, Apple ][, Macintosh Classic, etc. Many were launched in the late 70s. By 1985 we were well into the era of PC compatibles.
        bluGill 1y ago
        in 1985 PC compatibles were talked about, but systems like VAX, and mainframes were still very common and considered the real computers while PCs were toys for executives. PCs had already shown enough value (via word processors and spreadsheets) that everyone knew they were not going away. PCs lacked things like multi-tasking that even then "real" computers had for decades.

mgaunard 1y ago

A lot of people using C++ don't actually use any libraries. I've observed the opposite with Rust. People choose C++ because it's a flexible language that lets you do whatever you want. Meanwhile Rust is a constrained and opinionated thing that only works if you do things "the right way".

tialaramex 1y ago
> People choose C++ because it's a flexible language that lets you do whatever you want. You went on a bit too long. C++ lets you do whatever. Whether you wanted that is not its concern. That's handily illustrated in Matt Godbolt's talk - you provided a floating point value but that's inappropriate? Whatever. Negative values for unsigned? Whatever. This has terrible ergonomics and the consequences were entirely predictable.
- mgaunard 1y ago
  It's just strong typing. You can do it in C++ too.