6 ms·
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
by NAHWheatCracker 1y ago
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 1y agoYou 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 1y agoThat sounds a lot like just using another language.
- silisili 1y agoIt'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 1y agoIf 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.