LWN: Comments on "Mozilla and Samsung building a new browser engine"

Rust

roc — 2013-04-08T01:58:09+00:00

Rust isn't designed to be "a better C++". It's designed to provide features C++ doesn't have:
-- Type/memory safety guarantees
-- Parallel programming with a guarantee of no data races (primarily by enforcing "no mutable shared memory")
-- Lightweight isolated tasks as a unit of failure

Developers who don't want those things should stick to C++. Developers who want all those things can't get them from C++ and should consider Rust, among other alternatives. Developers who want those things in a language which is as close as possible to C++ in performance should strongly consider Rust.

Rust

HelloWorld — 2013-04-07T21:50:26+00:00

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

mathstuf — 2013-04-07T18:11:30+00:00

GCC does have a pure attribute, but it's not verified that you're using it properly and no one uses it anyways…

Rust

hummassa — 2013-04-07T18:08:34+00:00

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

mathstuf — 2013-04-07T17:59:21+00:00

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

HelloWorld — 2013-04-07T15:10:02+00:00

> 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.

Rust

HelloWorld — 2013-04-07T14:13:03+00:00

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

anselm — 2013-04-07T14:04:10+00:00

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

hummassa — 2013-04-07T12:19:38+00:00

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

HelloWorld — 2013-04-07T11:27:49+00:00

> C is slow, too, slower than Fortran
Programming languages aren't fast or slow, programs are.

Case in point: the benchmarks game.
http://benchmarksgame.alioth.debian.org/u32/benchmark.php...

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

mathstuf — 2013-04-07T05:25:00+00:00

> 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

ncm — 2013-04-07T05:03:14+00:00

C is slow, too, slower than Fortran, so it's not a good standard for comparison.

Rust-lang

HelloWorld — 2013-04-06T16:38:15+00:00

Yeah, I know, people confuse + and ++ in C all the time. Oh wait: they don't!

Rust

mathstuf — 2013-04-06T13:34:23+00:00

> 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...
[2]http://www.reddit.com/r/programming/comments/1bs0p3/haske...

Rust-lang

gevaerts — 2013-04-06T13:24:59+00:00

> you've confused ::: and ::
Are you sure you're making the point you're trying to make?

Rust-lang

HelloWorld — 2013-04-06T00:26:08+00:00

> So imagine a case where both branches are different.
That's a type error in itself in most cases. In order for such code to typecheck, the branches' types must have a common supertype. As far as I can see, Rust allows only interfaces to form hierarchies, and I don't know if it's even possible for () to implement interfaces. But even if it is, this situation is going to be so rare that it's not worth losing any sleep over it.

Rust-lang

jimparis — 2013-04-05T22:47:22+00:00

> It doesn't matter whether the branch can be taken, the values of both branches are of type ()

So imagine a case where both branches are different. Or where the conditional is deep inside a function before the return value finally gets to the assignment. If having a conditional return type () makes sense in some cases and not others, then you can't trivially warn about it.

Rust-lang

HelloWorld — 2013-04-05T22:18:48+00:00

> A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.
It doesn't matter whether the branch can be taken, the values of both branches are of type (), and it doesn't make sense to store a value of that type in a variable.

Rust-lang

jimparis — 2013-04-05T17:01:04+00:00

A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.

Rust

tjc — 2013-04-05T15:00:57+00:00

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-lang

HelloWorld — 2013-04-05T12:54:10+00:00

It is trivial to add a warning for that. Just check if a local variable is bound to a value of type ().

Rust-lang

renox — 2013-04-05T12:39:02+00:00

Yes, in Rust you have to be very cautious about the usage of ';'!
Thankfully as the return type of functions is not inferred but given explicitly in many cases the compiler will be able to complain, not in the example you've given though.

Apparently they don't like 'return', I'm not sure why.. Maybe it's because it's 'big' (they seem to like short keyword)?
In this case, they could have done like SmallTalk use '^' instead of return.

Another weird part is the for: 'for v.each |e| { bar(*e);}', uh?
The languages I know use either for (for e in set { .. }' or each (set.each |e| { .. }) but having both for AND each at the same time??

Also code with named lifetime seems really hard, but I don't think that's a syntax issue, it's just a difficult concept to master.

Rust

ncm — 2013-04-05T08:38:51+00:00

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-lang

dgm — 2013-04-05T08:21:58+00:00

I don't find those much problematic, but go read the tutorial, and in section 3.1 you will find that:

let var = 
  if (condition1) {
    value1
  } else {
    value2
  };

is completely different from:

let var = 
  if (condition1) {
    value1;
  } else {
    value2;
  }

The second one would be almost surely a mistake, but the compiler would not complain. In my opinion this defeats the purpose of doing Yet Another Curly Brace Language. The mere fact that they feel they need to point it out in the tutorial is a clear sign that something is wrong here.

I hope they get this sorted out before 1.0

Rust

khim — 2013-04-05T07:38:31+00:00

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

khim — 2013-04-05T07:32:16+00:00

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

ncm — 2013-04-05T07:00:40+00:00

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

HelloWorld — 2013-04-04T23:11:35+00:00

(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-lang

HelloWorld — 2013-04-04T22:55:36+00:00

Nobody writes it that way, there's a reason why one is allowed to omit the . and the (). Also, you've confused ::: and ::. qsort(rest) ::: pivot :: qsort(smaller) I don't think this looks too bad.

Rust

Cyberax — 2013-04-04T21:39:37+00:00

>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#
And I've seen tons of these switches. People were eager to jump C++ when an acceptable alternative presented itself.

Rust

khim — 2013-04-04T20:42:54+00:00

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

khim — 2013-04-04T20:29:40+00:00

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

Cyberax — 2013-04-04T20:04:27+00:00

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.
You don't need to replace C as a language for the kernel (though C# can be used even there - see Singularity OS).

Rust

khim — 2013-04-04T20:00:59+00:00

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

ncm — 2013-04-04T19:06:02+00:00

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

Cyberax — 2013-04-04T18:00:42+00:00

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-lang

Cyberax — 2013-04-04T17:59:28+00:00

Mac OS X with recent enough MacPorts. No problems at all during the build.

Rust

khim — 2013-04-04T17:39:28+00:00

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?

Rust-lang

Cyberax — 2013-04-04T16:39:27+00:00

"qsort(rest).::(pivot).:::(qsort(smaller))"

Rust-lang

tjc — 2013-04-04T15:43:02+00:00

> I've recently tried to use Rust instead of Go for simple "scripts" and I really loved it.

What OS/distro are you using? I tried to build Rust on both OS X and Linux Mint 12.04, but both failed, for different reasons.