Rust is far more portable in practice than C. Your average C program is written either for Unix or for Windows, while Rust has sufficient abstraction power to be able to write most business logic once.
I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest.
I think you have no idea how big the C ecosystem is. I am not sure what cargo-nextest is, but I have seen people solve the most challenging programs in C.
As I mentioned, cargo-nextest is a widely used test runner for Rust -- you're welcome to check out its website for its feature set.
It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C.
> I think you have no idea how big the C ecosystem is.
I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.
I also doesn't seem like anything most people would spend a lot of time on. I run my tests using "make" which somewhat poor but does the job. So from a programming side, what exactly do you think would be difficult to implement in C?
> I also doesn't seem like anything most people would spend a lot of time on.
That's because the conditions created by C make solving this problem very hard, not because the problem isn't worth solving.
It is still a hard problem with Rust, requiring heavy use of async state machines to manage a rather extraordinary level of complexity. But at least it is possible for essentially a solo dev like myself to do in a robust, largely bug-free manner.
> I run my tests using "make" which somewhat poor but does the job.
Right, "make" is indeed not quite a high-performance enterprise-grade test runner with parallel test execution, high-quality reporting, signal handling, dynamic status querying, timeouts, retries, flaky test detection, mutual exclusion between tests, a DSL that lets you specify sets of tests, flexible configuration, archiving tests to run on another computer, sharding test runs, JUnit support, wrapper scripts, setup scripts, and several other features. Make doesn't even properly support Windows, which is table stakes for a portable test runner.
Looks like you think only in windows and linux. Ok, but how much of your rust runs on freeRTOS or bare metal and on how many processor families? C? Runs on all of them. 6502? No Problem? 8051? Clearly! CRC16C? Yes. Eco32? yup. i386? Is developed to run C. Arm64, Arm? They too. They run Minix in their internal controlling hardware. Written in C...
Nextest works on a variety of platforms and architectures -- a lot more than x86_64 Windows and Linux. Porting to new platforms tends to be quite straightforward as long as someone's made Tokio work on that platform. (This is the power of abstraction! Turning MxN portability problems into M+N ones.)
C definitely has a place, but "Rust is not portable at all compared with C code" is simply not correct. A lot more Rust code works across Windows and Unix than C code does. Rust's portability story is different from C's, much better in many ways but worse in others. In practice I do think Rust ends up being more portable than C in most practical scenarios -- for example, look at how things like `eza` work on Windows, the number one developer platform worldwide.
I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest.
https://nexte.st/docs/design/architecture/runner-loop/