3 ms·

The author claims to know C++, but remarks suggest she has not learned much, if anything, of it since 1998. It is possible that her team is similarly not aware

by ncmncm 5y ago

The author claims to know C++, but remarks suggest she has not learned much, if anything, of it since 1998. It is possible that her team is similarly not aware, so that it wouldn't matter if she was.

IAmEveryone 5y ago
metadat 5y ago
Are people only allowed to claim they know a language when they keep up with the bleeding edge and every new revision as they are released? Your post comes across to me as more a thinly veiled insult than any sort of useful insight.
- snovv_crash 5y ago
  C++ had a major change of direction with C++11, to the extent that a lot of previous design patterns and constraints are now completely obsolete. C++98 compared to C++20 is probably equivalent to Python 2.2 vs 3.9, and someone wouldn't claim to "know python" if they only used 2.2.
  - dureuill 5y ago
    While true, I believe it doesn't significantly change the tradeoff between Rust and C++. Also, nothing in the post lets us infer that the author doesn't know C++11 and later.
    - ncmncm 5y ago
      You can believe whatever you like, but the fact is that changes in C++11 and C++20 change the tradeoff between C++ and Rust in fundamental ways. The only way anyone could believe otherwise would be by knowing precious little about the topic.
      - dureuill 5y ago
        While I did not use C++20, I did follow its new feature set, and did not see anything able to address the issues of C++: - no way to express "lifetime relationships", they remain in comments or force you to work around the problem by using copied objects or worse, shared pointers. This resulted in very real bugs in our code due to a library returning structs that had to live shorter than some other object, without it being clear from the name of the struct. Coincidentally, this same library has a rust implementation, where keeping instances of this struct for too long is a compiler error. - no blessed way to express thread safety in the type system - terrible build system without a blessed package manager, which is not about to change because: - they are still headers everywhere. While modules are technically in C++20, tooling is not ready today (save for MSVC). The module implementation is also dubious in that it seems to cater to any niche use case in existence which adds a lot of complexity (and new opportunities for ODR violations...), instead of going "clean slate" and providing a simple system (preventing the split between declaration and definition and not being orthogonal to namespaces would have been a good start) - no ergonomic sum types. Sum types are very important to model business logic and it is hard to go back to languages lacking them. There are discussions of pattern matching for C++ but it's not in C++20. Several of these issues are impossible to fix in an existing language without breaking an unreasonable amount of existing code, so I don't see future versions of C++ reversing the statu quo. I also don't really trust the committee to achieve simple, ergonomic solutions, when I look to eg what was done with modules or coroutines (here I heard that the solution is to use third party libraries, but while it is tractable in Rust it is much less so in C++ due to the lack of satisfying tooling). You're welcome to elaborate if you disagree though.
        ncmncm 5y ago
        In modern C++, you get the same benefits as are claimed for "lifetime annotations" by operating at a higher level. In effect, a library may adopt responsibility for what the Rust compiler would have enforced, and where it matters, they routinely do. This is no substantial burden. As a result, it has been a very long time since I last encountered a lifetime problem in my C++ code. Sum types work fine in C++. Pattern matching is an extra notational convenience on top of them. Rust has many nice convenience features, but lacks numerous other powerful features C++ provides. But this is not a good place to go into detail. If you care, there is plenty of material online. The point remains that comparisons, if done at all, should be done based on knowledge about current facts, not suppositions and hearsay.
- ncmncm 5y ago
  Yes. People are "only allowed to claim" to know about the merits of a language that they actually know. C++20 is the C++ to compare against, unless she wants to compare against, say, Rust as it was in 2014. C++98 is simply not an honest basis for comparison. I don't need "thinly veiled insults" when the facts speak for themselves. The author had no need to mention C++ at all. Then, she would not have found herself making ignorant comparisons.
  - tialaramex 5y ago
    > C++20 is the C++ to compare against Admitting that each ISO standard is a distinct language (so, C++ 20 is distinct from C++ 17 and C++ 03 and so on) and insisting upon naming them this way would of course satisfy this concern. But doing so would also highlight the uncomfortable reality that C++ 20 isn't a real language programmers can use yet - compiler vendors are still implementing this standard and won't be done for a while. It would also highlight the fragmentation, you would need to pick one of these different C++ languages to write some software, and in doing so rule out using the others. And that's a pretty poor alternative to Rust, which is one real language Maxime and her team were able to use to write this software.
  - metadat 5y ago
    ncmncm, what is your specific definition for "actually" knowing a programming language? If it's something like "mastery over most or all facets and nuances", perhaps there are a few thousand human beings in total who meet this qualification. Across all programming languages across the entire Earth.
    - ncmncm 5y ago
      Trolling is generally unwelcome here.
