9 ms·

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". He is right on this one. Pretty much in every discussion abou

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". He is right on this one. Pretty much in every discussion about Programming Languages people write how good Rust is and complain about how bad C++ is but the reality is, C++ it's one of the most used languages in the world. This quote could be a very harsh reply to Rust vs C++.

sgift 3y ago
No, it could be a very stupid reply to Rust vs C++ since people do write in Rust. Bigger programs get written in it all the time and - what a surprise - people who use it have things they are annoyed about, which is why it gets improved. To me this is one of the most stupid things he's ever uttered on one hand and the most useful one on the other. Cause it can be used to remind people that there's always trade-offs, which is a good thing if a discussion gets a bit too heated and "I am right!" "No, I am right!", but it can also be used, and most often is, as a very shallow and arrogant dismissal - funny enough, especially by C++ zealots, IME - of someone trying to fix some things. As if trying to do things better is somehow an affront to their greatness.
- einpoklum 3y ago
  FWIW, I think Bjarne and other C++ magnates have a plan for eating Rust's lunch by allowing for "safe"/"unsafe" within C++.
  - sgift 3y ago
    Sounds like something they could try. We'll see what happens. It's not like I expect C++ to "roll over" and just declare that they don't care anymore if people use the language.
  - dralley 3y ago
    I'm skeptical of the value of adding on "safe / unsafe" to C++ at this point. It's a bit like adding type annotations to Python. Better than nothing I suppose, but there's 30+ years of C/C++ that doesn't and will never be opted-in to these features, and the value declines rapidly when only 10% of the codebase (including dependencies) can be considered "safe" vs. when 99.9% of it can be. https://cor3ntin.github.io/posts/safety/ https://cor3ntin.github.io/posts/safety/
    - Animats 3y ago
      > I'm skeptical of the value of adding on "safe / unsafe" to C++ at this point. Me too. I've went down the road of a safer C/C++ a decade ago. So have many others. It's not impossible. But backwards compatibility is really tough. The existing attempts at a better C or C++ did not work out. After three years of Rust, I have some misgivings. Rust does many things right, and the rigor does get you reliable programs if you stick to safe Rust, which I do. But there are problems. - The single-ownership thing is useful but very restrictive. Lack of back references is a serious problem. Yet, so often, you want to have something that talks to its owner. Refcount everything, and you've re-invented Python and moved the problem to run time. If you have to use handles and hashes, you're lost the value that Rust added. Something like static-analyzed safe weak back references is needed, and that's a hard theoretical problem. Think of this as working like single strong forward references and weak back references that can become strong only temporarily. Compile time checking like the borrow checker would enforce rules that eliminated the need for reference counts. This is probably possible, and is hard to do in a way that is not too restrictive to be useful. Someone has to work through the common design patterns for trees, lists you can modify in the middle, and such. Good PhD topic for someone. - Traits turn out to be useful for only a limited class of problems. Traits are not a substitute for classes. Converting a class-oriented program to Rust is very tough. Once new Rust programmers get past the syntax, those two issues are the big ones that prevent conversion of existing programs to safe Rust. There's a big impedance mismatch. You can't just convert; you have to redesign. Which is hard.
  - tialaramex 3y ago
    I mean, sure, Bjarne calls his proposed way forward "safety profiles". Most fundamentally, this completely misunderstands the nature of the problem. This is a technical change, but the most important problem C++ has is cultural. So, they're not even addressing the right problem. In his original talk about this Bjarne even repeatedly describes his approach as a "strategy" which practically begged someone to say "Culture Eats Strategy For Breakfast" but no-one did. But let's imagine that C++ culture magically is fixed by pixies or whatever, leaving only technical problems, which safety profiles could address. The next big problem is that Rust's safety is compositional. The many different kinds of "safety" delivered via Bjarne's "safety profiles" don't compose, safety A + safety B = no safety. So this makes it largely useless from a software engineering point of view. Once you've cleared these two fundamental obstacles you're back to more mundane limitations like timing. Rust 1.0 shipped in 2015. There are teams out there already with many years of Rust experience in practice. But Bjarne's "Safety Profiles" aren't available in your C++ compiler today, and won't be for years to come, perhaps many years. Are you confident that starting this far behind the pack will be OK?
    - GoblinSlayer 3y ago
      If culture wanted safety strategy in the compiler, wouldn't it need to standardize it? >There are teams out there already with many years of Rust experience in practice. They routinely use nightly version, no?
      - steveklabnik 3y ago
        > They routinely use nightly version, no? Depends on what you mean by "routinely." In 2020, the last year that the annual survey published these numbers, 8.7% of Rust programmers used exclusively nightly. It has been dropping every year. Some people do occasionally use nightly; at my job, most code is on stable, but there are a few projects that do currently require a couple of nightly specific things.
    - einpoklum 3y ago
      > but the most important problem C++ has is cultural That part, Bjarne and others have been working on for at least two decades I think. There's a lot of indoctrination/education about "staying safe" so to speak, through better coding practices, extended standard library facilities, static analysis and so forth. And from the little I can see, this is seeping into the C++ culture. > The many different kinds of "safety" delivered via Bjarne's "safety profiles" don't compose I'm not familiar enough with the details. But, about Rust - I was under the (possibly wrong) impression that you have the binary of either safe or unsafe: https://doc.rust-lang.org/std/keyword.unsafe.html https://doc.rust-lang.org/std/keyword.unsafe.html > Are you confident that starting this far behind the pack will be OK? You're counting the wrong thing IMHO. If you count software systems of note, or add up their sizes; or count developers; or count organization; or add up turnover; etc. - its Python, Java, C, C++ in some sort of order that are at the head of the pack. Rust has certain benefits which make it attractive to jump onto its bandwagon - but it needs a lot of bandwagon-jumping to take the lead. If you can achieve more or less the same thing by just fiddling with your C++ development environment, then people might just not switch.
  - pjmlp 3y ago
    Profiles will help on the domains where C++ is going to stay for a long time, like HPC, GPUs, game development, GCC/LLVM. However it is kind of late in domains where Rust, or other safer languages are already being used. They won't rewrite back into C++.
    - einpoklum 3y ago
      > domains where Rust ... [is] already being used The point is that Rust usage is still quite limited. This is a bit like C++ and D, two decades back; or perhaps even Scala and Java. The analogy isn't perfect, but the point is you had a language with a lot of potential usability-domain overlap which addressed some or many pain points and failures of the older, more popular language - but the older language embraced some of the alternative ideas, adopted them in a more-or-less compatible way, and made it not-attractive-enough to switch. So the newer languages lost momentum, and at least in the case of D - stopped gaining users and eventually sank into oblivion. > other safer languages ... won't rewrite back into C++. I mostly agree. Except... that some safe languages, like Java, pay for safety with a lot of overhead. And Dennard scaling is over. So, over time, there is some pressure to replace Java, or maybe C# code with something closer-to-the-metal. But we'll see.
      - pjmlp 3y ago
        D suffered from lack of focus, and company sponsoring, hence why it hardly mattered to C++ folks. The domains that Java and .NET took away from C++ aren't coming back to C++, even if now they feel the pressure to have AOT and value types with better low level coding primitives. Additionally Java and .NET applications that get rewritten, most likely will be in one of those C++ wannabe successors, even if C++ is part of the equation by using GCC/LLVM backends.
        einpoklum 3y ago
        The thing is, that the "C++ successor language" sometimes ends up being C++ itself, a decade or two later. As an example, take this question from 2008: "How do I tokenize a string in C++?" https://stackoverflow.com/q/53849/1593077 https://stackoverflow.com/q/53849/1593077 A very popular, straightforward, and traditional-style answer to this question, , given early on, was: vector<string> split(const char *str, char c = ' ') { std::vector<std::string> result; do { const char *begin = str; while(*str != c && *str) { str++; } result.push_back(std::string(begin, str)); } while (0 != *str++); return result; } but a recent answer is: auto results = str | ranges::views::tokenize(" ",1); which is in lazy-evaluated functional style, and doesn't even directly utilize the fugly standard C++ string class. This example is of course a bit simplistic (since the main change exhibited here is in the standard library), but the point is that the language has demonstrasted strong abilities to reconfigure how users tend to write code. But - perhaps I'm giving it more credit than it's due any this won't comen to pass.
