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