3 ms·

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go develo

by cyphar 8y ago

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bitter taste in my mouth. Not to mention that Go was sold as a systems programming language, but my last 5 years of experience with the language (developing container runtimes -- which are the most canonical example of systems program you can come up with these days) tell me otherwise.

laumars 8y ago
Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application. However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.
- cyphar 8y ago
  From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment). The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).
euyyn 8y ago
Why do you think, from your experience, it is not a systems programming language?
- cyphar 8y ago
  You cannot write a single-threaded program in it (GOMAXPROCS doesn't do what you probably think it does), and the green threading until very recently didn't obey runtime.LockOSThread which meant that you couldn't even guarantee that a function would execute on the same logical thread (which is critical for certain syscalls). cgo (which is unfortunately necessary if you have C library dependencies) has significant issues like not being able to support union conversion to a Go type -- which means that you have to write helper functions in C and call those to access unions. This is part of a more generic problem that the memory safety model doesn't lend well to systems programming (and unsafe.* is just too scary to be usable everywhere). Oh, and the syscall package is effectively deprecated and you now have to switch everything to golang.org/x/sys/unix in order to use it properly (though one of the maintainers does nicely send PRs to projects often). This indicates to me that not enough people tested that the "syscall" package interface made sense in the 9 years before 1.0 and the stability guarantee set in (which means that the code which is very important for a systems programming language wasn't widely tested). If you want to (for instance) use AT_FDCMD with openat(2) you won't be able to because all of the syscall bindings require file descriptors to be a uint -- despite the kernel interface using an int (and the fact that AT_FDCMD is -100 or something like that). Yet they use AT_FDCMD internally -- which means they know it is needed but they elected not to expose this to users. It uses the "int" type for PIDs instead of using pid_t, for crying out loud. No systems programming language should do that.

by cyphar 8y ago

laumars 8y ago

Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application. However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.

cyphar 8y ago
From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment). The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).

euyyn 8y ago

Why do you think, from your experience, it is not a systems programming language?

cyphar 8y ago
You cannot write a single-threaded program in it (GOMAXPROCS doesn't do what you probably think it does), and the green threading until very recently didn't obey runtime.LockOSThread which meant that you couldn't even guarantee that a function would execute on the same logical thread (which is critical for certain syscalls). cgo (which is unfortunately necessary if you have C library dependencies) has significant issues like not being able to support union conversion to a Go type -- which means that you have to write helper functions in C and call those to access unions. This is part of a more generic problem that the memory safety model doesn't lend well to systems programming (and unsafe.* is just too scary to be usable everywhere). Oh, and the syscall package is effectively deprecated and you now have to switch everything to golang.org/x/sys/unix in order to use it properly (though one of the maintainers does nicely send PRs to projects often). This indicates to me that not enough people tested that the "syscall" package interface made sense in the 9 years before 1.0 and the stability guarantee set in (which means that the code which is very important for a systems programming language wasn't widely tested). If you want to (for instance) use AT_FDCMD with openat(2) you won't be able to because all of the syscall bindings require file descriptors to be a uint -- despite the kernel interface using an int (and the fact that AT_FDCMD is -100 or something like that). Yet they use AT_FDCMD internally -- which means they know it is needed but they elected not to expose this to users. It uses the "int" type for PIDs instead of using pid_t, for crying out loud. No systems programming language should do that.