[jesse__]

I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself.

The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

[Yoric]

My anecdotal experience is the opposite.

I write code much faster in Rust than in C++. Part of it is thanks to the type system – fewer opportunities for dev errors means that I can produce code that is more concise, spends less time handling runtime errors because I can have static guarantees that they have already been handled somewhere, etc. Part of it is #[derive(...)], great documentation, Cargo and other QoL components of Rust.

[jesse__]

Fair enough. I can imagine if you largely write code that plays nice with the compiler it could be faster. That just hasn't been my experience.

[__jem]

> The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

Why is this your exercise you have in mind though? This is such a bad argument. Like, yes, if you work at doublylinkedlist.com where your entire job is writing a new linked list implementation every day of the week, Rust might be a bad choice. But that's not what any kind of commercial enterprise actually looks like. If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.

[jesse__]

>> Why is this your exercise you have in mind though?

That was an example I could point to where the code size difference between Rust and C or C++ is roughly 10x. I mentioned it to corroborate the claim that sometimes writing Rust is very verbose, on the order of ten times more.

My point was not that average commercial codebases are largely dominated my these types of structures. My point was that my experience with Rust has been that the development slowdown is much more than 5%, as the OP suggested.

>> If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.

And that's one reason we don't work together ;)

[pkulak]

A lockless thread queue (not entirely sure what that would be, sorry; a queue in front of a pool?) seems like the kind of low-level library that could be written with liberal use of unsafe. No need to flagellate yourself on the altar of compile-time safety.

[jesse__]

Then why would I use rust in the first place?

[ColonelPhantom]

So that you can write "primitives" such as a queue in unsafe, and assuming it is correct, it is not possible to introduce bugs from other code.

Also, things like queues tend to be implemented in either the stdlib or a very popular library. So they are very well tested and likely to be widely reviewed.

[jackmott42]

I'm sure there is a ton of variance. I have done some Rust projects where I run into absolutely no safety complaints from Rust because it just isn't the kind of code that does anything the borrow checker cares about. For those development time ends up typically faster than C/C++ due to various syntax and tooling niceties.

Other projects will really get into domains where you have to work hard to satisfy the borrow checker and it can slow you down a lot. In a real application you won't be writing lockless thread queues for a big % of the time. But then for a real application the compile times will start to weigh on you more. (Though, C++ does not always compile fast either unless some care is taken to be sure it does)

[ttfkam]

And you're running at least one static analysis tool and a linter on your C++ code too, right? You're not just deploying the C++ compiler output as-is, right?

Those take time to run too and should absolutely be added to the compile time metrics when comparing against "cargo build".

[jesse__]

On a personal project I run 2 metaprogramming passes, compile the entire project (~2m LoC) _twice_ and run the entire test suite in < 30s on a laptop from 2010.

I don't run a linter because I hate them, and my metaprogramming passes do a bit of extra static checking clang doesn't. I occationally run extra static tools (valgrind et. al) but they're painfully slow and very rarely catch anything.

[kaba0]

Rust in incremental build mode is not slow at all, I really don’t see why people say so.

[kajaktum]

>The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

Do they have an equivalent API? Rust does have a hard time explaining very, very low level stuff that you'd have to do unsafe and various magicks. But once you get the unsafe details right, the consumer API for them tends to be extremely rigid and fool proof.

[jnordwick]

> Rust does have a hard time explaining very, very low level stuff

A little odd for a supposed system langauge

[kaba0]

But it is just not true. Rust has a hard time writing algorithms where objects don’t have a singular owner. That’s all, it is not low level stuff. It for example has proper SIMD support, while the supposedly low level c doesn’t.

[mcronce]

This is an ... interesting argument. "I can't write this 200LOC component of a large codebase in safe Rust, so what's the point in Rust?"