3 ms·
There's no guarantee of backwards compatibility without limiting of forward functionality. The trade-off can't be escaped. If you can make do without any persi
by barrkel 6y ago
There's no guarantee of backwards compatibility without limiting of forward functionality. The trade-off can't be escaped.
If you can make do without any persistent state, or global or externally visible resources (network connections, configuration files, etc.), then you're OK. But that's a limitation.
- roskilli 6y agoModules that rely on global state for anything other than memory pooling or what have you should be avoided. It’s a lot more testable and clean to return a high level data structure that contains any of that state you would have held before globally in the module and have that be the “context” or just the parent data structure to any others that are spawned. Global state makes thing impossible like parallel unit tests that all use another module, or changing things like “MaxConcurrency” in a way that is synchronized across goroutines that might already be calling into the third party module. My 2c.
- barrkel 6y agoOf course. I'm not advocating global state. It's just that most real systems have things like file systems, config files, databases, listening network sockets, etc. These are inherently non-local.