[NAHWheatCracker]

In some ways, yes. If you want to optimize at that level you ought to use another language.

I'm not a low level optimization guy, but I've had occasions where I wanted control over which threads my goroutines are running on or prioritizing important goroutines. It's a trade off for making things less complex, which is standard for Go.

I suppose there's always hope that the Go developers can change things.

[silisili]

You can kinda work around this though. runtime package has a LockOSThread that pins a goroutine to its current thread and prevents others from using it.

If you model it in a way where you have one goroutine per os thread that receives and does work, it gets you close. But in many cases that means rearching the entire code base, as it's not a style I typically reach for.

[naikrovek]

That sounds a lot like just using another language.

[silisili]

It's really not that bad. If you have a codebase in Go you can speed up, it's fine.

That said, if you're greenfielding and see this as a limitation to begin with, picking another language is probably the right way.

[jerf]

If you need it here or there, no. I've got a use case where I need a single locked thread for a particular syscall's functionality. It's not like it leaks out into the rest of the program and everything else has to change to accomodate it.

If you need it pervasively, Go may not be the correct choice. Then again, the list of languages that is not a correct choice in that case is quite long. That's a minority case. An important one, but a minority one.