5 ms·

C or C++ are still (depending on background) the systems languages of first-resort for things like writing a database or an operating system. The exception to t

C or C++ are still (depending on background) the systems languages of first-resort for things like writing a database or an operating system. The exception to the former is usually Java depending on ecosystem and the programmers involved. (Cassandra, et al) No-compromise performance still happens with C and C++. Secondarily Fortran and Ada for their respective industries. I doubt that'll change anytime soon as I'm not seeing any languages that are choosing the same priorities. Go isn't a systems language by any measure or estimation in design or implementation, and Rust is a type-safety-centric compromise that will likely end up somewhere around Java in performance. I'm not seeing much indication from the mailing list that safety-off all-go performance is a priority for the Rust devs because they seemed to favor avoiding the quagmire of a large C++ codebase. I think realistically a "clean start" of C++ with the best of C++11 and earlier standards but removing a lot of the less worthwhile features would go a long way. Won't happen though. A lot of people avoid those problems by just writing C. Missing out on the cool reference counted pointers and compile-time stuff though. Any language that wants to fully replace C/C++ has to embrace "pay only for what you use". Mandatory anything at runtime at the language design level is untenable.

mrich 14y ago
D basically is this restart of C++ you are referring too. Unfortunately it sees basically no adoption in the industry as far as I can tell.
- codewright 14y ago
  It was poorly timed and the default GC terrified (C/C++) people. It would've been more constructive for D to focus less on using GC and more on compromises and intermediate stages between fully static memory management and raw malloc/free. Compromises like reference-counting pointers with various semantics available in Boost. C++ didn't kill D, Java did. D was never going to replace C++. Rust is doing a better job of making things like that available (unique pointer, borrowed pointer, etc). That said, D didn't embrace "pay for only what you use" at a serious level because shutting off the GC basically left you in the wilderness and there weren't many accommodations made for making non-GC operation as good as possible. Rust doesn't seem to embracing that either for the sake of prioritizing safety.
  - pcwalton 14y ago
    Rust is embracing optional GC. Almost any use of the GC in the standard library is considered a bug at this point. Also, the GC in Rust is not for safety (as the language is memory-safe regardless of whether you use the GC); rather it's for convenience when you want it. We can't ship a competitive touch-responsive browser engine if the compositor has GC pauses, so making the GC optional is as critical for us as it is for everybody else.
    - codewright 14y ago
      I know the GC is designed to make a lot of task-centric things work nicely. I mean, it's good that the GC is optional and I think Rust is well-designed but you get what I'm saying about "pay for only what you use". GC being optional alone doesn't constitute embracing that mindset. It's a far-reaching sentiment that explains a lot of the stranger design decisions in C++. I'm sure Rust could end up being great for Servo, but there's more to how C and C++ get used than that. It takes a lot of unintuitive design compromises to make a language that's just as suitable in a 4kb RAM embedded device as it is in an HPC cluster. Only a committee of people from very diverse backgrounds is generally going to be able to account for that sort of thing. For better or worse, C and C++'s design-by-committee did result in languages that were capable of coping with a vast variety of extremes, even if it meant giving up a lot of 'niceness' and never really taking safety seriously beyond tooling/testing. "Pay only for what you use" means safety optional, GC optional, dynamic allocation optional, everything. I know you're a very well read and highly experienced programmer and I have a lot of confidence in the Rust-dev team, but you are not replacing C++. You're replacing C++ for Mozilla.
      - pcwalton 14y ago
        I'm curious what in particular in Rust's design that you feel closes off optimization opportunities. "Safety optional, GC optional, dynamic allocation optional" are all true for Rust, for example. I don't feel that we're replacing C++ for everybody, of course. C++ is a very nice language for what it does, and there's a huge amount of infrastructure and an ecosystem built around it. I don't think that we're at an optimization/performance disadvantage relative to C++ in terms of the language design, however. (Compiler toolchain immaturity is another issue, though; currently we aren't really using LLVM to its full potential in various ways.)
