9 ms·

Maybe there's some truth to what you're saying. But at the same time, there aren't many alternatives that tick all the boxes C++ does (performance, portability,

• jeltz 6y ago
  Rust has all of those other than portability. Rust's ecosystem while it is missing some things it also has things which are lacking in C++ like a good mature package manager.
  • User23 6y ago
    > Rust has all of those other than portability. That's crippling. Arguably the best use case for C++ is coding video games, and portability is huge there.
    • stu2b50 6y ago
      The modern video game platforms are: PC, Xbox Series, PS5, Xbox One, PS4, Switch, Android, iOS, Web Of which Rust has backends for all them, even the web via wasm. While Rust is not as portable, it's not like it's strictly limited to well functioning x86 boxes, it'll produce binaries for anything that LLVM supports, which is quite a lot by now.
      • FartyMcFarter 6y ago
        > Of which Rust has backends for all them, even the web via wasm. Are those backends officially supported on consoles? Do all those consoles have libraries and tools (profilers, debuggers, etc) that support Rust?
        • stu2b50 6y ago
          Yep, like in C++ it's trivially easy to use the platforms C apis. And indeed the debugger does work on all platform.
        • bsagdiyev 6y ago
          Internally I know Sony had a Rust compiler for the PS4, I don’t know much more than that (like if it was used for anything). Just saw the repo was updated quite often so it was definitely still WIP at least, and it had some code samples for console apps. Never tried it on my dev console to see if it worked.
        • steveklabnik 6y ago
          They are not directly supported by the vendors. That said, tools that work on C and C++ will at least somewhat work on Rust, so you also get sorta kinda half support even if it's not officially supported. We'll see if this changes in the future, especially with some of the names doing Rust dev in these places.
    • Torkel 6y ago
      Modern C++ isn’t all that portable either.
      • FartyMcFarter 6y ago
        IMHO the last big upgrade to C++ was C++11, which is supported by lots of toolchains. It added move semantics, decent smart pointers, and a crapload of other improvements. C++14 and C++17 were minor upgrades by comparison, so I'd say C++11 can rightly be called modern C++, though others may disagree.
        • ncmncm 6y ago
          I see that you are wholly unaware of C++20, which (combined with '14 and '17) is as large a step from C++11 as C++11 was from C++98.
          • FartyMcFarter 6y ago
            C++20 is barely out yet, and not supported by any toolchain. If that's the only version that counts as modern C++, then I agree that modern C++ isn't portable :)
      • jcelerier 6y ago
        c'mon, you can run C++17 code on Commodore 64 (https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE) and MS-DOS (https://www.youtube.com/watch?v=yHrC_rZUaiA https://www.youtube.com/watch?v=yHrC_rZUaiA), what more do you want ?
    • rndgermandude 6y ago
      I'd argue that Rust is as portable as C++, if not more so, in the sense that there are no real barriers in the language itself that limit portability. It's harder to write un-portable code in Rust than in C++, because a lot less in idiomatic rust is undefined or food-gunable. Of course when it comes to practical portability today then you're right as there are plenty more C++ compilers for different platforms than Rust compilers (then again, there are more C compilers than C++ in that regard). This may eventually change over time, tho, but it sure is something to consider today. PS and edit: I don't mind you disagreeing with me, but would anybody care to illuminate me as to what your disagreement is about?
  • cycloptic 6y ago
    C++ has several package managers, of varying levels of maturity. Here's a few: https://github.com/conan-io/conan https://github.com/conan-io/conan https://github.com/microsoft/vcpkg https://github.com/microsoft/vcpkg https://github.com/cpp-pm/hunter https://github.com/cpp-pm/hunter Another option if you're on Linux/BSD is to use your native package manager. C++ packages are usually included in those repositories. You also may be able to install Brew, Nix, or Guix on any given distribution.
    • xigoi 6y ago
      >Another option if you're on Linux/BSD is to use your native package manager. There goes the portability.
      • cycloptic 6y ago
        No, portability is easily achieved with those by using containers.
  • andi999 6y ago
    I never learned rust, but from what I read loving the borrow checker also requires Stockholm syndrom.
    • cxvxx 6y ago
      It's more like snowboarding or any activity with a high initial learning curve before a big payoff: It's hard, even painful, at the beginning, and you might come home covered in bruises, but eventually it "clicks" and it's a lot of fun. Stockholm Syndrome is more about convincing yourself that a bad situation is good because you're stuck in it. I don't think there are too many people "stuck" with Rust yet. On the contrary, I think the borrow checker is a draw.