ChrisSD 3y ago
If you think nobody complains about Rust then you haven't visited HN much recently ;). Heck, Bjarne Stroustrup himself has recently taken to complaining about Rust in papers and talks (though most recently he's taken to referring to it without naming names).
- tialaramex 3y ago
  There's a noticeable difference between what you get from somebody like Barry Revzin, who understands C++ and Rust well and has very specific criiques, and from people like Bjarne or Herb who seem to be relying on superficial impressions at best.
epolanski 3y ago
I came to the conclusion that the inverse is true, people tend to love languages they don't use. I used to love Lisp and Racket. But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell. People should not program programming languages. There's use cases for this style of programming, but they aren't how general-purpose programming should look like.
- neilv 3y ago
  > But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL. Just like we use libraries judiciously in many languages. (Well, we should, but casually pulling in a hundred libraries is more a Python/JS/Rust convention, than a Lisp family one.) > Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell. Is this a problem when Haskell is used professionally by software engineering teams? Or are you speaking of code by academics/students, who don't have a lot of experience on professional software engineering teams? Or by hobbyists, who are (rightly) indulging, and writing code however they want (more power to them), not writing how they have to at their day job?
  - specialist 3y ago
    Yes but: u/epolanski is referring to the abuse of metaprogramming, such that every org, every project creates its own bespoke mutant creole which remains C++ (or Haskell, Forth, LISP) in name only. Java's founders wisely omitted metaprogramming. But memories are short. And chaos always finds a way. So now Java has its own medley of obfuscation strategies. Annotations, aspects, inversion of control, dependency injection, logging frameworks, etc.
