-1 to this idea from OpenBSD that all syscalls have to be routed through libc, requiring e.g. Golang to link to and run syscalls via libc.
Languages which are not C should not depend on C. A language design is much more compelling when its own compiler, runtime, stdlib, etc are self-hosting (i.e. written in the language itself). Constraining ourselves to a language design which can route all of its syscalls through the libc abstraction layer (which is THICK) constrains our language designs in ways I dislike.
@sir can we just create kernels and userspaces that aren't based in emulating 70s machines please
@espectalll that would be nice, but not yet
@sir also, ABI definitions shouldn't depend on C.
@Wolf480pl strong disagree with this one
@sir why tho?
@Wolf480pl the ABI isn't an abstraction as much as it's a language. System-V is the lingua franca of ABIs and the constraints it imposes are managable/desirable and necessary for dissonant modules to communicate. By constraining ourselves to the C ABI then we (1) discourage being too clever and (2) prevent the introduction of FFI layers with awkward idiomaticy transitions
@Wolf480pl or, in other words, constraining ourselves to the C ABI *simplifies* our systems, whereas routing all syscalls through libc adds complexity.
@sir I guess we meant different things by ABI.
I meant ABI as in "binary signature of this particular set of functions", while you meant sth like "a method to translate source-level signature of a function to binary calling protocol".
Like, when you describe a type of a function, one way to do it is to write its C signature, like:
which uses C-specific types eg size_t, or int, whose size can differ across machines, and can be different from the size of those types in the language from which you're calling this function from.
Alternatively, you could describe the function like this:
which is IMO less ambiguouss.
Of course you still need to know the calling convention - in which registers to pass arguments, etc.. In theory it'd be nice if we had a declarative syntax to describe that, too, but I agree that it's better if all functions use the same calling convention.
@Wolf480pl yeah, this is the wrong definition of an ABI. You mean the C type system
@Wolf480pl though note that you lose some semantics here: void* is deliberately an untyped pointer (cause malloc doesn't know what you're using it for - it might not be u8) and size_t is an architecture-specific size. u8 also isn't always necessarily the lowest common denominator - it's *probably* (but not definitely) the smallest possible addressable unit, but it's also likely to be too slow for some use-cases. Not to mention encoding concerns like pointer alignment and so on... there are reasons C is the way it is and they should be taken account if considering a different API design
@sir can't find your opinion on vlang. it is self hosted, but it also claims to have C as the backend https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-as-a-language-backend
@tho I can write this off straight away because you said it has a C backend
@sir but why? :( i thought you loved C
@tho I built you this house out of books instead of plywood. Why don't you like it? I thought you liked books!
@sir haha, okay
@sir I think, Mr DeVault, that this would be an appropriate time for you to create such a language to demonstrate :-)
@sir is it actually nailed to libc, or could another language register it's wrappers ? (Eg a flag on an elf section or attribute on an .so file?
@penguin42 I'm psure it's nailed to libc but you should research this question yourself
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!