> A systems programming language cannot afford to silo itself on a single OS solutions.
If a OS (or alleged OS) demands that you dynamically link against libc (or anything else written in C) to interact with it, that problem is not the (non-C) programming language's fault.
> your rant barely scratches the surface of the [OS] options available
That's fair, but most of the not-linux I have experience with is microcontrollers or other things that are far enough from unix/posix that they don't have dlopen (mmap itself is hit-or-miss, but tends to be hit in the sorts of situations where I'd have occasion to dynamically load stuff in the first place), so there's not much I could do about that.
If a OS (or alleged OS) demands that you dynamically link against libc (or anything else written in C) to interact with it, that problem is not the (non-C) programming language's fault.
> your rant barely scratches the surface of the [OS] options available
That's fair, but most of the not-linux I have experience with is microcontrollers or other things that are far enough from unix/posix that they don't have dlopen (mmap itself is hit-or-miss, but tends to be hit in the sorts of situations where I'd have occasion to dynamically load stuff in the first place), so there's not much I could do about that.