frou_dh 14y ago
> I think realistically a "clean start" of C++ with the best of C++11 and earlier standards but removing a lot of the less worthwhile features would go a long way. Won't happen though. I'm sure the big players are in standard C++ for the long haul. Though, the thing you mention, wouldn't that make a good (though ambitious) community project? Make a hot-rod non-standard C++ implementation using Clang as a starting point.
- codewright 14y ago
  C++ programmers 'hate giving things up' and there's an imperfect and sparse subset of the language that any given sampling of C++ programmers use. Getting consensus on what to take out would be difficult, considering a lot of the features aren't there to incrementally improve the lives of 'everyone', but rather to cope with an edge-case that could be a fatal problem for something specific. That's how a lot of committee work goes. I wouldn't mind seeing such a thing. I find C++ intimidating, but I don't think the answer is to completely forgo utilizing it. Realistically my solution is to only use features I understand in relation to how something similar would look in C.
  - frou_dh 14y ago
    Those who had the gumption to get the project off the ground would get the decision-making hats (a better solution to "can't please everyone" than analysis paralysis!). All hypothetical of course.
  - Shorel 14y ago
    > Realistically my solution is to only use features I understand in relation to how something similar would look in C. Absolutely true. I don't understand people trying to use every single language feature in every single program. And I'm thinking in general terms, not just C++.
- cmccabe 14y ago
  Luckily a subset of C++ with just the "good" features has already been made and is widely deployed. It's called C.
pcwalton 14y ago
"I'm not seeing much indication from the mailing list that safety-off all-go performance is a priority for the Rust devs" It is. We are counting every cycle in the JS<->Rust bridge, for example, when compared against C++ Gecko and WebKit. As a general policy, Mozilla does not take performance regressions. Servo is a total non-starter if it is a performance regression over the existing C++ browser engines. That said, Rust does some things by default that C++ doesn't do by default, such as stack overflow checks and array bounds checks. This is because we believe that, for most apps, they're the right defaults when weighed against the dire security consequences. It's planned for both of these to be able to be switched off in the future. (It's already possible to switch off array bounds checks, and switching off stack growth will be needed for competitive JS<->Rust interoperability in Servo.)
- codewright 14y ago
  Lets not commit the same sin as the PyPy people, is it really faster than the C++ rendering engine? If not, how far off the mark is it? I really want real numbers, not idle conjecture. Gosling was fond of speculating that Java would eventually be faster than C and C++ because of $COOL_FEATURE_X, but nothing ever materialized or made enough of a difference. Concurrent GC didn't make up the difference. JIT didn't make up the difference. Why would I believe anybody else bringing the same message? This cyclical "we're gunna be faster and here is the cool compiler research saying so!" is why the programming language community has thoroughly alienated my colleagues that work in systems. They can't afford to build their systems on speculation, it HAS to work. They believe nothing anybody says about programming languages now. What's the most impactful territory to conquer that could help make up the difference? Rust's design allows for a subset of valid programs that could be constructed in C++. It's the same kind of thinking that Haskell utilizes. The type system is useful in Haskell because it disallows potentially invalid programs giving you a smaller space to reason about. (cf. Total programming) However, that subsetting means avenues and opportunities for optimization are eliminated. Optimization sometimes means doing something batshit. A high-level 6502 emulator a friend wrote in x86 asm comes to mind.
  - pcwalton 14y ago
