[jkarneges]

> I see [..] Rust replacing C/C++ (yeah, even C)

To me, the possibility of Rust replacing C is the most interesting aspect of the language.

(I'm not sure I see it replacing C++, but maybe competing with it; choose between evolution or revolution!)

The general hype around Rust is fascinating to me though. I assume it's mostly driven by former C/C++ programmers, but the process has been noisy enough to attract attention from the general developer community? If anyone wanted a non-GC language, C++ has been here since forever and is still being worked on. But Rust has somehow made non-GC seem cool?

> It may never be truly C speed, but from where I stand the tradeoff is worth it

I'm a Rust newbie and haven't benchmarked anything, but the sense I get from the docs is that it theoretically can be as fast depending on how much you limit yourself. Kinda like how C++ can be as fast as C, if written with care.

It would be great to see a write-up comparing Rust and C overhead, e.g. cpu/memory overhead of function calls, slices, etc.

[hardwaresofton]

I think the hype around rust is actually pretty well warranted though -- people got really excited about Go and Rust because they were new "systems" languages, and the world hasn't really seen one of those in a while. "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed -- I think most people would agree with that.

I think Rust is interesting to the people already using non-GC languages is precisely because it offers the speed of C/C++ with LESS of the footgun aspect. Writing C/C++ is accessible and familiar, but it is far from simple, there are tons of pitfalls. Rust has less of those, and takes a modern approach to much of it's toolchain bits and ergonomics.

> I'm a Rust newbie and haven't benchmarked anything, but the sense I get from the docs is that it theoretically can be as fast depending on how much you limit yourself. Kinda like how C++ can be as fast as C, if written with care.

Almost axiomatically, if Rust could be built 100% with ONLY zero cost abstractions, then it could certainly be as fast as C. Concretely, I don't think that's possible, because usually abstractions will cost you something even if it's just a single extra function call redirection. However, you can definitely get to a point where the difference is negligible, and the downsides (maintainability taking a nosedive) make the tradeoff worth it.

I think if you were to compare rust and C overhead in terms of function calls, slices and the like , you'd just be comparing compilers and micro optimizations implemented in both. I think it's kind of hard to test for the things that really make rust shine -- it's all the time you DON'T spend on race condition bugs, and the time you DON'T spend debugging pointer issues.

[steveklabnik]

> Almost axiomatically

It's more complex than that. You also have to consider the expert vs the general case. So for example, Rust can automatically apply the equivalent of restrict to many of your pointers. An expert with 100% accuracy could do so in C, but an average C programmer may not. Thanks to the compiler, the average and the expert Rust developer will both do this all the time.

Then, there's the cases when being safer and checked by the compiler means you can be more aggressive. When writing code that needs to be maintained over time, you need to make decisions that will ensure correctness even as you modify the code. And as your staff turns over. Rust lets you do very aggressive things, while making sure that you won't say, introduce thread unsafety accidentally. Not only that, but currently, since LLVM does all optimizations, we have to deal with the ones that are designed for C or C++; Rust is already quite fast without Rust-specific optimizing.

Anyway, in the end, we'll be sometimes slower and sometimes faster than C, just generally. I think it'll be very interesting to watch over time.

[whyever]

> "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed

Go does not let you manage memory manually.

[hardwaresofton]

You're absolutely right -- I didn't think I had to re-state that here since it's like the second sentence of the original comment. That's also why I went into qualifying "systems" language, some might consider golang a systems language, even though it very much does not allow manual memory management, which is why it's vague (and I put it in quotes).

[sevensor]

> I assume it's mostly driven by former C/C++ programmer

From what I can tell, Rust seems mainly to have attracted people from dynamic interpreted languages who weren't deeply invested in C or C++. I think it's easier to sell a Ruby programmer on performance than it is to sell a C++ programmer on an unfamiliar safety mechanism.