[antirez]

Are we at this level now? The scheduler performance has nothing to do with the used language. Actually making use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision in the most direct way. Moreover scheduling is all about tradeoffs: it's not hard to write a scheduler that is better than a genera purpose one for a specific task. If you like Rust write your code in Rust but the community should stop with this kind of attitude.

[bluejekyll]

What attitude are you referring to? An engineer wanted to play around and see if they could get something to work. Not only did it work, for one task it worked well, so it probably exceeded their initial goal?

I thought that was exactly what we encouraged here on HN?

[otikik]

Antirez, I respect you immensely. I know you know what you are talking about. I do think that there's too much hype around rust.

That said, I also think that we live in a world where a little bit of clickbait or hype-riding is admissible. The economics of the thing make it almost mandatory. I would just acknowledge the hype, nod in disagreement, and move on. At the end o the day this is about someone tinkering with a language they enjoy. Let them have that.

[antirez]

I believe that some hype / over-enthusiasm is acceptable, but I'm a bit more worried when a given community uses it as some kind of organized propaganda, arriving to excesses like saying that writing code in non-safe languages should be considered immoral, and also never admitting that Rust is a compromise in the design space like anything else. So ok for the hype, but sometimes I see some excesses. Anyway this is just my very limited opinion, I don't claim to be right, I just believe my feeling represents some part of people here.

[dragonsh]

Like you said its fine to promote language on its merit, but using false propaganda to promote it borders fraud and Rust community needs to act together to stop such practices.

Overhype within Rust community is a sign of fear among the community that some simple language (may be zig, nim or something new) might come and pull the rug under their feet. Given it compromise on simplicity in favour of quashing memory safety bugs.

One reason rewrite in Rust is popular because its easier to copy something already done vs doing something original (one recent example came to mind is rewriting gnu coreutils in Rust).

[odiroot]

Thank you for your comments :)

[rcxdude]

Especially when the hype is added by a third party. This is an article about a hobby project written in a few weeks and yet the headline suggests it is somehow a serious contender for being added to Linux (right now at least. Maybe something grows out of this, most likely not)

[ksec]

>Especially when the hype is added by a third party.

I think this is ( or should have been ) obvious but also an interesting observation. At least it never came across my mind. The Hype driven feedback loop that generate a positive ( so to speak ) hype cycle.

The Rust community has definitely toned down a lot of their evangelism in the past 2 years. After obviously enough people came out to say enough is enough. But the third party continue the trend regardless.

[bheadmaster]

> I would just acknowledge the hype, nod in disagreement, and move on.

Which is exactly what he did, in addition to also acknowledging the pattern of the Rust community using hype to attract attention. He didn't force anything onto anyone, he just expressed his opinion.

[loeg]

Don't mistake Phoronix as any more representative of the Rust community than it is of the Linux kernel community.

[Yoric]

To be fair, I've seen this happen with every language community.

[bheadmaster]

Every community has a hype period, true.

But I don't think I've ever seen any other community (except C++, 20 years ago, perhaps?) being so vocal about wanting to rewrite the whole software ecosystem in their language. "Rewrite it in Rust" is basically a catchphrase now.

[Pet_Ant]

> But I don't think I've ever seen any other community (except C++, 20 years ago, perhaps?) being so vocal about wanting to rewrite the whole software ecosystem in their language.

cough NodeJS cough

[Yoric]

I remember the Java community attempting to rewrite the world in Java (Jazilla, anyone?)

I remember web browsers written in Perl.

We live in a world where everything is being rewritten in JavaScript.

etc.

[bheadmaster]

True. I suppose the main difference is that nobody (in their right mind) was ever advocating for rewriting fundamental system components such as Linux (the kernel) and all the GNU system utilities in Java/Perl/JavaScript. If they were, then I completely missed them.

[jacquesm]

Only if it doesn't harm your cause, which it does.

[iknowstuff]

What do you think their cause is?

[mamcx]

> ... use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision

This is highly misleading. That is not true. At all.

Just take a sample: Do you write OO on C? No, because C is a terrible OO language. Do you write short optimized array-oriented code on C? No, because C is not APL.

People write C how people write C, the way C make them write it.

Moving into other paradigms, you see things differently.

Rust makes a lot of idioms that are inexistent on C viable: Algebraic types alone will shape the way you do algorithms by a lot. Then they push for better errors, then know exactly where things alloc, etc.

Coding in Rust is distinctly different from code in C. It is like the best way you can refactor a codebase: You come for the safety and tooling, you stay because the algorithms write better themselves.

[surajrmal]

Writing oo style code in c is extremely common. At least where I work we often pass around structs of function pointers to accomplish roughly the same thing a vtable would give you and name methods such as foo_verb for methods that operate on struct foo.