gjm11 14y ago
> Any language that wants to fully replace C/C++ has to embrace "pay only for what you use". "Pay only for what you use" sounds like a really great principle. But ... Every user of C++ pays the cost (in convenience and reduced bugs) of not having automatic memory management, even if they don't need its benefits in memory consumption and avoiding GC pauses. Many users of C++ pay a performance cost for the language's lack of automatic memory management, because getting the best performance from an automatic memory management system requires tight language integration and you can't have that with C++. (So they fall back on refcounting or Boehm-Weiser-like conservative GC, and pay the cost.) Every user of C++ pays the cost (in ugly syntax and long compile times because of the included-header model) of backward compatibility with C, even if they don't really need that. Many users of C++ pay a performance cost for this, because the C++ compilation model means that template-heavy code tends to end up with a lot of more or less duplicate object code, which means more cache misses and more time spent paging code in from disc. Every user of C++ pays the cost (in overflow bugs and the like) of using integral types tied closely to the underlying processor architecture, even if they don't need the performance advantages it brings. Some C++ users pay a performance cost for this, because if an application actually needs bignums then it'll typically be implemented using some general-purpose bignum system like GMP, which will typically perform very well for really large numbers but may be totally unsuited for smaller ones -- and sometimes most of the numbers you're computing with are in fact the small ones. C++ uses "pay only for what you use" as a slogan, but it applies that slogan only in a very narrow domain. C++ users are paying, all the time, for lots of things they don't use. Quite a lot of C++ users are paying in performance for things they don't use. The slogan is misleading because it directs your attention to the obvious, explicit costs of features like automatic memory management and integer types that overflow gracefully, but there are plenty of costs that aren't so obvious. (Lest I be misunderstood: For many applications C++ is a great choice. For some it's the only realistic choice. I am not, for instance, arguing that actually everyone should be programming in Common Lisp or something. I just think "you don't pay for what you don't use" is a really misleading slogan.)
- antiterra 14y ago
  How sure are you that the performance cost from template-heavy code outweighs the performance cost of the virtual function calls you'd undoubtedly be doing instead?
Shorel 14y ago
> but removing a lot of the less worthwhile features And what are those features, according to you?

mrich 14y ago

D basically is this restart of C++ you are referring too. Unfortunately it sees basically no adoption in the industry as far as I can tell.

codewright 14y ago
It was poorly timed and the default GC terrified (C/C++) people. It would've been more constructive for D to focus less on using GC and more on compromises and intermediate stages between fully static memory management and raw malloc/free. Compromises like reference-counting pointers with various semantics available in Boost. C++ didn't kill D, Java did. D was never going to replace C++. Rust is doing a better job of making things like that available (unique pointer, borrowed pointer, etc). That said, D didn't embrace "pay for only what you use" at a serious level because shutting off the GC basically left you in the wilderness and there weren't many accommodations made for making non-GC operation as good as possible. Rust doesn't seem to embracing that either for the sake of prioritizing safety.
- pcwalton 14y ago
  Rust is embracing optional GC. Almost any use of the GC in the standard library is considered a bug at this point. Also, the GC in Rust is not for safety (as the language is memory-safe regardless of whether you use the GC); rather it's for convenience when you want it. We can't ship a competitive touch-responsive browser engine if the compositor has GC pauses, so making the GC optional is as critical for us as it is for everybody else.
  - codewright 14y ago
    I know the GC is designed to make a lot of task-centric things work nicely. I mean, it's good that the GC is optional and I think Rust is well-designed but you get what I'm saying about "pay for only what you use". GC being optional alone doesn't constitute embracing that mindset. It's a far-reaching sentiment that explains a lot of the stranger design decisions in C++. I'm sure Rust could end up being great for Servo, but there's more to how C and C++ get used than that. It takes a lot of unintuitive design compromises to make a language that's just as suitable in a 4kb RAM embedded device as it is in an HPC cluster. Only a committee of people from very diverse backgrounds is generally going to be able to account for that sort of thing. For better or worse, C and C++'s design-by-committee did result in languages that were capable of coping with a vast variety of extremes, even if it meant giving up a lot of 'niceness' and never really taking safety seriously beyond tooling/testing. "Pay only for what you use" means safety optional, GC optional, dynamic allocation optional, everything. I know you're a very well read and highly experienced programmer and I have a lot of confidence in the Rust-dev team, but you are not replacing C++. You're replacing C++ for Mozilla.
    - pcwalton 14y ago
      I'm curious what in particular in Rust's design that you feel closes off optimization opportunities. "Safety optional, GC optional, dynamic allocation optional" are all true for Rust, for example. I don't feel that we're replacing C++ for everybody, of course. C++ is a very nice language for what it does, and there's a huge amount of infrastructure and an ecosystem built around it. I don't think that we're at an optimization/performance disadvantage relative to C++ in terms of the language design, however. (Compiler toolchain immaturity is another issue, though; currently we aren't really using LLVM to its full potential in various ways.)

frou_dh 14y ago

> I think realistically a "clean start" of C++ with the best of C++11 and earlier standards but removing a lot of the less worthwhile features would go a long way. Won't happen though. I'm sure the big players are in standard C++ for the long haul. Though, the thing you mention, wouldn't that make a good (though ambitious) community project? Make a hot-rod non-standard C++ implementation using Clang as a starting point.

codewright 14y ago
C++ programmers 'hate giving things up' and there's an imperfect and sparse subset of the language that any given sampling of C++ programmers use. Getting consensus on what to take out would be difficult, considering a lot of the features aren't there to incrementally improve the lives of 'everyone', but rather to cope with an edge-case that could be a fatal problem for something specific. That's how a lot of committee work goes. I wouldn't mind seeing such a thing. I find C++ intimidating, but I don't think the answer is to completely forgo utilizing it. Realistically my solution is to only use features I understand in relation to how something similar would look in C.
- frou_dh 14y ago
  Those who had the gumption to get the project off the ground would get the decision-making hats (a better solution to "can't please everyone" than analysis paralysis!). All hypothetical of course.
