7 ms·

As a longtime C++ user, I'd sooner just upgrade to a better system programming language. C++ is a weird mess.

by QuadrupleA 2y ago

RivieraKid 2y ago
Which one would you recommend? My ideal C++ alternative would be something like Swift but faster.
- nextaccountic 2y ago
  Just so you know, Rust is in many ways a lot like Swift, and not just because many Rust compiler devs went later to work on the Swift compiler.
- deepsun 2y ago
  For low-level compiled system applications: Rust, Zig etc. For compiled garbage-collected applications (web/cli): Go. For high-level applications (web/cli/etl/desktop): Java, C#. Also here is good writeup: https://hackernoon.com/the-real-c-killers-not-you-rust https://hackernoon.com/the-real-c-killers-not-you-rust discussed here two times: https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=39770467 https://news.ycombinator.com/item?id=39770467
  - ghosty141 2y ago
    I have a similar opinion: For low level stuff Rust or more "obscure" langs like Zig or Carbon offer a lot in that space. The moment you leave low-level I'd always go with C#/Java or TS for web-stuff. The productivity gains you get from switching from C++ to C# are absolutely insane.
  - neonsunset 2y ago
    Little reason to use Go here. C# is a much better language at allowing you to tactically write high-performance low-level code where it matters and relying on higher level abstractions when it's not (struct generics are just like in Rust allowing you to expend a little effort for achieving zero-cost abstractions, although not as convenient as just using objects everywhere). Go is inadequate, poorly typed, has abysmal FFI overhead and bloated binary sizes as it does no metadata compression and other tricks C#'s AOT compilation does.
    - paulddraper 2y ago
      With Go, I can easily cross-compile a statically linked binary for each of the major platforms. You cannot do that with C#.
      - posix_monad 2y ago
        Cross compilation story in C# is very good actually.
        paulddraper 2y ago
        With Go, I can use my Linux CI server to compile a statically linked binary for MacOS.
        posix_monad 2y ago
        You can publish across platforms with modern .NET
  - nickpp 2y ago
    But the fact that developers often need to be able to cover any one (or even multiple) of these areas, and that language proficiency (with platform APIs and various quirks) is quite hard to achieve - makes me think that the actual alternative is the elephant in the room, the one not even listed here: JavaScript.
    - deepsun 2y ago
      Having been programming continuously on JavaScript for over 20 with all the popular frameworks, I'd try to stay away from it as much as possible: 1. Dynamic typing must die. Except for R/Julia/Python (aka JuPyteR) notebooks use-case, where it's awesome. My list includes only statically-typed languages. Typescript is much better, but its type-checking still fails sometimes, unlike real static-typed languages. 2. NPM is a mess that allows any transitive dependency to run arbitrary code on your machine at a time of installation (including cleaning up after itself). Compare that to Java's Maven -- libs quality is much better. no arbitrary code runs, just downloading.
      - throwitaway1123 2y ago
        > allows any transitive dependency to run arbitrary code on your machine at a time of installation This point gets parroted so often on HN [1]. You can install packages with the --ignore-scripts flag to disable this behavior, or just set the option globally in your NPM config file. I do like the way Bun disables lifecycle scripts by default [2], but it takes me all of two seconds to run `npm config set ignore-scripts=true` on a new machine, so it's basically a non-issue for me. [1] https://news.ycombinator.com/item?id=38797176 https://news.ycombinator.com/item?id=38797176 [2] https://bun.sh/docs/cli/install#lifecycle-scripts https://bun.sh/docs/cli/install#lifecycle-scripts
    - palata 2y ago
      Are you seriously mentioning JS as a C++ alternative? I am confused.
      - nickpp 2y ago
- jandrewrogers 2y ago
  I think it depends on what you use C++ for. For low-level high-performance systems work, the thing I probably miss most in many of the alternatives is the extensive metaprogramming and generics capabilities of C++. This is unfortunate given both the power of this language feature and how much opportunity there is to improve the ergonomics of C++ metaprogramming.
- neonsunset 2y ago
  That's C# :)
- hot_gril 2y ago
  Rust, since you're mentioning speed. It was refreshing to use, partially because the standard library is so much nicer.