tialaramex 5y ago
Which remarks in particular made you think this?
dureuill 5y ago
I find your remark strange: the author is mainly comparing the scalability of Rust vs C. C++ does provide tools to build scalable software, and was already doing so in 1998 (few new features on this front since 98 I guess? Maybe modules, but using them for portable development in 2022 looks difficult given their state in compilers that aren't MSVC). I don't think this is a reason to prefer C++ over Rust (if anything, the tools for encapsulation and modularization provided by C++ are way less convenient and efficient than Rust's--speaking from experience of C++14 and Rust here). Also C++ has the massive drawbacks of lacking ADT, forcing headers on users (which is elaborated in the post I believe) and not offering a "safe mode" like Rust does (the tooling is also massively better, but somehow cargo felt like a hindrance to the author of that post, so there's that). It did surprise me that the author wouldn't elaborate on why C++ was not chosen, when her argument made it look like it could provide some of the advantages she found in Rust. However, she doesn't *have to* elaborate on every possible subject in that post, and implying she doesn't know the language (anymore) because of her not focusing on the reasons she didn't use it looks like a dubious stretch.
- ncmncm 5y ago
  The author does, in fact, bring up C++ herself. It is very strange to have dismissed it while knowing so little about its current status, and so worth bringing up. She didn't have to mention C++ at all. If you don't see C++20 as a very, very different language from C++98, it can only be because you know practically nothing about the topic. That is totally allowed, but expressing opinions based on knowing nothing produces worthless opinions.

by ncmncm 5y ago

The author claims to know C++, but remarks suggest she has not learned much, if anything, of it since 1998. It is possible that her team is similarly not aware, so that it wouldn't matter if she was.

IAmEveryone 5y ago

metadat 5y ago

Are people only allowed to claim they know a language when they keep up with the bleeding edge and every new revision as they are released? Your post comes across to me as more a thinly veiled insult than any sort of useful insight.

snovv_crash 5y ago
C++ had a major change of direction with C++11, to the extent that a lot of previous design patterns and constraints are now completely obsolete. C++98 compared to C++20 is probably equivalent to Python 2.2 vs 3.9, and someone wouldn't claim to "know python" if they only used 2.2.
- dureuill 5y ago
  While true, I believe it doesn't significantly change the tradeoff between Rust and C++. Also, nothing in the post lets us infer that the author doesn't know C++11 and later.
  - ncmncm 5y ago
    You can believe whatever you like, but the fact is that changes in C++11 and C++20 change the tradeoff between C++ and Rust in fundamental ways. The only way anyone could believe otherwise would be by knowing precious little about the topic.
    - dureuill 5y ago
      While I did not use C++20, I did follow its new feature set, and did not see anything able to address the issues of C++: - no way to express "lifetime relationships", they remain in comments or force you to work around the problem by using copied objects or worse, shared pointers. This resulted in very real bugs in our code due to a library returning structs that had to live shorter than some other object, without it being clear from the name of the struct. Coincidentally, this same library has a rust implementation, where keeping instances of this struct for too long is a compiler error. - no blessed way to express thread safety in the type system - terrible build system without a blessed package manager, which is not about to change because: - they are still headers everywhere. While modules are technically in C++20, tooling is not ready today (save for MSVC). The module implementation is also dubious in that it seems to cater to any niche use case in existence which adds a lot of complexity (and new opportunities for ODR violations...), instead of going "clean slate" and providing a simple system (preventing the split between declaration and definition and not being orthogonal to namespaces would have been a good start) - no ergonomic sum types. Sum types are very important to model business logic and it is hard to go back to languages lacking them. There are discussions of pattern matching for C++ but it's not in C++20. Several of these issues are impossible to fix in an existing language without breaking an unreasonable amount of existing code, so I don't see future versions of C++ reversing the statu quo. I also don't really trust the committee to achieve simple, ergonomic solutions, when I look to eg what was done with modules or coroutines (here I heard that the solution is to use third party libraries, but while it is tractable in Rust it is much less so in C++ due to the lack of satisfying tooling). You're welcome to elaborate if you disagree though.
      - ncmncm 5y ago
        In modern C++, you get the same benefits as are claimed for "lifetime annotations" by operating at a higher level. In effect, a library may adopt responsibility for what the Rust compiler would have enforced, and where it matters, they routinely do. This is no substantial burden. As a result, it has been a very long time since I last encountered a lifetime problem in my C++ code. Sum types work fine in C++. Pattern matching is an extra notational convenience on top of them. Rust has many nice convenience features, but lacks numerous other powerful features C++ provides. But this is not a good place to go into detail. If you care, there is plenty of material online. The point remains that comparisons, if done at all, should be done based on knowledge about current facts, not suppositions and hearsay.
ncmncm 5y ago
Yes. People are "only allowed to claim" to know about the merits of a language that they actually know. C++20 is the C++ to compare against, unless she wants to compare against, say, Rust as it was in 2014. C++98 is simply not an honest basis for comparison. I don't need "thinly veiled insults" when the facts speak for themselves. The author had no need to mention C++ at all. Then, she would not have found herself making ignorant comparisons.
- tialaramex 5y ago
  > C++20 is the C++ to compare against Admitting that each ISO standard is a distinct language (so, C++ 20 is distinct from C++ 17 and C++ 03 and so on) and insisting upon naming them this way would of course satisfy this concern. But doing so would also highlight the uncomfortable reality that C++ 20 isn't a real language programmers can use yet - compiler vendors are still implementing this standard and won't be done for a while. It would also highlight the fragmentation, you would need to pick one of these different C++ languages to write some software, and in doing so rule out using the others. And that's a pretty poor alternative to Rust, which is one real language Maxime and her team were able to use to write this software.
- metadat 5y ago
  ncmncm, what is your specific definition for "actually" knowing a programming language? If it's something like "mastery over most or all facets and nuances", perhaps there are a few thousand human beings in total who meet this qualification. Across all programming languages across the entire Earth.
  - ncmncm 5y ago
    Trolling is generally unwelcome here.

tialaramex 5y ago

Which remarks in particular made you think this?

dureuill 5y ago

I find your remark strange: the author is mainly comparing the scalability of Rust vs C. C++ does provide tools to build scalable software, and was already doing so in 1998 (few new features on this front since 98 I guess? Maybe modules, but using them for portable development in 2022 looks difficult given their state in compilers that aren't MSVC). I don't think this is a reason to prefer C++ over Rust (if anything, the tools for encapsulation and modularization provided by C++ are way less convenient and efficient than Rust's--speaking from experience of C++14 and Rust here). Also C++ has the massive drawbacks of lacking ADT, forcing headers on users (which is elaborated in the post I believe) and not offering a "safe mode" like Rust does (the tooling is also massively better, but somehow cargo felt like a hindrance to the author of that post, so there's that). It did surprise me that the author wouldn't elaborate on why C++ was not chosen, when her argument made it look like it could provide some of the advantages she found in Rust. However, she doesn't *have to* elaborate on every possible subject in that post, and implying she doesn't know the language (anymore) because of her not focusing on the reasons she didn't use it looks like a dubious stretch.

ncmncm 5y ago
The author does, in fact, bring up C++ herself. It is very strange to have dismissed it while knowing so little about its current status, and so worth bringing up. She didn't have to mention C++ at all. If you don't see C++20 as a very, very different language from C++98, it can only be because you know practically nothing about the topic. That is totally allowed, but expressing opinions based on knowing nothing produces worthless opinions.