12 ms·

I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should. h

by roca 4y ago

I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon https://github.com/carbon-language/carbon-lang/blob/trunk/do...

nindalf 4y ago
The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...). The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.” The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google. That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright. This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang. Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...)
- fxtentacle 4y ago
  My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.
  - bluGill 4y ago
    Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.
    - fxtentacle 4y ago
      Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
      - bluGill 4y ago
        Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .
  - CoastalCoder 4y ago
    > If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.
    - fxtentacle 4y ago
      Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
      - CoastalCoder 4y ago
        > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.
- sseagull 4y ago
  There was a bit of discussion yesterday about 'immaturity' in the programming community. To me, this is an example of a broader immaturity. Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way. Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...
  - not_the_fda 4y ago
    And we all know how well Goggle is at keeping interest in its side projects.
  - UncleMeat 4y ago
    A lot of people don't think that a frozen ABI is for the greater good of the community. It is specifically good for the set of people who cannot recompile their dependencies or cannot recompile their binaries. That's an ever-shrinking population.
    - menaerus 4y ago
      > That's an ever-shrinking population. Is that really so? I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. Like, all of the sudden all the software that we use on our machines becomes subtly broken since, well, new version of C or C++ runtime library is now out. I really don't see how this can be considered as a reasonable thing to do and therefore I understand and support the slow and careful ABI increments because the language is there to serve the goal which is beyond being a hostage to a handful of big players.
      - still_grokking 4y ago
        > I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. > I really don't see how this can be considered as a reasonable thing to do […] Well, Linux distributions do exactly this, since decades, and it works just fine.
- UncleMeat 4y ago
  > The committee chose an endorsement of indefinite ABI stability. It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.
  - JonChesterfield 4y ago
    The longer the committee holds onto the current status - that we neither promise stability nor will break it - the more users who value performance over never running a compiler will leave. The remaining members are increasingly likely to vote in favour of stability, despite that meaning performance overhead. By induction, the expected result should be that stability is chosen over performance in the future as well.
    - UncleMeat 4y ago
      I think that is indeed true, but if that is the future I'd really like the committee to actually say it. Right now, the folks who really do depend on being able to link against code compiled a decade ago can't fully trust that the status quo will remain.
codehalo 4y ago
They said the same thing for Java, Kotlin, and Go: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-a-garbage-collected-language-like-java-kotlin-or-go https://github.com/carbon-language/carbon-lang/blob/trunk/do...
otabdeveloper4 4y ago
Google isn't some grand authority. It's an old, tired and dysfunctional legacy IT company, like IBM or Oracle.
- smt88 4y ago
  They aren't a grand authority, but they maintain a huge amount of C++ code
  - mempko 4y ago
    C++ code using their flavor of strange guidelines... Google C++ is not how the rest of the world writes C++.
    - bfrog 4y ago
      Right, every org and individual has their own subset of c++ they use and exclude. C++ may have standards but that hardly matters when projects/orgs/individuals have their own variant of the language that is used. It’s a fallacy to think that there’s some idiomatic C++, there isn’t in practice.
  - deviantbit 4y ago
    Not more than Microsoft.
    - smt88 4y ago
      Microsoft has also officially and unofficially started replacing C++ with Rust.
      - pjmlp 4y ago
        So far it looks like experiments, besides a few projects like Azure Sphere SDK, Azure IoT (C# and Rust), and Rust/WinRT (which is even worse than C++/WinRT in regards to tooling in its current state, no authoring support for COM or VS integration). Office and Windows teams love C++ and COM too much to use anything else.
echelon 4y ago
As a Rust developer [1], I can't help but look at C++ as anything but a very dangerous Perl that has outlived its welcome. C++ can do all kinds of wacky stuff, all of which feels bolted on as the language tried to grow support for each passing paradigm and fad. The syntax is arcane and makes PHP look downright delectable. Pointer sigil placement and const correctness (dangerously) matters, template compile errors look like alien machine code, and no amount of new best practices will save you from old C++ codebases. I can't see new people reaching to learn C++. It will die with its current users. It's difficult to learn anyway, mostly because the materials and community are inaccessible and stuck in the 90's. And the important lessons on how to actually properly do memory management aren't enforced and only come from painful failures, direct tutelage, or reading an entire book on the subject twice over. If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win. Thankfully it's got so much more than that, and it fixes many of the systemic problems that C/C++ can't address. [1] (in production, generating revenue)
- j1elo 4y ago
  > I can't see new people reaching to learn C++ I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up. And if "people" in this sentence meant the companies using it, then again not a chance in the short term. Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase)
  - echelon 4y ago
    > I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up. Just like FORTRAN. (Sorry for the snark! I do agree with your points.) > Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase) Again, not disagreeing with you, but this is why it's good when companies get eaten by more nimble startups without the baggage. Legacy systems die due to business failure.
