| |||||||||||||
RustRustPosted Apr 4, 2013 17:39 UTC (Thu) by khim (subscriber, #9252)In reply to: Rust by ncm Parent article: Mozilla and Samsung building a new browser engine
Why people think D, Go, Rust or some other "modern" language can replace C++? They all lack the ability to convert your program in new language piece-by-piece which means they'll have as much success trying to replace C++ and Plan9 had trying to replace UNIX. I can imagine new language which will start from C and will go from there (think Objective-C), but even this is not all that likely. New, incompatible one? No chances, sorry. Sure, we'll see some projects written in these languages, but what exactly will distinguish these from projects written in Java or, ugh, PHP?
(Log in to post comments)
Rust Posted Apr 4, 2013 18:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Java has succeeded and so has C#. And while C# has a decent FFI (Foreign Function Interface), Java only has JNI.
So C compatibility is not essential. But having a good FFI certainly helps.
Rust Posted Apr 4, 2013 20:00 UTC (Thu) by khim (subscriber, #9252) [Link] Java has succeeded and so has C# Rilly? Reality check: Java Applets - failure, Java ME - failure, Android - failure (it's huge success only came after NDK release), Silverlight - failure, Windows Phone - failure (Windows Phone 7.x, that is, Windows Phone 8 returned back to C - we'll see where it'll lead), where is this success? I'm talking about "next C" which means that either it replaces C as program-development language or it replaces it as OS kernel-level language. AFAIKS Java and C# both failed there. Spectacularly. Sure, they carved niche for itself, but so did many other languages - from VBA to PHP and Perl, but "next C"? Not even close.
Rust Posted Apr 4, 2013 20:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Java succeeded on mobile (Android) and on the server-side. C# is very successful on Windows both on client and server side.
>I'm talking about "next C" which means that either it replaces C as program-development language or it replaces it as OS kernel-level language. AFAIKS Java and C# both failed there. Spectacularly.
Rust Posted Apr 4, 2013 20:42 UTC (Thu) by khim (subscriber, #9252) [Link] Java succeeded on mobile (Android) and on the server-side. Java is used to write huge amount of new code, that's true, but the same can be said about PHP or JavaScript and number of projects which switched from C to Java is so minuscule it's not even worth talking about. Android only caught up when it allowed execution of C/C++ code and can only be counted as yet-another-failed-attempt-to-replace-C++-with-Java (or may be it was never planned as such an attempt: some people claim that NDK for Android was planned from the start and was just released later because it was not ready for Android 1.0). C# is very successful on Windows both on client and server side. Again, in the same fashion: some pieces are written in C# but amount of new C++ code does not go down at all and people rarely make conscious decision to switch from C++ to C# (few projects did that - notably Visual Studio itself - but these are rare exceptions, not rule). If anything C# replaced Visual Basic not C++ - and that only happened because Visual Basic was brutally killed (Visual Fred is not Visual Basic). P.S. Note that I don't argue that Java and/or C# are not popular - of course they are (I don't necessarily think it's good thing, but that's irrelevant), but are they popular as "Glorious Successor to C" or "Glorious Successor to C++"? Of course not! Not even close!
Rust Posted Apr 4, 2013 21:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Java is used to write huge amount of new code, that's true, but the same can be said about PHP or JavaScript and number of projects which switched from C to Java is so minuscule it's not even worth talking about.
Heh. You clearly haven't seen the number of large enterprise projects switching from C++ to Java in 90s and early 2000-s. Ditto for C# - quite a lot of software was rewritten in it.
A good C++-like language does not NEED to be directly compatible with all braindeadness of C, it just needs to have a good FFI.
>Again, in the same fashion: some pieces are written in C# but amount of new C++ code does not go down at all and people rarely make conscious decision to switch from C++ to C#
Rust Posted Apr 5, 2013 7:38 UTC (Fri) by khim (subscriber, #9252) [Link] You clearly haven't seen the number of large enterprise projects switching from C++ to Java in 90s and early 2000-s. Yes, I have seen these failures. What about them? Sure, with well-oiled PR machine you can convince pointy-haired bosses to adopt basically anything and because they can not admit that they goofed up failures are often presented as successes (Elop is undisputed leader here, but he's not the only one). In any case they are mostly about hype: systems written in Cobol, Pascal, dBase and other similar languages are often still used even when bosses think they operate pure Java (or C#) shops. IOW: if anything "the big switch of enterprise to Java and C#" is nothing but smoke and mirrors. PR achievement at best.
Rust Posted Apr 4, 2013 23:11 UTC (Thu) by HelloWorld (guest, #56129) [Link] (Visual Fred is not Visual Basic)I see esr still doesn't understand The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets. sigh.
Rust Posted Apr 4, 2013 19:06 UTC (Thu) by ncm (subscriber, #165) [Link]
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.
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.
[1]http://research.microsoft.com/en-us/um/people/simonpj/pap...
Rust 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.
Case in point: the benchmarks game.
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 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
...
call strtol
mov edi, eax
call sq
imul eax, eax
mov edi, OFFSET FLAT:.LC0
mov esi, eax
xor eax, eax
call printf
...
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.
|
|||||||||||||