Hacker News new | ask | show | jobs
by qweqwe14 808 days ago
Didn't Go already realize that it can't use direct syscalls on anything other than Linux? They made some mistakes in the past but by this point I think they learned their lesson.

On Linux, using direct syscalls is a good idea, since it's the stable userspace-kernel interface. There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.
3 comments
int_19h 808 days ago
They knew it all along, since it's well-documented. But they don't seem to care about it until they get burned. Which first happened on macOS, so that was switched; then OpenBSD.

This was previously discussed at length here: https://news.ycombinator.com/item?id=25999623

link
akira2501 807 days ago
Ironically the libc itself fails to document how large of a stack you should have before you call into it. Which is why go, having goroutines, tried to avoid it in the first place.

They didn't "get burned" they were "trying to provide a nice feature that wasn't as broadly compatible as they had hoped."

link
int_19h 806 days ago
When Go first shipped, it was already well-documented that the only stable ABI on some platforms was via dynamic libraries (such as libc) provided by said platforms. Go knowingly and deliberately ignored this on the assumption that they can get away with it. And then this happened:

https://github.com/golang/go/issues/16606

If that's not "getting burned", I don't know what is. "Trying to provide a nice feature" is an excuse, and it can be argued that it is a valid and justifiable one, but nevertheless they knew that they were using an unstable ABI that could be pulled out from under them at any moment, and decided that it's worth the risk. I don't see what that has to do with "not being as broadly compatible as they had hoped", since it was all known well in advance.

link
pjmlp 808 days ago
Like many other decisions, and as it happens with other technologies, reaching for it is a decision that outweights my preferences, given how it has managed to become unavoidable in many CNCF and DevOps products.
link
zokier 808 days ago
> There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.

Its not always not so clearcut. For example using pthreads instead of just calling clone can be useful for interop etc. Similarly, anything involving NSS is probably best done through libc. Having libc malloc integrated makes interacting with other C libs easier. And so on.

link
LAC-Tech 808 days ago
There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.

Rustix is a great implementation of that idea https://docs.rs/rustix/latest/rustix/

Any similar projects in other langs?

link
qweqwe14 807 days ago
It would be great for Rust to have a Linux target that doesn't use libc, but from what I've read, not many people are interested in this.

Found this as well: https://github.com/sunfishcode/mustang

Some discussion here: https://github.com/bytecodealliance/rustix/issues/76

link
Cloudef 808 days ago
Zig's standard library does not use libc
link