3 ms·

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 fr

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