Hacker News Reader

Comment by salmo | Hacker News Reader

I think the issue with the footprint here is not wanting to reinvent wheels.

In theory, if you scrapped libc and up, you could limit your "speaking C" to the kernel of whatever OS/architecture you're using. Different OS/architecture combos would be more of a nightmare than others, but we cheat off libc for that , except we have to do things to support multiple libc implementations some times.

It doesn't solve interop with other languages, because they don't want to reinvent wheels either.

In theory, you could scrap it all and go hardware up. Have a nice OS with a well defined message passing interface that any language could interact with. You could even make a libc wrapper on top to address portability. In 20 years, it may have serious adoption.

The problem is that the situation is "good enough" that nobody wants to solve it. That applies to most technical debt, and really any other human concern.

View on HN

That message passing comes with a lot of overhead while it might be more generic. Making the already bloated software we use these days even slower does not sound like a better alternative.

That would make interacting with OS slower, and probably even more important are things like .DLLs/.SOs. If the dynamic library or heck even a static library your linking against used message passing imagine all the cases where that would be a bad idea. All that overhead just so you can call a function not written in whatever language you happen to be using. ABI's like we have now are a much better for this reason. Also just because one uses message passing does not mean there are no compatibility issues.

I think the main issue here is if we reference the article linked. "You Can’t Actually Parse A C Header". To know the size of types and therefore figure out memory layout you need to be able to read a C header. With that information you can construct a lot the ABI for a C function. Aside from some OS specific things like stack layout requirements and hardware/OS specific things like what registers are used for certain parameters of a function ect...

Sorry, I don't disagree at all and the message passing was a little tongue in cheek. I was in CS in the 90s, when the dream of a message passing microkernel utopia was so hot.

I don't see a way around this complaint other than starting from scratch. If you "fixed" C, you'd have to rebuild all those things underneath you. And the reason we do FFI is to not reinvent some chunk of code.

I think you fundamentally run into issues with ABI compatibility regardless of language. You get a step better if you could derive the ABI from the code, but there's always interop issues cross-language. I don't think you can avoid wandering into having to implement the isms of the provider's language.

So much baggage just comes from strings. Then you have higher level constructs like making threading/concurrency, memory management, etc. jive. That's even an issue at the API level. I use a ton of libraries that just wrap a C library with a language-idiomatic interface.

Reply on news.ycombinator.com