Is Rust faster than C?

Re:Is Rust faster than C? by tcfhgj on Wednesday January 14, 2026 @10:02AM (#46616807)

what about generics (equivalent to templates in C++), which allow compile time optimizations all the way down which may not possible if the implementation is hidden behind a void*?

[ Parent | on HN ]

Re:Is Rust faster than C? by OptionOfT on Wednesday January 14, 2026 @12:52PM (#46619429)

Unless you use `dyn`, all code is monomorphized, and that code on its own will get optimized.

This does come with code-bloat. So the Rust std sometimes exposes a generic function (which gets monomorphized), but internally passes it off to a non-generic function.

This to avoid that the underlying code gets monomorphized.

https://github.com/rust-lang/rust/blob/8c52f735abd1af9a73941...

[ Parent | on HN ]

Re:Is Rust faster than C? by dwattttt on Wednesday January 14, 2026 @07:39PM (#46626266)

> This does come with code-bloat. So the Rust std sometimes exposes a generic function (which gets monomorphized), but internally passes it off to a non-generic function.

There's no free lunch here. Reducing the amount of code that's monomorphised reduces the code emitted & improves compile times, but it reduces the scope of the code that's exposed to the input type, which reduces optimisation opportunities.

[ Parent | on HN ]

Re:Is Rust faster than C? by josephg on Wednesday January 14, 2026 @08:41PM (#46626798)

Yes. But I like that rust gives you the option.

In C, the only way to write a monomorphized hash table or array list involves horribly ugly macros that are difficult to write and debug. Rust does monomorphization by default, but you can also use &dyn trait for vtable-like behaviour if you prefer.

[ Parent | on HN ]

Re:Is Rust faster than C? by bonzini on Thursday January 15, 2026 @03:31AM (#46629754)

There is also the "momo" crate to do the same with a procedural macro attribute (https://docs.rs/momo/latest/momo/).

[ Parent | on HN ]