Rust Infrastructure Pull Request Submitted For Linux 6.1!

[jacob]

Rust's compile time overhead isn't even bad, I find it well within expectations. The complaints seem to be from people coming in from Python... which well yeah it's not going to be instantaneous like an interpreted scripting language.... but if you're coming from another normal compiled language it's.... average. No better or worse than anything else in the category.

I find it to be on the worse side. Go in particular compiles nearly instantaneously. Rust is usually similar or slightly better than C++, and not terribly worse than C because of its preprocessor.

[BreachScrambler]

- Rust is generally better at autovectoring than C

As someone who prototyped* multiple implementations of fast-math in rustc, this isn't true for floating points.

And even in integers where it does well, you have to be careful about the indices else you prevent the compiler from deducing that bounds checking can be elided out (if triggered on multiple arrays, this can be a harsh perf hit). Iterators usually help with auto-vectorization, but not all algorithms can be mapped cleanly into them.

* If anyone here is curious, fast-math can be used in stable using the linker-plugin-lto flag.

[Luke_Wolf]

I find it to be on the worse side. Go in particular compiles nearly instantaneously. Rust is usually similar or slightly better than C++, and not terribly worse than C because of its preprocessor.

Oh no a language that was designed around quick compile times and simplicity for language implementors is fast whereas a language targeted at the same space as C and C++ falls within vaguely the same compile times... whatever shall we do?

The entire complaint is totally absurd.

[cardich]

It takes away the memory safety foot guns that C developers are so fond of using to blow their own feet off.

We got tired of fairy tales with dragons and Rust.

[uxmkt]

Ah, the old fallacy.
It's been proven time and again Rust is every bit as fast as C.

Ah, the old fallacy. Languages don't have an intrinsic speed(*), so it's nonsense to say "X is faster/as fast as/slower than Y". It's all a property of implementations. You can have a shit C compiler/runtime (hi MSVC), and you can have a shit Rust compiler/runtime.

(*) Of course esoteric programming languages will do whatever. Specifications of common general-purposes programming languages however generally don't say "this has to execute in 17 nanoseconds". At best, they'll mention the scaling characteristic of certain APIs (e.g. C++'s std::map should be logarithmic with #elements -> \infinity).

[karolherbst]

I find it to be on the worse side. Go in particular compiles nearly instantaneously. Rust is usually similar or slightly better than C++, and not terribly worse than C because of its preprocessor.

Go compiles fast because the compiler isn't great at optimizing.

[RahulSundaram]

Ah, the old fallacy. Languages don't have an intrinsic speed(*), so it's nonsense to say "X is faster/as fast as/slower than Y". It's all a property of implementations.

Certainly some of it very much dependent on the language. If you have a dynamic language like Python where things are determined at runtime, even with a highly optimized implementation, it just isn't going to compete on raw performance with a language where more things can be determined at compile time. So both the language *and* the implementation matters. Not just one.

[Weasel]

Not even that. Fortran has always been faster.

You have restrict in C so no.

Plus C's million dollar mistake with zero terminated strings means that trivial operations like strlen() are O(n) instead of O(1).

But who gives a shit about the standard library? Nobody forces you to use it. You can use length-prefixed strings in C just fine.

[karolherbst]

You have restrict in C so no.

But who gives a shit about the standard library? Nobody forces you to use it. You can use length-prefixed strings in C just fine.

Most won't if the language doesn't provide the interfaces. A good and reliable standard library is the most important thing for a good programming language.

[marios]

Most won't if the language doesn't provide the interfaces. A good and reliable standard library is the most important thing for a good programming language.

I disagree. The standard library should not even be considered as a part of a language. It is just an (important) extra. Only the syntax/keywords are part of the language and I think everything else (including standard libraries) should be standardised separately.