Comment by saosebastiao | Hacker News Reader

Comment by saosebastiao | Hacker News Reader

Parent Full thread

It's still not there yet, but getting close. And Rust is really the only language that has come close.

In terms of performance, it's really the only language out there that can claim to be as fast as C/C++. It has a minimal runtime, with the option of no runtime. It has pretty great FFI and can produce easily callable libraries for other runtime-heavy languages.

It's not, however, as broadly compatible as C. I don't think that's a problem for most cases, as most programming is now done for (MIPS|ARM|X86|X86_64), and it can handle those well enough. But microcontrollers and OS-less embedded devices still have a ways to go before Rust beats out C.

And stability is just not there. IMO, that's a good thing. Rust is the best thing to happen to systems programming in a really long time, and there are still tons of ideas with amazing potential benefits. The Rust community has been exceptional at guiding this development. I'm sure some day it will level off, but until then, I'm happy with it changing pretty rapidly.

I don't think "stability" and "changing rapidly" are incompatible notions. Stability implies that code written today continues to work years from now on later versions of the compiler and language. Rust has always (well, since 1.0) striven to provide stability in that sense, despite the rapid pace of language improvement.

> most programming is now done for (MIPS|ARM|X86|X86_64)

but not necessarily posix/windows/etc

having C as a least-common-denominator toolchain which almost all platforms will provide is still useful for the embedded world where sqlite has a huge number of applications..

Rust has a complete #nostd mode where most of it's ergonomics are still usable without any runtime. It also supports pluggable allocators, as well as replacing most of the builtin functionality of other language components (lang items).

It's story around panic and debug handling is also improving, including cutting out formatting code for things like println! and debug! when targetting embedded platforms.

It’s also not as fast as C/C++ in all cases, only in some.

http://benchmarksgame.alioth.debian.org/u64q/rust.html

The biggest differences there are due to lack of SIMD. We expect it to be stable quite soon, and that should close the gap quite a bit.

Do you say that because you have coded those programs using SIMD and rustc nightly, and seen that using SIMD eliminates the performance difference ?

I have not personally done this, but the people who have identified that as the issue, and what we’re stabilizing is the exact same thing as what C and C++ compilers have, so there’s no reason to believe it would be different. Once it’s stable, we’ll all see!

Someone has repeatedly commented on /r/rust/ that differences are due not so much to SIMD but iirc to not triggering the same LLVM loop unrolling.

I think you're confusing loop unrolling and autovectorization. That said, it's kinda moot, once SIMD is stable, we'll find out :)

>> I think you're confusing loop unrolling and autovectorization. <<

Here's exactly what I was told -- "This was achieved by manually unrolling a 10-step loop, which compiler apparently could not optimize."

I would say C will never be as safe as Rust. Just accept it, C is crap. It's just not cool.

You may want to check out Pony :)

Reply on news.ycombinator.com