Blog post: Portability matters
@sir I guess applications that have their own abstraction layer over all OS-specific code don't count, do they?
OTOH, if the abstraction layer is within a programming language's standard library (like with Java) it should count as portable, right?
> This is also why I question niche programming languages like Rust when they claim to be suited to systems programming or even kernel development. That’s simply not true when they only run on a small handful of operating systems and CPU architectures.
My understanding is that Rust runs on ~90 platforms. https://forge.rust-lang.org/platform-support.html How many platforms would you like to see it support before you'd say it supports more than a small handful?
(I agree that portability is important)
@codesections that number isn't quite right for kernel hacking. If you combine CPU families and operating systems, and eliminate emscription/wasm, you get 8 targets (or 9 if you consider the Nvidia target, and tbf I guess we should). Of those only a handlful are self hosting.
This is a lot better than when I wrote that article, but it's still peanuts compared to C. A new architecture can barely be considered to *exist* until it has a C compiler.
> This is a lot better than when I wrote that article, but it's still peanuts compared to C.
Oh, I didn't see the date on that post. For some reason, the toot showed up as new in my feed. That seems to have been happening occasionally lately; odd
@codesections someone boosted it
@sir oh, I missed that. Makes sense. Anyway, yeah, it seems like something that's getting better, slowly
(Goes without saying, I too think that portability is important.)
I think the difference is in who has to provide the support. If glibc/gcc do not support some platform/architecture, it's either the job of the platform to provide a working toolchain, or it'll be "platform Foo doesn't support proper C", not the other way around.
If libstd/rustc don't support some platform/architecture, then of course everyone (rightfully) blames Rust
Why do we still need to rely on a language dating back the beginnings oft computing? I mean I unterstand points against Rust but C basically(IMO) needs a small upgrade (like e.g. type safety and some other features).
Rusts targets just inherit from LLVM and are just as based on the Compiler as C is.
@nifker "Why do we still need to rely on a language dating back to the beginnings oft[sic] computing?"
(1) see article (2) old != bad (3) lots of people actually like C
Lisp, especially Scheme, is even simpler though 🤷
I also think it's weird that C is held up as the gold standard, even though there were many good programming languages created in the same time frame, just because it could piggyback on the popularity of Unix.
Now I'm not saying C is bad -- in fact, I would recommend everyone to learn C -- but there's other languages, some "more simple" and others "more complex" than C (how do you even quantify that?), that provide better safety and/or convenience than C. (Though I have to admit that "convenience" is no easier to define than "simplicity.)
There's also something to be said about languages that transpile to C that give you the same portability advantages that C gives you.
Also, I'm not saying that you or anyone else should use Rust, Lisp, Ada, or whatever. Use whatever you want. It's a bit silly to tell people what tool they should use, whether it's the Rust camp, the Go camp, the C camp, or any of the other language fanbois.
There's exceptions though. If you're writing code for avionics, medical equipment, cryptographic primitives, or similarly important code, don't use (unverified) C, don't use Rust; formal verification is great for those and I don't see a reason not to use them. I'd almost say that it's irresponsible not to use it.
PS: lol no generics 🙄
Depends. Low* produces good C code, but maybe that's cheating since you're essentially defining what code should be generated. But I think even Nim should be fine as long as it makes sure to only generate valid standard C. Whether the compiler has to make sure to only produce valid C or ASM shouldn't make a difference as long as you trust that the C compiler doesn't mess up.
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.