isopede 2y ago
C++ has long surpassed the point where mere mortals like me can understand it; It's so loaded with baggage, footguns, and inscrutable standards language that honestly I think the only thing keeping it going is institutional inertia and "backwards compatbility" (air quotes). I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the day rust or some other language finally supplants them.
- dlivingston 2y ago
  What's stopping Rust from being used in embedded?
  - selfmodruntime 2y ago
    Documentation is severely lacking and vendor specific libraries and build systems are sometimes interfering with cargo. There‘s also the problem of rust-analyzer being relatively flaky in general and even more so when being used with environment specific / KConfig / build system feature flags that enable or disable certain library headers.
  - isopede 2y ago
    Among other things, tooling and vendor libraries. Vendor libraries are often composed of thousands upon thousands of lines of auto-generated C headers and written in some bespoke format. Demonstration code and/or sample drivers are almost invariably provided in C. Of course you _can_ rewrite these in Rust, but if you're an engineer trying to get shit working, you'd first basically have to reinvent the whole wheel just to do bringup. I don't even want to talk about the state of proprietary vendor tooling...
- selfmodruntime 2y ago
  I‘m currently doing work with Rust on Esp32 platforms and I‘ll have to say, it‘s not quite ready yet. Debug tools still have issues, and we‘re facing some problems with vendor specific magic in Esp IDF version 5.
