>But, for systems programming, abstractions suck.
Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.
Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.
The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel.
Systems programming just means you're working below the application layer. So if you take your laptop and write a device driver, or work on filesystem or networking code, you're doing systems programming without doing embedded.
That's a good point though. A lot of people mean different things by systems programming.
Actually, no. It meant one thing until Go proponents tried to market their language and realized that their target audience didn't actually care.
I'd also s/didn't actually care/got confused/ in your last sentence too.