tsc is (very) slow and there are also no convenient ways to interact with it from Rust.

So it saves a lot development and CI time to roll our own. The downside is that our inference still isn’t as good as tsc of course, but we’re hopeful the community can help us get very close at least.

I would argue that because C is so hard to program in, even the claim to machine efficiency is arguable. Yes, if you have infinite time for implementation, then C is among the most efficient, but then the same applies to C++, Rust and Zig too, because with infinite time any artificial hurdle can be cleared by the programmer.

In practice however, programmers have limited time. That means they need to use the tools of the language to save themselves time. Languages with higher levels of abstraction make it easier, not harder, to reach high performance, assuming the abstractions don’t provide too much overhead. C++, Rust and Zig all apply in this domain.

An example is the situation where you need a hash map or B-Tree map to implement efficient lookups. The languages with higher abstraction give you reusable, high performance options. The C programmer will need to either roll his own, which may not be an option if time Is limited, or choose a lower-performance alternative.

You’re implying that Linus is somehow responsible for burning out Marcan? I don’t think that’s a fair assessment.

So far, the only good argument I have really seen from the ones opposing the Rust4Linux effort comes down to: adding Rust to a C codebase introduces a lot of complexity that is hard to deal with.

But the argument offers no solution except to give up and not even attempt to address the real issues the kernel struggles with. It’s effectively a form of defeatism when you want to give up and don’t want to let others attempt to do what you don’t see as feasible.

Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

Cool, that was an informative read!

If we were willing to leak memory, then we could write […] Box::leak(Box::new(0))

In this example, you could have just made a constant with value 0 and returned a reference to that. It would also have a 'static lifetime and there would be no leaking.

Why does nobody seem to be talking about this?

My guess is that the overlap in use cases between Rust and C# isn’t very large. Many places where Rust is making inroads (kernel and low-level libraries) are places where C# would be automatically disqualified because of the requirements for a runtime and garbage collection.

While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.

Issue resolved

I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.

The System76 scheduler helps to tune for better desktop responsiveness under high load: https://github.com/pop-os/system76-scheduler I think if you use Pop!OS this may be set up out-of-the-box.

Of course, technically you can compile anything to almost anything. But I don’t think linking to a project that’s unmaintained for 15 years really helps your argument.

This is the actual PR, btw: https://github.com/getgrit/gritql/pull/85