ilovecaching 2y ago
The grass is always greener. Rust also has rough edges and there's maybe a fraction of a fraction of a percent of Rust code out there to work on in the corpus of systems software, and a lot of it has to interface with C anyway. Even crates in Rust are overly complicated and they've set up a system that allows people to squat on well known names. I think if you want to work on systems software you should enjoy working with legacy cruft, otherwise you're just going to be miserable. I mean it's everywhere from the language, to the POSIX APIs, to device drivers, to hardware quirks... C++ is only a quarter of the problem.
shrimp_emoji 2y ago
And yet C++ is the best programming language. If you had to pick only one language to use, for everything, you'd pick C++. It can do it all, from bit fields to polymorphic classes to closures; it's safer and saner than C (you haven't read the standards if you think otherwise); it's got a level of support and maturity (and probably lifespan) than any other comparable language.

As a longtime C++ user, I'd sooner just upgrade to a better system programming language. C++ is a weird mess.

RivieraKid 2y ago

Which one would you recommend? My ideal C++ alternative would be something like Swift but faster.

nextaccountic 2y ago
Just so you know, Rust is in many ways a lot like Swift, and not just because many Rust compiler devs went later to work on the Swift compiler.
deepsun 2y ago
For low-level compiled system applications: Rust, Zig etc. For compiled garbage-collected applications (web/cli): Go. For high-level applications (web/cli/etl/desktop): Java, C#. Also here is good writeup: https://hackernoon.com/the-real-c-killers-not-you-rust https://hackernoon.com/the-real-c-killers-not-you-rust discussed here two times: https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=39770467 https://news.ycombinator.com/item?id=39770467
- ghosty141 2y ago
  I have a similar opinion: For low level stuff Rust or more "obscure" langs like Zig or Carbon offer a lot in that space. The moment you leave low-level I'd always go with C#/Java or TS for web-stuff. The productivity gains you get from switching from C++ to C# are absolutely insane.
- neonsunset 2y ago
  Little reason to use Go here. C# is a much better language at allowing you to tactically write high-performance low-level code where it matters and relying on higher level abstractions when it's not (struct generics are just like in Rust allowing you to expend a little effort for achieving zero-cost abstractions, although not as convenient as just using objects everywhere). Go is inadequate, poorly typed, has abysmal FFI overhead and bloated binary sizes as it does no metadata compression and other tricks C#'s AOT compilation does.
  - paulddraper 2y ago
    With Go, I can easily cross-compile a statically linked binary for each of the major platforms. You cannot do that with C#.
    - posix_monad 2y ago
      Cross compilation story in C# is very good actually.
      - paulddraper 2y ago
        With Go, I can use my Linux CI server to compile a statically linked binary for MacOS.
        posix_monad 2y ago
        You can publish across platforms with modern .NET
- nickpp 2y ago
  But the fact that developers often need to be able to cover any one (or even multiple) of these areas, and that language proficiency (with platform APIs and various quirks) is quite hard to achieve - makes me think that the actual alternative is the elephant in the room, the one not even listed here: JavaScript.
  - deepsun 2y ago
    Having been programming continuously on JavaScript for over 20 with all the popular frameworks, I'd try to stay away from it as much as possible: 1. Dynamic typing must die. Except for R/Julia/Python (aka JuPyteR) notebooks use-case, where it's awesome. My list includes only statically-typed languages. Typescript is much better, but its type-checking still fails sometimes, unlike real static-typed languages. 2. NPM is a mess that allows any transitive dependency to run arbitrary code on your machine at a time of installation (including cleaning up after itself). Compare that to Java's Maven -- libs quality is much better. no arbitrary code runs, just downloading.
    - throwitaway1123 2y ago
      > allows any transitive dependency to run arbitrary code on your machine at a time of installation This point gets parroted so often on HN [1]. You can install packages with the --ignore-scripts flag to disable this behavior, or just set the option globally in your NPM config file. I do like the way Bun disables lifecycle scripts by default [2], but it takes me all of two seconds to run `npm config set ignore-scripts=true` on a new machine, so it's basically a non-issue for me. [1] https://news.ycombinator.com/item?id=38797176 https://news.ycombinator.com/item?id=38797176 [2] https://bun.sh/docs/cli/install#lifecycle-scripts https://bun.sh/docs/cli/install#lifecycle-scripts
  - palata 2y ago
    Are you seriously mentioning JS as a C++ alternative? I am confused.
    - nickpp 2y ago
jandrewrogers 2y ago
I think it depends on what you use C++ for. For low-level high-performance systems work, the thing I probably miss most in many of the alternatives is the extensive metaprogramming and generics capabilities of C++. This is unfortunate given both the power of this language feature and how much opportunity there is to improve the ergonomics of C++ metaprogramming.
neonsunset 2y ago
That's C# :)
hot_gril 2y ago
Rust, since you're mentioning speed. It was refreshing to use, partially because the standard library is so much nicer.

isopede 2y ago

C++ has long surpassed the point where mere mortals like me can understand it; It's so loaded with baggage, footguns, and inscrutable standards language that honestly I think the only thing keeping it going is institutional inertia and "backwards compatbility" (air quotes). I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the day rust or some other language finally supplants them.

dlivingston 2y ago
What's stopping Rust from being used in embedded?
- selfmodruntime 2y ago
  Documentation is severely lacking and vendor specific libraries and build systems are sometimes interfering with cargo. There‘s also the problem of rust-analyzer being relatively flaky in general and even more so when being used with environment specific / KConfig / build system feature flags that enable or disable certain library headers.
- isopede 2y ago
  Among other things, tooling and vendor libraries. Vendor libraries are often composed of thousands upon thousands of lines of auto-generated C headers and written in some bespoke format. Demonstration code and/or sample drivers are almost invariably provided in C. Of course you _can_ rewrite these in Rust, but if you're an engineer trying to get shit working, you'd first basically have to reinvent the whole wheel just to do bringup. I don't even want to talk about the state of proprietary vendor tooling...
selfmodruntime 2y ago
I‘m currently doing work with Rust on Esp32 platforms and I‘ll have to say, it‘s not quite ready yet. Debug tools still have issues, and we‘re facing some problems with vendor specific magic in Esp IDF version 5.

ilovecaching 2y ago

The grass is always greener. Rust also has rough edges and there's maybe a fraction of a fraction of a percent of Rust code out there to work on in the corpus of systems software, and a lot of it has to interface with C anyway. Even crates in Rust are overly complicated and they've set up a system that allows people to squat on well known names. I think if you want to work on systems software you should enjoy working with legacy cruft, otherwise you're just going to be miserable. I mean it's everywhere from the language, to the POSIX APIs, to device drivers, to hardware quirks... C++ is only a quarter of the problem.

shrimp_emoji 2y ago

And yet C++ is the best programming language. If you had to pick only one language to use, for everything, you'd pick C++. It can do it all, from bit fields to polymorphic classes to closures; it's safer and saner than C (you haven't read the standards if you think otherwise); it's got a level of support and maturity (and probably lifespan) than any other comparable language.