A language as powerful and expressive as C++ has a big advantage. Java is not, Go is not, Ruby is not. Haskell is powerful but slow, and needs an intrusive runtime environment. If (as it appears) Rust is as expressive as C++, equally fast, and link-compatible with C, it has a unique opportunity because it's much, much simpler than C++. That makes it easier to learn, and cheaper to implement and maintain, both the compiler and your own code. Given C link-compatibility, Rust modules can be added to your existing programs, and new Rust programs can call your existing libraries, offering a smooth transition path.
No language is forever. Rust might not be the true Glorious Successor to C++. If not, whatever is will look a lot like Rust.
Posted Apr 4, 2013 20:29 UTC (Thu) by khim (subscriber, #9252)
[Link]
If (as it appears) Rust is as expressive as C++, equally fast, and link-compatible with C, it has a unique opportunity because it's much, much simpler than C++.
Nope. There are fundamental difference between these.
To go from C to Java you need to jump over 100 feet high wall and to go from C to Haskell you need to jump over 1000 feet high wall. With Rust this wall may be 50 feet high or may be even 10 feet high, but it's still a wall and it'll keep users from defecting from C camp.
C++? For C++ it's kinda 500 feet-high staircase: sure, the end position it pretty far removed from where you've started but you can go there at the pace you want. You can use as many or as few C++ features as you want - which means that any C programmer can become C++ programmer by learning about couple of things s/he wants/needs. Sure, s/he may not be very efficient C++ programmer, but s/he'll be a C++ programmer even the only thing s/he uses are mutex classes or something like this. Eventually C++ can replace C more-or-less everywhere (the last holdouts like binutils and gcc are slowly switching to C++ camp). Well, may be not kernel (because it uses C++-incompatible dialect of C), but even that may happen in 10 years or so. If you introduce incompatible syntax, incompatible paradigms (and insist that said paradigms must be used from the start) then substantial percentage of developers will just be kept behind the wall such changes reproduce.
Rust may succeed as a language or it may fail but it can not be next C++. It's not in the cards.
No language is forever. Rust might not be the true Glorious Successor to C++. If not, whatever is will look a lot like Rust.
I seriously doubt it. Go, Rust and other "modern" languages is not designed to be C replacement and this means that at best they'll coexist with C/C++ (at worst they'll go to the dustbin of history).
Think another, parallel world of Pascal: it was quite popular till a few years ago but it's nominal successor never actually caught up (as successor!) because it was incompatible. Rust is in similar position and it's not even named as "C successor" by people who designed C...
Or another data point: Fortran. The last version which was actually incompatible with it's predecessor to significant degree was FORTRAN 77 - and it was almost enough to ruin the transition. Planned transition governed by most compiler vendors! And now you think that another NCP style transitions will happen? Dream on.
Rust
Posted Apr 5, 2013 7:00 UTC (Fri) by ncm (subscriber, #165)
[Link]
Fortran is an excellent example. Subsequent Fortran releases are more or less backward-compatible, and recent ones even support pointers and recursion, but how many places are they used? When starting a project where Fortran would have been required, people use C++ now because it's faster and more expressive. C++ has turned out to be the Glorious Successor to Fortran, despite being just barely link compatible, in the same way that FORTRAN succeeded assembly language.
The GStC++ will not be anything that is obliged to carry forward C++'s avoidable complexities (largely, forced C compatibility, name lookup horrors). People using C++ now will continue using it, but in maybe ten years new organizations and projects that need C++'s power will begin to pick up Rust (or something) instead. Second-tier languages will come and go, and be used for the easy problems, as always.
My point is that Rust is the first language above the horizon that seems physically capable of supplanting C++ on problems where, before, nothing else could even be seriously considered. If it sputters out, the world will continue with C++ as before until the next contender matures.
Rust
Posted Apr 5, 2013 7:32 UTC (Fri) by khim (subscriber, #9252)
[Link]
Subsequent Fortran releases are more or less backward-compatible, and recent ones even support pointers and recursion, but how many places are they used?
In more places then you expect. I know few people who thought like you do till they actually participated in bioresearch, weather prediction research and so on. They found out to their sudden surprise that new projects are still written in Fortran. Usually it's a mix: IT guys write the supplemental logic in C/C++ and non-IT scientists write their algorithms in Fortran. In that sense Fortran is still alive. Number one request for Exacycle is Fortran support (perhaps they already implemented Fortran support at this stage? I don't know).
People using C++ now will continue using it, but in maybe ten years new organizations and projects that need C++'s power will begin to pick up Rust (or something) instead. Second-tier languages will come and go, and be used for the easy problems, as always.
And Rust in one of these second-tier languages. The same happens with other industries, too. Think track gauges or QWERTY keyboard: once upon time it was easy to change track gauges or layout of keyboard but by now it's basically impossible. You can change some auxiliary pieces (railroad ties are made today from stone, wood, plastic or even fiberglass) and specialized cases use specialized gauges or keyboards, but mainstream is stuck.
My point is that Rust is the first language above the horizon that seems physically capable of supplanting C++ on problems where, before, nothing else could even be seriously considered.
Nope. Rust is yet-another-pretender with overblown hype.
If it sputters out, the world will continue with C++ as before until the next contender matures.
Well, the next contender will probably be called C++17, so it's not like we'll need to wait too long.
Rust
Posted Apr 5, 2013 8:38 UTC (Fri) by ncm (subscriber, #165)
[Link]
Yes, Fortran is still used heavily in certain domains, but no longer because it is, as it once was, the only reasonable choice. Nowadays its continued use is more a matter of inertia than of technical merit.
You seem to be asserting that C++ will always be the only reasonable choice for those difficult problems where there is, at this moment, no other. People used to say that about Fortran. They were wrong too.
That's not to say that Rust (or its descendant, TiN?) really will be the new heavy. What is certain is that there will someday be a new heavy that is not C++XX. Furthermore, it will differ from C++ in many of the ways that Rust does.
Rust
Posted Apr 5, 2013 15:00 UTC (Fri) by tjc (subscriber, #137)
[Link]
I work in bioresearch, and we use Java for almost everything. That's not the decision I would have made, but that's the trend. Nearly all the organizations we work with use Java, so it's hard to resist.
We used to use C and Perl, which was a common combination in bioinformatics, but that's been fading away -- especially C, I am sorry to say.
Rust
Posted Apr 6, 2013 13:34 UTC (Sat) by mathstuf (subscriber, #69389)
[Link]
> Haskell is powerful but slow
Huh? Maybe in specific cases where laziness can bite you or you write your calls poorly, but Haskell *can* beat C. In this[1] paper (reddit[2] discussion), on how to get GHC to use SSE for fused inner loops, Haskell is beat by Eigen's optimized calls and Boost's uBLAS library (but Boost only when you work with > L3-sized data). The C code would need careful tuning to take care of the same optimizations. And GHC hasn't really even been "optimized" for the call in particular; it's just an instance of the optimizer at work on a single, fairly naïve writing of the code.
Posted Apr 7, 2013 5:03 UTC (Sun) by ncm (subscriber, #165)
[Link]
C is slow, too, slower than Fortran, so it's not a good standard for comparison.
Rust
Posted Apr 7, 2013 5:25 UTC (Sun) by mathstuf (subscriber, #69389)
[Link]
> Once the working set no longer fits in L3 cache, the Haskell implementation is even neck-and-neck with the implementation of ddotp from GotoBLAS, a collection of highly-tuned BLAS routines hand-written in assembly language that is generally consid- ered to be one of the fastest BLAS implementation available.
The authors didn't only compare with C.
Rust
Posted Apr 7, 2013 11:27 UTC (Sun) by HelloWorld (guest, #56129)
[Link]
> C is slow, too, slower than Fortran
Programming languages aren't fast or slow, programs are.
In some cases, the C program is faster, in others the Fortran one is faster. "faster than" is simply not a total order on the set of programming languages, so stop making it sound as if it were. It's meaningless and undifferentiated.
Rust
Posted Apr 7, 2013 12:19 UTC (Sun) by hummassa (subscriber, #307)
[Link]
You are being a purist.
When people say things "C is slower than C++" or "C is slower than Fortran" or "C is slower than Haskell" they actually mean "C offers less opportunities for the compiler and the standard library implementations to optimize many types of constructions in code, mainly because of loose typing rules and loose aliasing rules. When you set out to execute a task computationally complex enough, you have a great probability that a well-written program in C will be slower than a well-written program in FORTRAN, or Haskell, or C++".
Rust
Posted Apr 7, 2013 14:13 UTC (Sun) by HelloWorld (guest, #56129)
[Link]
What specific optimisation opportunities are you talking about? The ones everybody knows about are related to pointer aliasing, but the restrict keyword has been around for ages now.
Rust
Posted Apr 7, 2013 17:59 UTC (Sun) by mathstuf (subscriber, #69389)
[Link]
So, in Haskell, because pure functions are guaranteed to not modify data, the compiler is allowed to "fuse" operations[1] instead of doing exactly what a naïve reading of the code implies (strict order of expressions to be evaluated). This allows the simple map function to act like C++'s std::transform and optimize the specific calls being made (usually via inlining then optimization), but GHC can optimize the calls on a single data structure being operated on across function boundaries and fuse the map calls together ((map (f . g)) list rather than (map f . map g) list where map f and map g are in different functions). I don't think C++'s std::transform gets optimized like this (and even if it did, f and g can't necessarily be called gfgfgf rather than gggfff).
[1]This is how Eigen gets a lot of performance: by storing expressions instead of evaluating additions immediately, Eigen can merge loops together to get one loop with 3 operations in it rather than 3 loops with one operation each which wins on cache access and in hot loops, matters a lot.
Rust
Posted Apr 7, 2013 18:08 UTC (Sun) by hummassa (subscriber, #307)
[Link]
The restrict keyword, by itself, does not add some opportunities for loop unrollings where aliased things are used inside the loops.
The lack of defining pure functions, without side-effects, also elide some opportunities for repeated code removal.
Rust
Posted Apr 7, 2013 18:11 UTC (Sun) by mathstuf (subscriber, #69389)
[Link]
GCC does have a pure attribute, but it's not verified that you're using it properly and no one uses it anyways…
Rust
Posted Apr 8, 2013 8:03 UTC (Mon) by nix (subscriber, #2304)
[Link]
It does get used for functions often used in very tight inner loops. Just looking at glibc, strcmp() is declared pure, for example, as are many related functions.
Rust
Posted Apr 7, 2013 21:50 UTC (Sun) by HelloWorld (guest, #56129)
[Link]
The restrict keyword, by itself, does not add some opportunities for loop unrollings where aliased things are used inside the loops.
I don't understand that, can you give an example?
The lack of defining pure functions, without side-effects, also elide some opportunities for repeated code removal.
Modern optimising compilers try to figure out whether a function is pure and optimise accordingly. Example:
#include <stdio.h>
int sq(int i) {
return i*i;
}
int main(int argc, char **argv) {
int i = strtol(argv[1], 0, 0);
printf("%d\n", sq(i) * sq(i));
return 0;
}
Compiled with gcc -O3 -fno-inline-small-functions -S -masm=intel (gcc 4.7.2) this yields
So gcc sees that sq is a pure function and only calls it once, even though it's called twice in the source code. Granted, this isn't quite the same as in Fortran as the compiler needs to be able to see the definition of the relevant function for this to work. But due to link-time optimisation this isn't as big a limitation as it used to be. I'm not convinced the Fortran way offers significant benefits in the real world.
Rust
Posted Apr 7, 2013 14:04 UTC (Sun) by anselm (subscriber, #2796)
[Link]
A Fortran compiler is allowed by the language definition to make all sorts of assumptions that are unavailable to a C compiler. This gives a Fortran compiler room for various optimisations that a C compiler can't do to the same degree. This means that for the typical sort of program one would write in Fortran, a Fortran compiler is at a distinct advantage compared to a C compiler as far as optimisation is concerned. On the other hand, C allows you to write programs with reasonable ease that can't be conveniently expressed at all in Fortran (one notable example being the Linux kernel).
In addition, direct translation of Fortran source code to C (and vice versa) usually leads to significantly worse performance in the new language if arrays are involved, simply because Fortran assumes that arrays are stored in row-major order while C assumes a column-major arrangement. In a speed comparison of programs written in both languages, factors like these ought to be controlled for.
Rust
Posted Apr 7, 2013 15:10 UTC (Sun) by HelloWorld (guest, #56129)
[Link]
> A Fortran compiler is allowed by the language definition to make all sorts of assumptions that are unavailable to a C compiler.
What assumptions? The one that people keep bringing up (pointer aliasing issues) was fixed a long time ago with the restrict keyword.
> In addition, direct translation of Fortran source code to C (and vice versa) usually leads to significantly worse performance in the new language if arrays are involved, simply because Fortran assumes that arrays are stored in row-major order while C assumes a column-major arrangement.
How is that supposed to matter? Whether row-major or column-major arrangement is faster depends entirely on the access patterns in the relevant program, and besides that, you're free to use a column-major layout in C as well, you just have to calculate indices by hand.