harry8 3y ago
You can already program. When you program a hobby/research project in the language you want to learn (better) you program /with/ the grain of the language. It's a nice experience. Move over to implementing someone else's hard requirements where you have to make that happen, with time pressure - you find yourself going against the grain of the language by necessity and start describing the difficulties, sometimes colorfully. People waxing lyrical about (this year haskell, rust for example) and who don't have a list of complaints are in the first category.
deleted 3y ago
[deleted]
WiSaGaN 3y ago
I think you would have a very hard time defending the claim that 'nobody uses Rust,' given its current adoption trend in major technology companies like Microsoft and its integration in software projects like the Linux kernel.
- deleted 3y ago
  [deleted]
flykespice 3y ago
A language usage doesn't correlates with quality. I wish people would stop spamming that quote on discussions here on this site as shallow dismissal everytime someone posts their critique.
hardware2win 3y ago
Ecosystem effect.

sgift 3y ago

No, it could be a very stupid reply to Rust vs C++ since people do write in Rust. Bigger programs get written in it all the time and - what a surprise - people who use it have things they are annoyed about, which is why it gets improved. To me this is one of the most stupid things he's ever uttered on one hand and the most useful one on the other. Cause it can be used to remind people that there's always trade-offs, which is a good thing if a discussion gets a bit too heated and "I am right!" "No, I am right!", but it can also be used, and most often is, as a very shallow and arrogant dismissal - funny enough, especially by C++ zealots, IME - of someone trying to fix some things. As if trying to do things better is somehow an affront to their greatness.

einpoklum 3y ago
FWIW, I think Bjarne and other C++ magnates have a plan for eating Rust's lunch by allowing for "safe"/"unsafe" within C++.
- sgift 3y ago
  Sounds like something they could try. We'll see what happens. It's not like I expect C++ to "roll over" and just declare that they don't care anymore if people use the language.
- dralley 3y ago
  I'm skeptical of the value of adding on "safe / unsafe" to C++ at this point. It's a bit like adding type annotations to Python. Better than nothing I suppose, but there's 30+ years of C/C++ that doesn't and will never be opted-in to these features, and the value declines rapidly when only 10% of the codebase (including dependencies) can be considered "safe" vs. when 99.9% of it can be. https://cor3ntin.github.io/posts/safety/ https://cor3ntin.github.io/posts/safety/
  - Animats 3y ago
    > I'm skeptical of the value of adding on "safe / unsafe" to C++ at this point. Me too. I've went down the road of a safer C/C++ a decade ago. So have many others. It's not impossible. But backwards compatibility is really tough. The existing attempts at a better C or C++ did not work out. After three years of Rust, I have some misgivings. Rust does many things right, and the rigor does get you reliable programs if you stick to safe Rust, which I do. But there are problems. - The single-ownership thing is useful but very restrictive. Lack of back references is a serious problem. Yet, so often, you want to have something that talks to its owner. Refcount everything, and you've re-invented Python and moved the problem to run time. If you have to use handles and hashes, you're lost the value that Rust added. Something like static-analyzed safe weak back references is needed, and that's a hard theoretical problem. Think of this as working like single strong forward references and weak back references that can become strong only temporarily. Compile time checking like the borrow checker would enforce rules that eliminated the need for reference counts. This is probably possible, and is hard to do in a way that is not too restrictive to be useful. Someone has to work through the common design patterns for trees, lists you can modify in the middle, and such. Good PhD topic for someone. - Traits turn out to be useful for only a limited class of problems. Traits are not a substitute for classes. Converting a class-oriented program to Rust is very tough. Once new Rust programmers get past the syntax, those two issues are the big ones that prevent conversion of existing programs to safe Rust. There's a big impedance mismatch. You can't just convert; you have to redesign. Which is hard.
