4 ms·

I like C++ because I only pay for what I use in the language. Very little overhead or additional baggage to slow or weigh things down, unless, I elect to includ

I like C++ because I only pay for what I use in the language. Very little overhead or additional baggage to slow or weigh things down, unless, I elect to include the extra luggage. The recent updates - C++11, C++14 and the drafts for C++17 are also very welcome. When you need performant, deterministic, portable and testable code, you go for C++.

heinrich5991 12y ago
The new Rust language by Mozilla makes similar promises, * only pay for what you use * memory safety * testability * portability (They even got a standard testing module.) EDIT: How do you make lists with Hacker News markup?
- SamReidHughes 12y ago
  > How do you make lists with Hacker News markup? You just made one.
  - loup-vaillant 12y ago
    Kinda. It would be nice to have a richer markup support. We always cite one another, provide links, and enumerate things. Supporting a subset of Markdown (or anything like it) would be very welcome.
- freyrs3 12y ago
  Conceptually they are similar, though it's always important to note that C++ has several man-centuries worth of compiler work. Rust may become stable and efficient enough to replace some existing C++, but at the moment it's most certainly not as mature as the existing C++ ecosystem.
  - pornel 12y ago
    Rust uses LLVM, so it benefits from the same optimizer as clang. The front-end is less mature of course, but also Rust is less complex, so may not need man-centuries of work to be parsed properly ;) Currently Rust doesn't outperform C++ partly because LLVM is optimized for the C subset (can't take advantage of extra aliasing/immutability information Rust has), but given that Apple is now betting on (quite similar) Swift I expect LLVM to rapidly improve in this area.
    - gsnedders 12y ago
      Also remember most of the work on Rust at the moment is focused on stabilizing the language — performance is only really required to be acceptable for now, provided it is possible to improve.
      - steveklabnik 12y ago
        Yes, there are several places where, for example, we generate sub-optimal LLVM IR, but time is better spent getting the interfaces and language spec correct for 1.0 than squeezing out performance. I should mention that that's different than 'who cares about performance, let's toss this in.' Performance aspects are absolutely taken into account when changing the language. But that's different than the implementation itself.

heinrich5991 12y ago

The new Rust language by Mozilla makes similar promises, * only pay for what you use * memory safety * testability * portability (They even got a standard testing module.) EDIT: How do you make lists with Hacker News markup?

SamReidHughes 12y ago
> How do you make lists with Hacker News markup? You just made one.
- loup-vaillant 12y ago
  Kinda. It would be nice to have a richer markup support. We always cite one another, provide links, and enumerate things. Supporting a subset of Markdown (or anything like it) would be very welcome.
freyrs3 12y ago
Conceptually they are similar, though it's always important to note that C++ has several man-centuries worth of compiler work. Rust may become stable and efficient enough to replace some existing C++, but at the moment it's most certainly not as mature as the existing C++ ecosystem.
- pornel 12y ago
  Rust uses LLVM, so it benefits from the same optimizer as clang. The front-end is less mature of course, but also Rust is less complex, so may not need man-centuries of work to be parsed properly ;) Currently Rust doesn't outperform C++ partly because LLVM is optimized for the C subset (can't take advantage of extra aliasing/immutability information Rust has), but given that Apple is now betting on (quite similar) Swift I expect LLVM to rapidly improve in this area.
  - gsnedders 12y ago
    Also remember most of the work on Rust at the moment is focused on stabilizing the language — performance is only really required to be acceptable for now, provided it is possible to improve.
    - steveklabnik 12y ago
      Yes, there are several places where, for example, we generate sub-optimal LLVM IR, but time is better spent getting the interfaces and language spec correct for 1.0 than squeezing out performance. I should mention that that's different than 'who cares about performance, let's toss this in.' Performance aspects are absolutely taken into account when changing the language. But that's different than the implementation itself.