3 ms·
> I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you ha
by everforward 3y ago
> I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges.
I think you're misunderstanding OP's theoretical. If TLS is in the stdlib, that means its version is tied to the version of the language you're using. I.e. if you want to upgrade to a newer TLS, you need to upgrade your entire language version (compiler, interpreter, whatever).
So you can end up in a spot where you need to go from v1 of a language to v2 to get a modern TLS implementation. However if v2 of the language also contains changes to how the language handles threading, you now need to rewrite your app's threading to be compatible with v2 of the language, just so you can get a safe TLS implementation.
Basically because TLS is in the stdlib, TLS can force you to upgrade your language version.
If TLS was 3rd party, you could upgrade the library without upgrading your language version (presuming the TLS library supports your language version).
- bborud 3y agoI understand the argument. Fortunately, Go makes a lot of promises that makes this scenario unlikely. So in real life this becomes mostly a theoretical issue. It could happen. It just isn’t terribly likely. And if it does happen, it is likely a lot of other people will find themselves in the same boat, making a practical solution emerging more likely. And note: the same thing could happen, and is more likely to happen, if you use a third party library. Some of the libraries I’ve used for years are no longer actively maintained, for instance.