- tialaramex 3y ago
  I mean, sure, Bjarne calls his proposed way forward "safety profiles". Most fundamentally, this completely misunderstands the nature of the problem. This is a technical change, but the most important problem C++ has is cultural. So, they're not even addressing the right problem. In his original talk about this Bjarne even repeatedly describes his approach as a "strategy" which practically begged someone to say "Culture Eats Strategy For Breakfast" but no-one did. But let's imagine that C++ culture magically is fixed by pixies or whatever, leaving only technical problems, which safety profiles could address. The next big problem is that Rust's safety is compositional. The many different kinds of "safety" delivered via Bjarne's "safety profiles" don't compose, safety A + safety B = no safety. So this makes it largely useless from a software engineering point of view. Once you've cleared these two fundamental obstacles you're back to more mundane limitations like timing. Rust 1.0 shipped in 2015. There are teams out there already with many years of Rust experience in practice. But Bjarne's "Safety Profiles" aren't available in your C++ compiler today, and won't be for years to come, perhaps many years. Are you confident that starting this far behind the pack will be OK?
  - GoblinSlayer 3y ago
    If culture wanted safety strategy in the compiler, wouldn't it need to standardize it? >There are teams out there already with many years of Rust experience in practice. They routinely use nightly version, no?
    - steveklabnik 3y ago
      > They routinely use nightly version, no? Depends on what you mean by "routinely." In 2020, the last year that the annual survey published these numbers, 8.7% of Rust programmers used exclusively nightly. It has been dropping every year. Some people do occasionally use nightly; at my job, most code is on stable, but there are a few projects that do currently require a couple of nightly specific things.
  - einpoklum 3y ago
    > but the most important problem C++ has is cultural That part, Bjarne and others have been working on for at least two decades I think. There's a lot of indoctrination/education about "staying safe" so to speak, through better coding practices, extended standard library facilities, static analysis and so forth. And from the little I can see, this is seeping into the C++ culture. > The many different kinds of "safety" delivered via Bjarne's "safety profiles" don't compose I'm not familiar enough with the details. But, about Rust - I was under the (possibly wrong) impression that you have the binary of either safe or unsafe: https://doc.rust-lang.org/std/keyword.unsafe.html https://doc.rust-lang.org/std/keyword.unsafe.html > Are you confident that starting this far behind the pack will be OK? You're counting the wrong thing IMHO. If you count software systems of note, or add up their sizes; or count developers; or count organization; or add up turnover; etc. - its Python, Java, C, C++ in some sort of order that are at the head of the pack. Rust has certain benefits which make it attractive to jump onto its bandwagon - but it needs a lot of bandwagon-jumping to take the lead. If you can achieve more or less the same thing by just fiddling with your C++ development environment, then people might just not switch.
