3 ms·

Seeing as the prime (and arguably only essential ^1) use cases for C are 1. O/S kernels and drivers, 2. embedded code for tiny microcontrollers, 3. language int

Seeing as the prime (and arguably only essential ^1) use cases for C are 1. O/S kernels and drivers, 2. embedded code for tiny microcontrollers, 3. language interpreters/runtimes and JITters, 4. bootstrap compilers, 5. portable command-line utilities, 6. low-level/mixed asm routines for performance, and 7. the large body of legacy apps of course, are there any examples for successful implementations for these categories in Rust? I'd imagine developing a nontrivial language runtime using Rust's memory model could be hard or impossible to do performantly. But that is or was the mainstay of C programming on Unix - implementing higher-level languages such as shell or awk. ^1: This is of course opinionated, but my reasoning for not including application code, and in particular long-lived evented or multithreaded app servers is that I personally think these are beyond C's memory management capabilities (even if you get malloc/free 100% right, there's still the problem of memory fragmentation) and are basically erratic outcomes of 1990's multithreading code originating from corouting in GUI programs

steveklabnik 7y ago
> are there any examples for successful implementations for these categories in Rust? Depends on how you define "successful", I'll toss some things in. This won't be comprehensive. 1. O/S kernels and drivers, Amazon has multiple projects in this space: Firecracker, Bottlerocket. So does Google: ChromeOS, Fuchsia. Kernel maintainers have said that they would accept non-essential drivers in Rust, but they want some examples first. 2. embedded code for tiny microcontrollers, Tons of stuff here. Multiple RTOSes like Tock and RTFM. Lots of little projects. One of the first Rust-only consultancies does a lot of embedded contracts. 3. language interpreters/runtimes and JITters, Most of the languages that have existed are bigger than toys, but don't have large user bases. Gluon and Dyon are two examples. JITs exist but aren't really "production", Cranelift has a JIT for example. 4. bootstrap compilers, rustc is written in Rust (it does use LLVM though) 5. portable command-line utilities, Tons and tons and tons. ripgrep is the most famous. On the "portable" end, I'm a Windows user, and most things I try Just Work, though they may print out funny paths sometimes. (if you escape a native\windows\path you'll get a native\\windows\\path since \ ends up getting escaped. Only a display issue though, things still work just fine.) 6. low-level/mixed asm routines for performance, This isn't "for performance" but I like https://crates.io/crates/x86 https://crates.io/crates/x86 as an example here. Inline asm isn't stable yet, but we're getting pretty close, it seems. 7. and the large body of legacy apps of course, It's not clear to me what this actually means.
- swsieber 7y ago
  Add to #1 Redox.
joppy 7y ago
Don’t C++ and Rust still have the memory fragmentation issue, since they have to use an allocator at some point?
- tannhaeuser 7y ago
  Exactly. That's why I don't think close-to-metal languages are the way to go for most apps (as in "C is not a general-purpose language"), except the ones I listed, and probably some. I admire the Rust community's energy and persistence to create a new zero-overhead language, but, for me at least, they're ultimately falling victim to the idea that an app must be a single giant monolithic binary. C and Unix grew strong because of small little composable programs, where each program's memory was manageable enough in a way multithreaded, let alone async/evented server-like programs aren't (if they need dynamic memory at all). But ever since idk Java app servers? people have this idea that they're better at memory management than the kernel + MMU when that isn't clearly demontrated at all considering that eg. GC overhead isn't insignificant in long-running programs. What I'd rather like to see is bringing down process spawning overhead (response latency), or at least a rational discussion backed by benchmarks why everybody (except unikernel folks) blindly follows the big fat app server idea when, from the outset, a process-per-request model with memory/permission/resource isolation clearly looks much saner given service-oriented workloads and troubles in recent years (eg side-channel attacks, DOSing, leaks).
- deleted 7y ago
  [deleted]

steveklabnik 7y ago

> are there any examples for successful implementations for these categories in Rust? Depends on how you define "successful", I'll toss some things in. This won't be comprehensive. 1. O/S kernels and drivers, Amazon has multiple projects in this space: Firecracker, Bottlerocket. So does Google: ChromeOS, Fuchsia. Kernel maintainers have said that they would accept non-essential drivers in Rust, but they want some examples first. 2. embedded code for tiny microcontrollers, Tons of stuff here. Multiple RTOSes like Tock and RTFM. Lots of little projects. One of the first Rust-only consultancies does a lot of embedded contracts. 3. language interpreters/runtimes and JITters, Most of the languages that have existed are bigger than toys, but don't have large user bases. Gluon and Dyon are two examples. JITs exist but aren't really "production", Cranelift has a JIT for example. 4. bootstrap compilers, rustc is written in Rust (it does use LLVM though) 5. portable command-line utilities, Tons and tons and tons. ripgrep is the most famous. On the "portable" end, I'm a Windows user, and most things I try Just Work, though they may print out funny paths sometimes. (if you escape a native\windows\path you'll get a native\\windows\\path since \ ends up getting escaped. Only a display issue though, things still work just fine.) 6. low-level/mixed asm routines for performance, This isn't "for performance" but I like https://crates.io/crates/x86 https://crates.io/crates/x86 as an example here. Inline asm isn't stable yet, but we're getting pretty close, it seems. 7. and the large body of legacy apps of course, It's not clear to me what this actually means.

swsieber 7y ago
Add to #1 Redox.

joppy 7y ago

Don’t C++ and Rust still have the memory fragmentation issue, since they have to use an allocator at some point?

tannhaeuser 7y ago
Exactly. That's why I don't think close-to-metal languages are the way to go for most apps (as in "C is not a general-purpose language"), except the ones I listed, and probably some. I admire the Rust community's energy and persistence to create a new zero-overhead language, but, for me at least, they're ultimately falling victim to the idea that an app must be a single giant monolithic binary. C and Unix grew strong because of small little composable programs, where each program's memory was manageable enough in a way multithreaded, let alone async/evented server-like programs aren't (if they need dynamic memory at all). But ever since idk Java app servers? people have this idea that they're better at memory management than the kernel + MMU when that isn't clearly demontrated at all considering that eg. GC overhead isn't insignificant in long-running programs. What I'd rather like to see is bringing down process spawning overhead (response latency), or at least a rational discussion backed by benchmarks why everybody (except unikernel folks) blindly follows the big fat app server idea when, from the outset, a process-per-request model with memory/permission/resource isolation clearly looks much saner given service-oriented workloads and troubles in recent years (eg side-channel attacks, DOSing, leaks).
deleted 7y ago
[deleted]