[Panino]

I'm currently switching my Go code to Rust in part because of the syscall related Go trouble:

> Users of syscall(2), such as Perl and the Go programming language were converted to use the libc functions.

I think the following may still need to be converted:

  * unix.Pledge from golang.org/x/sys/unix
  * unix.Unveil from golang.org/x/sys/unix
  * terminal.ReadPassword from golang.org/x/crypto/ssh/terminal

[qweqwe14]

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.

[int_19h]

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

[akira2501]

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."

[int_19h]

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.

[pjmlp]

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.

[zokier]

> 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.

[LAC-Tech]

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?

[qweqwe14]

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

[Cloudef]

Zig's standard library does not use libc

[tedunangst]

They were converted months ago.

[ikmckenz]

Have you updated your packages with ‘pkg_add -u’?

[Panino]

Yes, I run -current so I update packages frequently.

After tedu's comment here I installed 7.5 in a VM and could build and run my Go software in it successfully, so I figured there were some Go build or config files or something somewhere getting in the way. I pkg_delete'd go, removed every Go build/config file I could find, and re-added Go with pkg_add. Now I can build apps with the previously mentioned modules; everything works fine now.

Thank you for the responses. :-)

[citizenpaul]

Forgive my ignorance but is this something limited to go on openbsd? Or is it a general isssue with go?