- pjmlp 3y ago
  Profiles will help on the domains where C++ is going to stay for a long time, like HPC, GPUs, game development, GCC/LLVM. However it is kind of late in domains where Rust, or other safer languages are already being used. They won't rewrite back into C++.
  - einpoklum 3y ago
    > domains where Rust ... [is] already being used The point is that Rust usage is still quite limited. This is a bit like C++ and D, two decades back; or perhaps even Scala and Java. The analogy isn't perfect, but the point is you had a language with a lot of potential usability-domain overlap which addressed some or many pain points and failures of the older, more popular language - but the older language embraced some of the alternative ideas, adopted them in a more-or-less compatible way, and made it not-attractive-enough to switch. So the newer languages lost momentum, and at least in the case of D - stopped gaining users and eventually sank into oblivion. > other safer languages ... won't rewrite back into C++. I mostly agree. Except... that some safe languages, like Java, pay for safety with a lot of overhead. And Dennard scaling is over. So, over time, there is some pressure to replace Java, or maybe C# code with something closer-to-the-metal. But we'll see.
    - pjmlp 3y ago
      D suffered from lack of focus, and company sponsoring, hence why it hardly mattered to C++ folks. The domains that Java and .NET took away from C++ aren't coming back to C++, even if now they feel the pressure to have AOT and value types with better low level coding primitives. Additionally Java and .NET applications that get rewritten, most likely will be in one of those C++ wannabe successors, even if C++ is part of the equation by using GCC/LLVM backends.
      - einpoklum 3y ago
        The thing is, that the "C++ successor language" sometimes ends up being C++ itself, a decade or two later. As an example, take this question from 2008: "How do I tokenize a string in C++?" https://stackoverflow.com/q/53849/1593077 https://stackoverflow.com/q/53849/1593077 A very popular, straightforward, and traditional-style answer to this question, , given early on, was: vector<string> split(const char *str, char c = ' ') { std::vector<std::string> result; do { const char *begin = str; while(*str != c && *str) { str++; } result.push_back(std::string(begin, str)); } while (0 != *str++); return result; } but a recent answer is: auto results = str | ranges::views::tokenize(" ",1); which is in lazy-evaluated functional style, and doesn't even directly utilize the fugly standard C++ string class. This example is of course a bit simplistic (since the main change exhibited here is in the standard library), but the point is that the language has demonstrasted strong abilities to reconfigure how users tend to write code. But - perhaps I'm giving it more credit than it's due any this won't comen to pass.

ChrisSD 3y ago

If you think nobody complains about Rust then you haven't visited HN much recently ;). Heck, Bjarne Stroustrup himself has recently taken to complaining about Rust in papers and talks (though most recently he's taken to referring to it without naming names).

tialaramex 3y ago
There's a noticeable difference between what you get from somebody like Barry Revzin, who understands C++ and Rust well and has very specific criiques, and from people like Bjarne or Herb who seem to be relying on superficial impressions at best.

epolanski 3y ago

I came to the conclusion that the inverse is true, people tend to love languages they don't use. I used to love Lisp and Racket. But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell. People should not program programming languages. There's use cases for this style of programming, but they aren't how general-purpose programming should look like.

neilv 3y ago
> But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL. Just like we use libraries judiciously in many languages. (Well, we should, but casually pulling in a hundred libraries is more a Python/JS/Rust convention, than a Lisp family one.) > Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell. Is this a problem when Haskell is used professionally by software engineering teams? Or are you speaking of code by academics/students, who don't have a lot of experience on professional software engineering teams? Or by hobbyists, who are (rightly) indulging, and writing code however they want (more power to them), not writing how they have to at their day job?
- specialist 3y ago
  Yes but: u/epolanski is referring to the abuse of metaprogramming, such that every org, every project creates its own bespoke mutant creole which remains C++ (or Haskell, Forth, LISP) in name only. Java's founders wisely omitted metaprogramming. But memories are short. And chaos always finds a way. So now Java has its own medley of obfuscation strategies. Annotations, aspects, inversion of control, dependency injection, logging frameworks, etc.

harry8 3y ago

You can already program. When you program a hobby/research project in the language you want to learn (better) you program /with/ the grain of the language. It's a nice experience. Move over to implementing someone else's hard requirements where you have to make that happen, with time pressure - you find yourself going against the grain of the language by necessity and start describing the difficulties, sometimes colorfully. People waxing lyrical about (this year haskell, rust for example) and who don't have a list of complaints are in the first category.

deleted 3y ago

[deleted]

WiSaGaN 3y ago

I think you would have a very hard time defending the claim that 'nobody uses Rust,' given its current adoption trend in major technology companies like Microsoft and its integration in software projects like the Linux kernel.

deleted 3y ago
[deleted]

flykespice 3y ago

A language usage doesn't correlates with quality. I wish people would stop spamming that quote on discussions here on this site as shallow dismissal everytime someone posts their critique.

hardware2win 3y ago

Ecosystem effect.