I see a lot of cool tools in the broadly defined dev space written in Rust. Best ad for Rust.
I also think newer languages benefit from the fact that CLI developer tooling is a great "hello world" type project to work on. Such projects solve a very real problem that someone starting out in that language wants to solve, while also often being simple enough problem to learn that language in.
For example for something written in go you might expect signals to be mishandled, colour escape codes when piping to another command, and non-GNU command line parsing.
It's not inherent to the language, but it's more about the fact that often people who write the libraries don't know about unix and the system calls they should be using.
In fact I don’t think your average developer should need to understand syscalls to write applications. That kind of stuff should be abstracted away. Plus if you want to write good applications for Linux/UNIX then that might mean using platform specific syscalls rather than sticking with POSIX, which would be a maintainability nightmare if it wasn’t already abstracted. Furthermore, some platforms, like macOS, don’t even guarantee binary compatibility for syscalls between releases. So you’re not even supposed to making syscalls directly in Darwin.
So with that in mind, application developers are usually encouraged to stick with their respective language runtime as the OS interface — and even then, a lot of language runtimes still just hook into libc rather than making syscalls directly themselves.
To come to your examples specifically, even in C you wouldn’t directly call ioctl on your fd to check if it’s a TTY. Instead you’d use isatty() in libc. (In case anyone doesn’t follow, this is to check if stdout is being piped or a tty, and thus whether to output or suppress human readable formatting like ANSI escape sequences).
Your point about GNU argument passing is also off. GNU is a convention and it’s only officially supported in GNU/Linux. You talk about understanding UNIX while referencing conventions that aren’t even anything to do with UNIX!
Lastly, I’m not sure why you singled out Go when there are a lot of advanced developer tools written in it, from pretty much everything by Hashicorp (Terraform, Vault, Consul, etc) through to Docker and Kubenetes. I don’t want to start a flame war about Go nor its developers, just saying it was yet another weird example in a comment already full of weird examples.
I'm not saying they should never use a wrapper and must use opcodes. I'm saying they should understand the difference between a function call and a system call.
> GNU is a convention and it’s only officially supported in GNU/Linux
Which is where 99.999% of go software runs, coincidentally.
> Lastly, I’m not sure why you singled out Go
Because the problems I listed usually happen to me only if the command is implemented in go. And since go in itself doesn't have any such limitations, it must be something with the libraries, and of course with people who write those libraries.