blub 4y ago
Are you writing this because it’s really interesting or because you’re a Rust promoter? Sneaking in comments about Rust in discussions about other languages is a classic guerrilla marketing move that the Rust community is known for. Assuming the best intentions, one should think how misguided it is to look up to amoral entities like corporations as role-models. At a macro level, Google does what brings them money. At a micro level what brings the engineers promotions and improves their reputation.
- deleted 4y ago
  [deleted]
- tialaramex 4y ago
  Rather than about Google, which is just a corporation albeit a large one, this is about the direction of C++. I've written about this before, there's a tendency to insist that if you just asked surely future C++ can accommodate whatever it is that is needed. What a bunch of people (many but not all from Google) did was write a C++ Proposal which says "This is what C++ needs" and the committee said "No". P2137 "Goals and Priorities for C++" That finally means you can have the next conversation, instead of "Surely C++ can do that" we can get to "OK, C++ won't do that - what are we going to do instead ?" The answers include a lot more Rust, as you have seen from Google and other entities. I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. When people whose first language is Spanish speak Spanish to each other on the bus and you overhear them, that's not "guerilla marketing" for Spanish by any useful definition. Here's the thing: If you think of this point as "guerilla marketing" then C++ has been riddled with "guerilla marketing" for Rust for several years. Vittorio's (failed) Epochs proposal for C++ 20 more or less just says "Look, Rust has this cool feature [Editions], we should do that too".
  - still_grokking 4y ago
    > I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. Even I agree with all the rest, it's known that grass roots marketing is very strong in Google. There are people who's job includes to write on high impact channels like HN to promote things. The Rust hype does not come from thin air. It gets generated in part with the help of a lot of money in the background. Of course this time the task isn't difficult as Rust sells itself in large parts just on the ground of it's features. But this process gets accelerated with money of course. There are not much languages that made it purely by (or despite ;-)) their virtues. One honorable exception is Scala. It made it into the Top20 even it does not have a marketing division, only a small team behind, and a community that seems to love to produce bad publicity consistently (even the language excels at quite some things!). And there are cases like PHP, C, Objective-C (and for some likely, JS)… But let's not talk about those, …, historical accidents…
alphanullmeric 4y ago
Even more interesting that rust has such an obnoxious showing in forum comments and GitHub surveys but little actual corporate adoption. Seems like nobody with actual money on the line wants to take the hit to productivity to fully switch to rust. Google is literally writing a whole new language instead of using rust and rustaceans are still trying to spin it as a pro rust move. And that’s after Go, which funnily enough has also seen way more industry usage than rust. Hobbyist language.
- pjmlp 4y ago
  AWS serveless runs on a type 1 hypervisor written in Rust. Google is using Rust on Android and Fuchsia. Carbon is for C++ code that they can't write from scratch in Rust, given its size. Azure Sphere SDK only supports C and Rust is now in preview mode. No C++ support planned. So while it is decades away from reaching C++ adoption level, it isn't as if the big names aren't making use of it on key projects.
  - alphanullmeric 4y ago
    I bring up Go because it’s of similar age to rust and yet significant projects have been written entirely or almost entirely in Go (ie. kubernetes, docker). Nothing of that scale has been written in rust. You don’t get to list things predominantly written in other languages lol.
    - pjmlp 4y ago
      Well, some CNCF projects seem to be moving from Go into Rust, if you want to use that as measure point as well.
    - zozbot234 4y ago
      Go is not similar age to Rust. Rust was not really viable pre-late 2018, when non-lexical lifetimes and async were added. Even Rust 1.0 (half-baked in retrospect) only came out in 2015.
  - touisteur 4y ago
DrBazza 4y ago
Also, https://www.val-lang.dev/ https://www.val-lang.dev/ seems more interesting. And http://www.jot.fm/issues/issue_2022_02/article2.pdf http://www.jot.fm/issues/issue_2022_02/article2.pdf > Safe by default: Val’s foundation of mutable value semantics ensures that ordinary code is memory safe, typesafe, and data-race-free. By explicit, auditable opt-in, programmers can use unsafe constructs for performance where necessary, and can build safe constructs using unsafe ones. Versus Carbon: > Carbon's premise is that C++ users can't give up performance to get safety. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#safety https://github.com/carbon-language/carbon-lang/blob/trunk/do...