- Shorel 14y ago
  > Realistically my solution is to only use features I understand in relation to how something similar would look in C. Absolutely true. I don't understand people trying to use every single language feature in every single program. And I'm thinking in general terms, not just C++.
cmccabe 14y ago
Luckily a subset of C++ with just the "good" features has already been made and is widely deployed. It's called C.

pcwalton 14y ago

"I'm not seeing much indication from the mailing list that safety-off all-go performance is a priority for the Rust devs" It is. We are counting every cycle in the JS<->Rust bridge, for example, when compared against C++ Gecko and WebKit. As a general policy, Mozilla does not take performance regressions. Servo is a total non-starter if it is a performance regression over the existing C++ browser engines. That said, Rust does some things by default that C++ doesn't do by default, such as stack overflow checks and array bounds checks. This is because we believe that, for most apps, they're the right defaults when weighed against the dire security consequences. It's planned for both of these to be able to be switched off in the future. (It's already possible to switch off array bounds checks, and switching off stack growth will be needed for competitive JS<->Rust interoperability in Servo.)

codewright 14y ago
Lets not commit the same sin as the PyPy people, is it really faster than the C++ rendering engine? If not, how far off the mark is it? I really want real numbers, not idle conjecture. Gosling was fond of speculating that Java would eventually be faster than C and C++ because of $COOL_FEATURE_X, but nothing ever materialized or made enough of a difference. Concurrent GC didn't make up the difference. JIT didn't make up the difference. Why would I believe anybody else bringing the same message? This cyclical "we're gunna be faster and here is the cool compiler research saying so!" is why the programming language community has thoroughly alienated my colleagues that work in systems. They can't afford to build their systems on speculation, it HAS to work. They believe nothing anybody says about programming languages now. What's the most impactful territory to conquer that could help make up the difference? Rust's design allows for a subset of valid programs that could be constructed in C++. It's the same kind of thinking that Haskell utilizes. The type system is useful in Haskell because it disallows potentially invalid programs giving you a smaller space to reason about. (cf. Total programming) However, that subsetting means avenues and opportunities for optimization are eliminated. Optimization sometimes means doing something batshit. A high-level 6502 emulator a friend wrote in x86 asm comes to mind.
- pcwalton 14y ago

gjm11 14y ago

> Any language that wants to fully replace C/C++ has to embrace "pay only for what you use". "Pay only for what you use" sounds like a really great principle. But ... Every user of C++ pays the cost (in convenience and reduced bugs) of not having automatic memory management, even if they don't need its benefits in memory consumption and avoiding GC pauses. Many users of C++ pay a performance cost for the language's lack of automatic memory management, because getting the best performance from an automatic memory management system requires tight language integration and you can't have that with C++. (So they fall back on refcounting or Boehm-Weiser-like conservative GC, and pay the cost.) Every user of C++ pays the cost (in ugly syntax and long compile times because of the included-header model) of backward compatibility with C, even if they don't really need that. Many users of C++ pay a performance cost for this, because the C++ compilation model means that template-heavy code tends to end up with a lot of more or less duplicate object code, which means more cache misses and more time spent paging code in from disc. Every user of C++ pays the cost (in overflow bugs and the like) of using integral types tied closely to the underlying processor architecture, even if they don't need the performance advantages it brings. Some C++ users pay a performance cost for this, because if an application actually needs bignums then it'll typically be implemented using some general-purpose bignum system like GMP, which will typically perform very well for really large numbers but may be totally unsuited for smaller ones -- and sometimes most of the numbers you're computing with are in fact the small ones. C++ uses "pay only for what you use" as a slogan, but it applies that slogan only in a very narrow domain. C++ users are paying, all the time, for lots of things they don't use. Quite a lot of C++ users are paying in performance for things they don't use. The slogan is misleading because it directs your attention to the obvious, explicit costs of features like automatic memory management and integer types that overflow gracefully, but there are plenty of costs that aren't so obvious. (Lest I be misunderstood: For many applications C++ is a great choice. For some it's the only realistic choice. I am not, for instance, arguing that actually everyone should be programming in Common Lisp or something. I just think "you don't pay for what you don't use" is a really misleading slogan.)

antiterra 14y ago
How sure are you that the performance cost from template-heavy code outweighs the performance cost of the virtual function calls you'd undoubtedly be doing instead?

Shorel 14y ago

> but removing a lot of the less worthwhile features And what are those features, according to you?