Comment by masklinn
2 years ago
> It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.
Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems.
But as usual, go is uniquely american, only doing the right thing after it has tried everything else.
You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?
> You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI)
No, you could not.
On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc.
And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.
It's not about hardcoding, it's about the fact that libc isn't even an ABI, really. It's a C source API, which compiles down to a secret ABI that you can't know (you just have to expand all the macros and see what you get). That's sort of OK if every compiled program in the world is written in C, but as soon as you want to start writing in another language it kind of falls apart.
On linux the stable API and ABI that you are supposed to use is also just libc. But due to various reasons people think that the libc ABI is less stable than how stable it really is.
Edit: NT with its split OS API dll and separate libc is its own can of worms. You can have multiple instances of libc in the same address space, which among other things implies that you cannot safely malloc() in one module and free() in another, and don't even think about passing FILE* around.
1 reply →
My point is that libc as the only system API is not a sane choice, and appeals to tradition don't make it less insane.
1 reply →
> go is uniquely american, doing the right thing after it has tried everything else.
That doesn't seem like anything common to an American way of doing things. What an odd statement.
It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
Bizarre nationalistic "they're doing it because they're Americans" rantings are still not okay even if they're a "play on a quote". I can "play" with all sorts of quotes to say all sorts of idiotic things.
1 reply →
I don't use Go, but I had the exact same reaction; C is the source of most of the problems and this is just codifies the use of C. The whole thing has a security by obscurity smell.
Your comment seems to conflate a language with an ABI. To what end? What is inherently insecure about the C ABI? Why is using a syscall interface any more secure?
I'm not conflating anything. Why do you need to burden a language with a C ABI when you can just invoke the language independent mechanism directly?
2 replies →
> go is uniquely american, only doing the right thing after it has tried everything else.
Perhaps this is why most innovations are American. We don't automatically fall for the bully pulpit of the gnostic class.
> Something they wouldn't have to do
Yea, but they'll get it done anyways, and the language will continue to be excellent. I'm sure Google can absorb the engineering challenge without subtracting anything from us or other languages.