• Silhouette 6y ago
  But at the same time, there is no alternative that ticks all the boxes C++ does (performance, portability, maturity and stability). As you identified yourself, that's not entirely true, because C offers all of those things. But the really tragic thing about the status quo is that because there is so much sunk effort behind the C and C++ ecosystem, the resulting momentum makes it difficult for new languages that are simply better to gain traction. In a way, C++ is the ultimate demonstration of how important the surrounding tool, library and developer ecosystem is to the success (== usefulness in practice) of a programming language. If the language itself were the dominant factor, the writing would have been on the wall when almost every language at a higher level than C was adding features like first class functions and C++ was trying to do something vaguely similar with overcomplicated binder templates. A language with nicer syntax for working with higher-order functions, Haskell say, might have used xs = [1, 2, 3, 4, 5] n = count_if (<3) xs But for many years in C++, the closest theoretical equivalent would have been to write something like xs = // some standard container type, tediously constructed n = count_if(xs.begin(), xs.end(), bind2nd(less<int>(), 3)) instead. Obviously hardly any real programmers ever did that, and it's true that modern C++ is better in several relevant ways, but it's been literally decades and it still hasn't entirely caught up. Meanwhile, several much more promising languages are struggling to break into the kinds of markets they deserve to because they haven't achieved a critical mass of support. And the world continues to suffer the loss of productivity and problems with security and reliability that come from using a language like C++ for things that do actually matter. It's an understandable situation, but still a regrettable one.
  • FartyMcFarter 6y ago
    > As you identified yourself, that's not entirely true, because C offers all of those things. You're right, I contradicted myself there a bit. Fixed. But C is almost a subset of C++, except for some technicalities. So it's a bit hard to call it an actual alternative. Switching from C++ to C is more or less a matter of restricting oneself to less functionality (which in some cases is a good thing, but I digress). Other than C it's hard to point at a solid alternative for many C++ use cases. > In a way, C++ is the ultimate demonstration of how important the surrounding tool, library and developer ecosystem is to the success Indeed! This is something that any language wanting to compete with C++ must get right. It's a hard thing to do.
• arc619 6y ago
  Another option is to gradually replace parts of the C++ with Nim code set to output to C++. As such you get the advantages of a high level, low friction language with fast compile times and move semantics, ABI compatibility with C++, and a really nice FFI. You can import or export functions and so on between the languages, use any C++ libraries in Nim (or visa versa), and even directly emit C++ from Nim if required. Gradually porting like this lets you keep using your code base whilst introducing new or overly complex stuff in a language that's faster and easier to write (usually ends up with less than half the LoC of the equivalent C++ but often way, way less than that). Metaprogramming is also very nice, easier to reason about and perhaps most importantly, even with lots of macros doesn't noticeably affect the fast compiles. Another advantage is once you have some Nim code you can choose to change the target to C or ObjC (or even JS or LLVM) so you're actually increasing portability. This all depends on how you rank 'maturity' of course. Nim's been around for longer than Rust and Go IIRC, and it's been rock solid for me but you may have different parameters. It certainly helps being able to directly use libraries for C and C++ if you can't find an appropriate Nim implementation. Edit: For contrast, consider the challenges in the article for variants in C++, then the equivilent object variants in Nim: type MyVarKind = enum mvkNumber, mvkString MyVariant = object case kind: MyVarKind of mvkNumber: num: int of mvkString: str: string var myVariant = MyVariant(kind: mvkNumber) myVariant.num = 1 myVariant.str = "Oops" # Error: 'str' is not accessible using discriminant 'kind' of type 'MyVariant'
  • FpUser 6y ago
    How do you deal with debugging?
    • arc619 6y ago
      In VSCode and Neovim there's a visual debugger but in general you can compile with `--debugger:native` and use GDB, for example: A guide to debugging and profiling: https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html https://nim-lang.org/blog/2017/10/02/documenting-profiling-a... Guide for working directly with GDB-Nim: https://internet-of-tomohiro.netlify.app/nim/gdb.en.html https://internet-of-tomohiro.netlify.app/nim/gdb.en.html A walk through and extra info with the language devs: https://www.youtube.com/watch?v=DmYOPkI_LzU https://www.youtube.com/watch?v=DmYOPkI_LzU