by roca 4y ago

nindalf 4y ago

The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...). The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.” The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google. That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright. This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang. Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...)

fxtentacle 4y ago
My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.
- bluGill 4y ago
  Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.
  - fxtentacle 4y ago
    Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
    - bluGill 4y ago
      Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .
- CoastalCoder 4y ago
  > If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.
  - fxtentacle 4y ago
    Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
    - CoastalCoder 4y ago
      > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.
sseagull 4y ago
There was a bit of discussion yesterday about 'immaturity' in the programming community. To me, this is an example of a broader immaturity. Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way. Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...
- not_the_fda 4y ago
  And we all know how well Goggle is at keeping interest in its side projects.
- UncleMeat 4y ago
  A lot of people don't think that a frozen ABI is for the greater good of the community. It is specifically good for the set of people who cannot recompile their dependencies or cannot recompile their binaries. That's an ever-shrinking population.
  - menaerus 4y ago
    > That's an ever-shrinking population. Is that really so? I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. Like, all of the sudden all the software that we use on our machines becomes subtly broken since, well, new version of C or C++ runtime library is now out. I really don't see how this can be considered as a reasonable thing to do and therefore I understand and support the slow and careful ABI increments because the language is there to serve the goal which is beyond being a hostage to a handful of big players.
    - still_grokking 4y ago
      > I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. > I really don't see how this can be considered as a reasonable thing to do […] Well, Linux distributions do exactly this, since decades, and it works just fine.
UncleMeat 4y ago
> The committee chose an endorsement of indefinite ABI stability. It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.
- JonChesterfield 4y ago
  The longer the committee holds onto the current status - that we neither promise stability nor will break it - the more users who value performance over never running a compiler will leave. The remaining members are increasingly likely to vote in favour of stability, despite that meaning performance overhead. By induction, the expected result should be that stability is chosen over performance in the future as well.
  - UncleMeat 4y ago
    I think that is indeed true, but if that is the future I'd really like the committee to actually say it. Right now, the folks who really do depend on being able to link against code compiled a decade ago can't fully trust that the status quo will remain.

codehalo 4y ago

They said the same thing for Java, Kotlin, and Go: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-a-garbage-collected-language-like-java-kotlin-or-go https://github.com/carbon-language/carbon-lang/blob/trunk/do...

otabdeveloper4 4y ago

Google isn't some grand authority. It's an old, tired and dysfunctional legacy IT company, like IBM or Oracle.

smt88 4y ago
They aren't a grand authority, but they maintain a huge amount of C++ code
- mempko 4y ago
  C++ code using their flavor of strange guidelines... Google C++ is not how the rest of the world writes C++.
  - bfrog 4y ago
    Right, every org and individual has their own subset of c++ they use and exclude. C++ may have standards but that hardly matters when projects/orgs/individuals have their own variant of the language that is used. It’s a fallacy to think that there’s some idiomatic C++, there isn’t in practice.
- deviantbit 4y ago
  Not more than Microsoft.
  - smt88 4y ago
    Microsoft has also officially and unofficially started replacing C++ with Rust.
    - pjmlp 4y ago
      So far it looks like experiments, besides a few projects like Azure Sphere SDK, Azure IoT (C# and Rust), and Rust/WinRT (which is even worse than C++/WinRT in regards to tooling in its current state, no authoring support for COM or VS integration). Office and Windows teams love C++ and COM too much to use anything else.

echelon 4y ago

As a Rust developer [1], I can't help but look at C++ as anything but a very dangerous Perl that has outlived its welcome. C++ can do all kinds of wacky stuff, all of which feels bolted on as the language tried to grow support for each passing paradigm and fad. The syntax is arcane and makes PHP look downright delectable. Pointer sigil placement and const correctness (dangerously) matters, template compile errors look like alien machine code, and no amount of new best practices will save you from old C++ codebases. I can't see new people reaching to learn C++. It will die with its current users. It's difficult to learn anyway, mostly because the materials and community are inaccessible and stuck in the 90's. And the important lessons on how to actually properly do memory management aren't enforced and only come from painful failures, direct tutelage, or reading an entire book on the subject twice over. If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win. Thankfully it's got so much more than that, and it fixes many of the systemic problems that C/C++ can't address. [1] (in production, generating revenue)

j1elo 4y ago
> I can't see new people reaching to learn C++ I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up. And if "people" in this sentence meant the companies using it, then again not a chance in the short term. Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase)
- echelon 4y ago
  > I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up. Just like FORTRAN. (Sorry for the snark! I do agree with your points.) > Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase) Again, not disagreeing with you, but this is why it's good when companies get eaten by more nimble startups without the baggage. Legacy systems die due to business failure.

