[antirez]

Rust programs are safer than C programs but almost universally more complicated to write compared to C with equivalent high level libraries for data structures and other operations. So I can't see how your argument applies here.

[jamincan]

I think you'd need to support your statement that Rust programs are almost universally more complicated to write than C, given equivalent high-level libraries. I'd argue that ADTs, const-by-default, and being expression-based are all pretty simple and straight-forward features that make Rust programs easier to write and reason about without even getting into other higher-level features.

Occasionally managing lifetimes can be a headache, but it's not nearly as often as most people seem to think it is, and is precisely the sort of thing you should be concerned with fully understanding in a C-equivalent anyway.

[wongarsu]

"with equivalent high level libraries for data structures" is doing a lot of heavy lifting here. Getting and managing those high level libraries and data structures is much easier in Rust. I'd also argue that C's type system needlessly complicates correctly using those high level libraries and data structures compared to their Rust counterparts.

[mariusor]

> is doing a lot of heavy lifting here.

Yes, but the environment for this specific program is the linux kernel, where most of the high level libraries for data structures already exist in C already, and the Rust code is pretty constrained due to the existing limitations. A lot of, what I assume to be, data structure fanciness in Rust comes through non standard crates, and the kernel doesn't allow that as far as I remember.

[baq]

> Rust programs are safer than C programs but almost universally more complicated to write compared to C with equivalent high level libraries for data structures and other operations.

I'd argue equivalent C programs are usually undercomplicated due to missing safety requirements.

[steamer25]

Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".

Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).

[Kinrany]

I'm suggesting an outside view: give up trying to evaluate languages based on their features, evaluate languages based on programs written in them.

"X written in Y" advertises two things:

- language X turned out to be a reasonably good language for writing program Y

- program Y is likely to be good at things that X is known for making easy to do

Both of these seem useful, if prone to motivated reasoning.

[Kinrany]

But I agree that the article misrepresents the tweet. The promise is in achieving comparable performance with less effort, not in achieving better performance.

[reyqn]

Maybe for an experienced C programmer, but not everyone is one.

[jedisct1]

But until you're an experienced Rust programmer, you may frequently hit walls, spending a considerable amount of time trying to implement something that would be trivial in other languages, but requires a lot of contorsion to compile in Rust.

And once it compiles, the way you achieved it may be suboptimal, complicated, buggy, and even unsafe due to logic bugs.

My fairly large projects written in Rust have slowly become unmaintainable. There 's too much code that's just there to work around the borrow checker, and hurt readability. There are memory leaks and dead locks that I've never been able to pinpoint. There are dependencies that I stopped updating a long time ago due to constant breaking API changes. There are "unsafe" and "transmute" keywords because I couldn't figure out how to go through many layers of abstraction just to copy a type that resolves to an integer into another type that resolves to the same integer.

I've been writing Rust code for 10+ years and I still appreciate it for some projects, but I also really enjoy going back to C for the control, flexibility and expressiveness it offers, not to mention better performance. After Rust, it feels like fresh air.

[mplanchard]

Currently working on a ~120kloc Rust project, which is currently in its third year of existence. It's by far the easiest codebase to maintain I've ever worked in. Our only use of `unsafe` is for the sake of wrapping a C++ library from AWS, which also happens to be where our only use of `transmute` is. I'm able to make sweeping refactors across the entire codebase quickly and without stress. We try to encode logic in the type system where we can and make heavy use of Rust's enums, which makes the compiler able to catch the large majority of issues we might run into.

I think that if you avoid reaching for `unsafe` every time you're frustrated with the type system, you'll have a much better time.

[urschrei]

Being annoyed at articles that will have little or no impact on Rust's adoption in Linux are an unusual choice to spend your hard-earned credibility on. Why not simply let people enjoy things (speed, memory-safety, ergonomics)?