• tester756 6y ago
  >performance, portability, maturity and stability sounds like C# and Java with only performance being questionable, but Java's used in HFT, so it definitely can compete.
  • qppo 6y ago
    GC is usually out the window if you're debating using C++
  • whimsicalism 6y ago
    > Java's used in HFT, so it definitely can compete. This is a bad argument and if you're using Java, you're not competing in the very speed-critical parts of HFT. Nor is Java common among HFT shops at all. well-written C++ is much faster than Java.
    • tester756 6y ago
      I know people who sit in HK and have been doing HFT/Quant stuff for years and they say something completely different - that Java's popular among biggest trading/stock systems. So saying that > Nor is Java common among HFT shops at all. Sounds weird, especially when it appears among job postings.
• jandrewrogers 6y ago
  A major feature of modern C++, and one of the most difficult to replace, is its expressiveness and optional strictness. You don't get this with C (or most other languages). The metaprogramming and compile-time facilities for example, while complex, are indispensable for some code bases. This becomes evident when you try to port rigorous modern C++ code bases to other programming languages du jour. A surprising amount of C++ is difficult to express with equivalent behavior and performance in a similar amount of code. I play around with new system languages by implementing parts of database engines (typically written in modern C++) in the new language. It terms of abstract code architecture, you can port a C-style database design with relative ease -- most new system languages aim to be an improved C with direct portability in mind -- but not modern C++-style database design, and the latter is unambiguously superior for performance and correctness when writing database engines. C++ will continue to see a lot of usage as long as it is difficult or impossible to write code in other languages that is functionally equivalent to C++.
  • bennofs 6y ago
    Can you summarise how modern C++ database design differs from C-style design?
    • jandrewrogers 6y ago
      C-style designs rely heavily on macros and aliasing, there is minimal type safety and most correctness properties can only be determined at runtime. Resource management is extremely manual which is both fiddly in the amount of code and error prone. Lots of function pointer passing instead of generics. Macros are used to hide just how tedious a lot of it is but they aren't safe. PostgreSQL is an exceptionally tidy example of a C-style database engine. In C++-style designs, you end up writing surprisingly little code, having metaprogramming scaffolding generate most of the code for you while doing fairly deep correctness and type safety checks at compile-time. Someone has to write the scaffolding libraries but they aren't that large, just tedious, and they get reused. Resource management, change detection, etc is automagic because C++ makes that easy to hide even in complex cases like DMA I/O. Every data structure and algorithm is highly optimized for the local use case and using the most highly compressed representation reasonable in context. It would be impractical to write all of this code and analyze it manually. I used to write databases in C99. It required several times the lines of code relative to C++17, with worse results, even if you include the scaffolding libraries. C++17 implementations, done well, is much closer to writing a specification for a subsystem design and behavior and having the compiler generate an optimized implementation for that specification and exporting types that hide the fiddly details that can be safely composed with other generated types, than writing code. The scaffolding is also generic and flexible: some can generate an OLTP database engine just as easily as an OLAP database engine largely by changing the subsystem specifications and composing things differently. This would not be possible without heavy use of the metaprogramming facilities to both generate the types and guarantee that type interactions will still be safe and reasonably optimal.
• socialdemocrat 6y ago
  My point was that you should just use old-school C++ if you need to use C++. If your desire is to use fancy language features, and that is your primary focus, then you should switch language. People should just accept that they work with a legacy language and not try to turn C++ into Haskell, Rust or something it isn't. They just turn it into a worse mess than it already is. Most C++ code that exists and which is useful is written in old school C++ anyway and could be continued to be maintained that way and wrapped for other users. And really C++ performance is IMHO somewhat overrated. It depends entirely on what you are doing. I think it was the CouchDB creator. He made his first version in C++. He struggled hard. Then he switched to Erlang, despite Erlang running on a VM he got magnitudes higher performance and had to write less than half the code. You know the ones who squeezed the most performance out of the Playstation 2 did it using LISP and not C++. They used LISP to create a DSL for PS2 assembly code. Thus they could do high level LISP coding as well as low level assembly all in one. And today you got many scientists needing high performance computing switching to Julia. Fortran will usually outperform C++ on number crunching. And there are quite a number of cases where Julia will outperform Fortran. Yes in real time systems with tight memory requirements something like Julia is not a good choice. But then again in those cause you may actually want to prefer C or Rust.