blub 4y ago

Are you writing this because it’s really interesting or because you’re a Rust promoter? Sneaking in comments about Rust in discussions about other languages is a classic guerrilla marketing move that the Rust community is known for. Assuming the best intentions, one should think how misguided it is to look up to amoral entities like corporations as role-models. At a macro level, Google does what brings them money. At a micro level what brings the engineers promotions and improves their reputation.

deleted 4y ago
[deleted]
tialaramex 4y ago
Rather than about Google, which is just a corporation albeit a large one, this is about the direction of C++. I've written about this before, there's a tendency to insist that if you just asked surely future C++ can accommodate whatever it is that is needed. What a bunch of people (many but not all from Google) did was write a C++ Proposal which says "This is what C++ needs" and the committee said "No". P2137 "Goals and Priorities for C++" That finally means you can have the next conversation, instead of "Surely C++ can do that" we can get to "OK, C++ won't do that - what are we going to do instead ?" The answers include a lot more Rust, as you have seen from Google and other entities. I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. When people whose first language is Spanish speak Spanish to each other on the bus and you overhear them, that's not "guerilla marketing" for Spanish by any useful definition. Here's the thing: If you think of this point as "guerilla marketing" then C++ has been riddled with "guerilla marketing" for Rust for several years. Vittorio's (failed) Epochs proposal for C++ 20 more or less just says "Look, Rust has this cool feature [Editions], we should do that too".
- still_grokking 4y ago
  > I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. Even I agree with all the rest, it's known that grass roots marketing is very strong in Google. There are people who's job includes to write on high impact channels like HN to promote things. The Rust hype does not come from thin air. It gets generated in part with the help of a lot of money in the background. Of course this time the task isn't difficult as Rust sells itself in large parts just on the ground of it's features. But this process gets accelerated with money of course. There are not much languages that made it purely by (or despite ;-)) their virtues. One honorable exception is Scala. It made it into the Top20 even it does not have a marketing division, only a small team behind, and a community that seems to love to produce bad publicity consistently (even the language excels at quite some things!). And there are cases like PHP, C, Objective-C (and for some likely, JS)… But let's not talk about those, …, historical accidents…

alphanullmeric 4y ago

Even more interesting that rust has such an obnoxious showing in forum comments and GitHub surveys but little actual corporate adoption. Seems like nobody with actual money on the line wants to take the hit to productivity to fully switch to rust. Google is literally writing a whole new language instead of using rust and rustaceans are still trying to spin it as a pro rust move. And that’s after Go, which funnily enough has also seen way more industry usage than rust. Hobbyist language.

pjmlp 4y ago
AWS serveless runs on a type 1 hypervisor written in Rust. Google is using Rust on Android and Fuchsia. Carbon is for C++ code that they can't write from scratch in Rust, given its size. Azure Sphere SDK only supports C and Rust is now in preview mode. No C++ support planned. So while it is decades away from reaching C++ adoption level, it isn't as if the big names aren't making use of it on key projects.
- alphanullmeric 4y ago
  I bring up Go because it’s of similar age to rust and yet significant projects have been written entirely or almost entirely in Go (ie. kubernetes, docker). Nothing of that scale has been written in rust. You don’t get to list things predominantly written in other languages lol.
  - pjmlp 4y ago
    Well, some CNCF projects seem to be moving from Go into Rust, if you want to use that as measure point as well.
  - zozbot234 4y ago
    Go is not similar age to Rust. Rust was not really viable pre-late 2018, when non-lexical lifetimes and async were added. Even Rust 1.0 (half-baked in retrospect) only came out in 2015.
- touisteur 4y ago

DrBazza 4y ago

Also, https://www.val-lang.dev/ https://www.val-lang.dev/ seems more interesting. And http://www.jot.fm/issues/issue_2022_02/article2.pdf http://www.jot.fm/issues/issue_2022_02/article2.pdf > Safe by default: Val’s foundation of mutable value semantics ensures that ordinary code is memory safe, typesafe, and data-race-free. By explicit, auditable opt-in, programmers can use unsafe constructs for performance where necessary, and can build safe constructs using unsafe ones. Versus Carbon: > Carbon's premise is that C++ users can't give up performance to get safety. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#safety https://github.com/carbon-language/carbon-lang/blob/trunk/do...