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 have
by bborud 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.
That being said, a good reason for using Go and its standard library is that they have been very good in terms of keeping important things in good shape and they put a lot more care into smoothing upgrades than is usually the case for random libraries. That's much of the motivation for using standard libraries: they have to be maintained in a manner that doesn't blow up billions of lines of running code. Third party libraries tend to be a far more mixed bag.
As for crypto: I shudder to think what it was like to use SSL/TLS in the C/C++/Java world. Horrific implementations that are fiddly to work with so you won't be inclined to mess with them more than you absolutely need to in regimens that rarely, if ever, pushes you to improve security as algorithm preferences shift over time. We've made heavy use of the crypto parts of Go to build our own PKI solution for an IOT platform and it was a lot easier than in any language we've used before. By a good margin.
I think you inadvertently made the argument for using Go and its standard library :-)
(Of course, 10 years down the road, perhaps people have abandoned Go and it has become a wasteland and there's some other language with a better stdlib you should be using. But ask yourself this: how much of the code you have written in the past is still running unchanged? You'll have to evolve, develop and adapt over time no matter what so if Go were to fade away, it isn't going to happen overnight and you'll have plenty of time to move on)
- 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.