4 ms·
For the first time I've seen some seemingly valid criticism Go (thanks Marcan) and some good counter reasoning in the replies. To summarize, If I don't use CGO
by Abishek_Muthian 5y ago
For the first time I've seen some seemingly valid criticism Go (thanks Marcan) and some good counter reasoning in the replies.
To summarize, If I don't use CGO, Don't mind the increasingly large binary and run my Go production application only on Linux I wouldn't be facing the issues faced by Marcan?
- matheusmoreira 5y ago> If I don't use CGO Well, the vDSO bug Marcan described happened because the Go runtime itself was supposed to properly interoperate with a C library but didn't. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/vdso https://github.com/torvalds/linux/blob/master/Documentation/... > These functions are called just like ordinary C function according to your platform's ABI. > Call them from a sensible context. Go wasn't calling them from a sensible context. The functions didn't have enough stack space. Not sure if there are more ABI problems like that in the Go runtime. Probably not since the vDSO is Linux-specific and it's already been fixed. > run my Go production application only on Linux You should be fine. Linux system call binary interface is stable. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/syscalls https://github.com/torvalds/linux/blob/master/Documentation/... If Linux is all you're depending on then you're good.
- Abishek_Muthian 5y agoUnderstood, Thanks for being precise and succinct. > Not sure if there are more ABI problems like that in the Go runtime. Probably not since the vDSO is Linux-specific and it's already been fixed. Thanks to people like Marcan who put the effort in debugging and getting them fixed. Although it's a shame that the time-frame wasn't reasonable to Marcan and it seems to have influenced his decision to not indulge in such activities further.