An algebraic data type is just a c union with an auto generated flag and moving some type validation to compile time. Unions used in this manner are quite common in C. I do think the increased ergonomics and safety exist, but only when paired with other features like pattern matching. Selling algebraic data types alone as the major novel feature improvement is a bit misleading and dismissive of existing c features.

I do agree that additional compile safety in rust makes it far easier to confidently refactor without introducing bugs. Accomplishing the same in C requires a lot of unit tests which add maintenance overhead. Python is a more extreme example of that playing out. That all said, I don't think it's necessarily relevant to writing a performant scheduler.

Rust has many strengths and I endorse using it over C any day. That said, the way it's marketed feels misleading and gives experiences c developers bad vibes.

[the_third_wave]

> Do you write OO on C?

Yes, have a look at GTK, GOBject and parts of Gnome.

> Do you write short optimized array-oriented code on C?

If you want to stay close to C you'd use something like SAC [1] but no, pure C is not an array programming language.

> People write C how people write C, the way C make them write it.

C is sometimes called 'structured assembly' for a reason: it is a toolbox which can be used to construct things the way you see fit. This does mean you need to involve yourself more with certain implementation details since C itself does not force you to use any specific paradigm and as such does not provide you with the basic tenets of those paradigms. If you want to do OO in C you'll have to provide a pointer to the object you're working on in any function call related to that object since C does not assume there to be a 'current object'.

Does this mean C is the most optimal language to do OO programming or array programming? No, clearly not, this is why languages like C++/Java and APL were created. On the other hand it does mean that it is possible to do these things in C and - given the success of Gnome and GTK - doing so can be a viable proposition. The advantage of using C is that it is nearly universally portable, more so than many other languages.

So yes, use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision is actually true in that it is possible to do so. You may not want to use C for these purposes but that is irrelevant when considering whether it is possible to do so.

[1] https://www.sac-home.org/index

[hajile]

Isn't GTK effectively dynamically typed in C?

[Ferret7446]

OO and other paradigms are not algorithms. They are particular ways of organizing code. Any algorithm can be implemented with OO, FP, or plain procedural style. Objects can be closures. Loops can be TCO recursion.

[pseudocomposer]

So, you're definitely a better programmer than me. That said, there are more programmers at my level and below than at yours. I would not advise anyone to run a Linux scheduler I wrote and tested in C. However, if I wrote and tested one in Rust, I might not feel bad letting people use it.

All this news tells us is that a Rust implementation can compare to a C implementation in this field. As you say, schedulers are all about tradeoffs in the end anyway. This news unlocks us having more options, both C and Rust schedulers, meaning a better experience for the Linux community across a variety of workloads. Thus, I don't see any reason to be defensive about Rust performance being found to be comparable to C here.

[soulbadguy]

> I would not advise anyone to run a Linux scheduler I wrote and tested in C. However, if I wrote and tested one in Rust, I might not feel bad letting people use it.

For something as complex and sensitive as a kernel scheduler, i think "who" wrote the scheduler (as in how much experience writing scheduler), and what software dev. practices (especially how that thing was tested) and far better predictor than just the language used. I would actually go as far as saying that the language used might not even be a predictor at all.

No amount of rust safety would prevent things like dead/locks, quadratic algorithms in weird cases, unreleased resources etc... etc...

> All this news tells us is that a Rust implementation can compare to a C implementation in this field.

That's what the news "implied", but that's not actually what the news says. And i think that's what people are trying to call out.

The dev. implemented a prototype scheduler in rust, and in a very contrive case it does better than "a" C scheduler. The implementation are probably using different algorithm, they probably making different tradeoffs, we have no idea how safe and bug free his implementation his, and not even how safe it's (how much unsafe block is in that thing).

As an exercise to show that rust is a viable language to do kernel development in term of mature tool chain and good integration with kernel API sure. But as tool to compare C vs rust for kernel dev... this is pretty much worthless.

[Aurornis]

> Are we at this level now? The scheduler performance has nothing to do with the used language.

The whole project is a toy and they’re not trying to hide it. The mention of the language is just a descriptor for the project, not an implication that Rust is faster.

[underdeserver]

"Promising results for gaming performance" is not the kind of phrasing you use for toy projects though.

[loeg]

It's Phoronix, what do you expect? High editorial standards? Phoronix is the one overhyping this toy project, not the developer.

[sidkshatriya]

> It's Phoronix, what do you expect? High editorial standards?

It seems that you're implying that their standards aren't high. Is this a general feel of yours or based on some concrete examples ?

I think that Phoronix does a pretty good job. Its free, has some interesting benchmarks, covers technical topics like the Linux kernel, Graphics, Computer Hardware etc. quite well.

