@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?

@sir

> 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. forge.rust-lang.org/platform-s 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.

@sir

> 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

@sir oh, I missed that. Makes sense. Anyway, yeah, it seems like something that's getting better, slowly

@codesections @sir

(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

@codesections @sir see also: "Nvidia does not support Wayland" / "Wayland does not support Nvidia"

@sir
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

@xj9 @nifker @sir if C had vtables there would be literally no reason to use any other language.

@jeff

@sir @nifker @xj9 if you incrementally extended C to make writing efficient programs easy you'd end up with something a lot like C++ 😜

@xj9

@sir @jeff @nifker I'm not familiar with it, but it seems from a distance to be a perfectly reasonable language.

@AbbieNormal @xj9 @sir @nifker @RAOF you can extend C with literally any language that supports a FFI, which is everything except go and java.

@jeff @AbbieNormal @RAOF @nifker @xj9 Go has a spec. gccgo implements that spec. The implementation is not the language.

@xj9 @sir @nifker

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 🙄

@pyrolagus @xj9 @nifker

>There's also something to be said about languages that transpile to C that give you the same portability advantages that C gives you.

Yes: that they're bad. Adding an extra, inscrutable, undebuggable layer of indirection? Hard pass from me. This is why I don't like Nim.

@sir @xj9 @nifker

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.

@nifker @sir I've seen a couple of "safety C" variants over the years but none of them really caught on, possibly mostly due to being little known.

Wish I could remember their names :think_unamused:

Sign in to participate in the conversation
Mastodon

cmpwn.com is a private Mastodon instance for friends of SirCmpwn.