[w8rbt]

I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.

[wongarsu]

>Rust claims to be faster than C and safer than C at the same time. That's not possible.

Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C.

I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.

[pjmlp]

Attempted multiple times, always ignored by the C crowd.

[averell]

That is very much possible in many cases. Zero cost abstractions exist: https://blog.rust-lang.org/2015/05/11/traits.html

[vvanders]

Performance comes from being cache aware and having control over allocations moreso than safety checks.

Maybe not faster than C but at least as fast while bringing modern patterns and better safety.

[coldtea]

>Rust claims to be faster than C and safer than C at the same time. That's not possible.

It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.

[nitroll]

It is, especially if these checks are done at compile time, not at runtime.

[berkut]

How can checks be done if the size is dynamic based on run-time data?

[prodigal_erik]

"Integer between 0 and n-1 inclusive" is the type of valid indices for an n element array. The trouble is most languages don't have type systems that allow expressing that.

[pjmlp]

The Pascal family are such languages.

[102910201]

Expect a blog post within four hours "Rust has solved the halting problem!"...

[prodigal_erik]

Even when you can't prove what arbitrary code does, proving what well-written code does is useful, and not writing unprovable code would be a small price to pay.

[jdright]

And it is not. It is not faster than C but it can be almost as fast someday.

[w8rbt]

The rust zealots say it is, "Better performance than C"

That's from the linked article 'Rust is Software's Salvation' (bullet point 3).

[EugeneOZ]

It's possible: http://2015.splashcon.org/event/splash2015-tutorials-concurr...

[kstrauser]

That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way.

That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.

Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.

[comex]

Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.

[burntsushi]

rayon probably deserves a mention here: http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo...

(It's not built in, but that's a good thing IMO. :-))