Phoronix gets criticized a bit too much. I don't get it -- maybe someone can explain.

[jedisct1]

I'd have expected more than HN editorial standards.

[underdeserver]

Never heard of them before ¯\_(ツ)_/¯

[loeg]

It's a long-running one-man show that is quick to publish sensational, sometimes inaccurate recaps of emails from mailing lists.

[Kinrany]

Any program can be written in assembly. The purpose of languages is to make writing programs easier. Every useful program written in language A that could also be written in language B or C is a piece of evidence that writing programs in A is easier.

[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)?

[asveikau]

I had a similar reaction. It's not rust that makes this faster. It's the algorithm chosen. The rust part is an attention grabbing headline.

However I could see an argument that rust or another higher level language makes it easier for someone to experiment with a new algorithm and iterate faster on those ideas.

[viraptor]

It's not just attention grabbing. So far, almost all rust development I've seen has been in drivers. Getting something as core as scheduler replaced is a very interesting event.

[asveikau]

I remember replacing the Linux scheduler in an undergraduate class. It's probably changed since those days but I don't think it's that hard. Doing a good job is probably very hard though.

[viraptor]

I don't mean that it's particularly hard, but rather that it's using new interfaces which haven't been exposed yet, AFAIK. Scheduler itself + bpf is there from what I've seen, but likely other things too.

[asveikau]

But isn't exposing a C interface to Rust very easy? In either direction...

[viraptor]

1:1, calling the original functions - sure. Building a good usable interface - that's harder.

[electricant]

Well it's not just about Rust. What we have here is pluggable schedulers leveraging the BPF functionality within the linux kernel. They can be written in watever language you like and they are running in the user space.

[SpaceNugget]

eBPF doesn't run in user space in the context of eBPF in the linux kernel. It's verified so that the kernel can be sure it won't loop forever and then gets JIT'ed and run in kernel space.

There are some user space BPF vms like https://github.com/iovisor/ubpf and Solana.

[knorker]

1. It's interesting that Rust is not just viable in some less important kernel code, but possible in core components. 2. C isn't necessarily the best language for performance. Specifically it's not very good about letting the compiler make assumptions about aliasing. Same reason some CPU-heavy stuff tended to use (ugh) Fortran[1]. Rust is better than C in giving the compiler access to this information for optimization.

But I think you read the article and the post wrong. It's not "ha ha, C suxx", it's just... interesting.

[1] I say "tended", because presumably nowadays it's optimized for GPUs, and I've not been keeping up.

[ot]

> The scheduler performance has nothing to do with the used language.

This is correct, but I don't think the article is trying to make any claim about the language being relevant for performance.

What I believe the author is showcasing is two things:

- sched_ext allows to write schedulers that outperform a default general-purpose scheduler on certain workloads (performance)

- Since a sched_ext scheduler is a userland process, it can be implemented in any language. The author likes Rust and they used Rust (ergonomics)

The headline compresses both things in one sentence, and this can create some confusion about what they intend to convey.

[jedisct1]

Rewriting something, or writing something new but with past experience always produces a better product. Some people still attribute that to using a new language or framework, or market their new product that way.

But the real driver is the rewrite, not the tools. In that case, what's interesting is the algorithm, not the language it was implemented in.

Reminds me of a famous YouTuber making videos about new tech. Every video starts with "a company based in <name of a country> announced..." or "researchers from <name of a country> found..." - This is annoying. Does the country matter? Do people ignore or mock inventions from countries they don't like, writing on HN that they should be reinvented in another country because other countries suck? Fortunately not. But when it comes to programming languages, they do. And this is equally ridiculous.

[soulbadguy]

This is such a core idea that as you find it really surprising how much it gets overlooked.

IMO, another important aspect of rewrite is that it's usually pretty easy to get 70% of the functionality for 40 % of the work. But as one approaches 100% feature parity , plus handling all the corner cases, the transition from prototype to production ready things equalize pretty fast.

Not to mentioned the unknown unknown that the new language might also bring.

[binary132]

The Rust thing here is a bit of a distraction, you can target BPF with C too.

[k8svet]

And yet, this is a theme repeated for literally years at this point with Rust.

I'm sorry, but I'm tired of this. It's like being at the skate park watching someone scream at someone else's kid. "oh my god, no you can't do that, that's not the right way to do that! you're going to hurt yourself! oh wait, you pulled off the trick and everyone is cheering! YOURE NOT SUPPOSED TO DO THAT!!!111".

Every single Rust thread is like this. There's at least three in this whole thread already. It's exhausting and weird. And this whole implication of a global conspiracy to push Rust everywhere rather than gee god, maybe people just like it and are effective with it.

Clearly, "George Soros funds Rust advocacy" /s