8 ms·

My response to the plea in this article is simply "No thanks." If Go gets that bad, I'd be happy to use an ungoogled fork of it, or migrate to another toolchain

by jchw 4y ago

My response to the plea in this article is simply "No thanks." If Go gets that bad, I'd be happy to use an ungoogled fork of it, or migrate to another toolchain or language, or whatever needs to happen. But until then, I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. I want production quality toolchain and runtimes. That's hard. Go has a high quality library of cryptographic functions. Hard. Go has a fast usermode thread scheduler with preemption on many platforms. Hard. Go has an incredibly low latency GC that doesn't need much tuning for most workloads. Very hard. Some of those hard solutions are self-inflicted by the choices made in the language, but the fact that they are solved so well is what makes it valuable. A mediocre implementation of Go would have less value. A mediocre implementation of a random language with a tiny ecosystem by comparison would be even harder of a sell. I am by no means trying to say that Nim is low quality or not interesting for anyone. In fact, I actually think Nim is cool. It is not the only other smaller programming language I like. I have a strong affection for Zig as well. There are unique properties that make these languages desirable. Zig comptime is really cool for example. I like stuff like this. But: I also think Go is a great piece of production-quality software. I know many people hate the language now, especially now that the honeymoon has thoroughly ended. But I still like it. I feel highly productive in it, the ecosystem is good, and at the end of the day, I know I can make reliable and fast software in it. Corporate control is a shame, but the truth is that corporate control is not the problem at all. The problem is funding. Because anyone can fork Go, but can you pay maintainers? Can you run the CI, the website and playground, host the CDN with the downloads? Etc. Sometimes the answer is yes, especially with how much GitHub subsidizes a lot of those things, but in general the answer is no. "Corporate control" is not the problem itself. Governance is just an outwardly visible consequence. The true control comes from maintainership and stewardship. Because if nobody is stepping up to the plate to take that role, then whoever is doing it today effectively has control over the project.

goodpoint 4y ago
Corporate control is very much a problem. A big one.
Tozen 4y ago
Based on the article, the person appears to be also talking about privacy, security, and freedom. Where the corporate tools can unexpectedly and stealthily be phoning home or the direction they go in are corporate controlled too much. This is less of an issue with truly/more so free and open source tools like Nim, Vlang, Free Pascal, Odin, Dlang, etc... They don't have the same kinds or levels of corporate gotchas attached to them. They are more "tools of the people". In various languages, corporations are more akin to users and donors, than they are dictating the direction and forcing their way, despite what the majority of users may want.
mattgreenrocks 4y ago
Maybe we should be investing more time into creating meta-platforms so that we don't need millions of dollars to bootstrap production-ready languages.
- shadowgovt 4y ago
  I don't think it's a platform problem... It's a money problem. I've got a toy language I've built at home for my own reasons. Lots of developers do. The difference (especially in these modern times) between my toy and Rob Pike's toy is that Rob is paid by Google to develop it, hammer out the details, work out the bugs, and support it. As are the whole team Google dedicated to it. Some languages get supported by volunteer armies (Lua comes to mind, last I checked), but TypeScript, Go, and Rust are supported / maintained by corporate money and it's hard to compete with that because a corporation can throw money at a language that isn't done yet while it's harder to get volunteers excited about a broken toolset.
  - nandalism 4y ago
    I constantly hear that "we can't do it without corporations" and yet there are so many counter examples. Most of the corporations were built on free languages and ecosystems which existed before they did.
    - deleted 4y ago
      [deleted]
    - mattgreenrocks 4y ago
      There's been a shift away from vague distrust of corporations (think Slashdot) to full-on embrace. The fallout from that is we can't imagine platforms that don't require tens of millions of dollars to bootstrap, and we cling to the ones we have because they're so expensive. Too big to fail is not the hacker ideology I grew up with. Maybe that's gone now.
      - shadowgovt 4y ago
bob1029 4y ago
> I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything. The more developers who give me grief on some principled basis that "<megacorp> bad, so everything related is bad", the more I double-down on my position. These non-technical arguments are read as desperation and incompetence from my perspective in 2023.
- stcroixx 4y ago
  In the late 90's I used to sit next to a team of about 20 VB developers. When MS decided to make VB obsolete, those folks had to re-learn software development and were getting intern like opportunities because suddenly all that VB knowledge and experience was worth exactly zero. Hopefully y'all fare better when they decide to nuke C# and .NET.
  - deleted 4y ago
    [deleted]
  - fexecve 4y ago
    I was there in those days too. VB was a very beginner-friendly language, more akin to what we call today "low-code" than other languages. Those developers didn't have to "re" learn software development, as you think, instead they probably never knew software development well enough to use languages like VB.NET (which is what all of the VB devs I worked with ended up on). "C# and .NET" is equal to any language you can think of in terms of complexity, so C# devs are going to be just fine.
  - tclancy 4y ago
    I'm not totally sure what that means. VB and the change to .NET are kind of a one-off event. A "VB developer" could mean anything from someone writing VB/ ASP in a text editor with minimal syntax highlighting to someone using a drag and drop editor and never writing code to someone who was really just writing fancy Excel macros. If you want to suggest some of the people working in a GUI only had trouble making the transition, I suppose it's possible, but .NET offered VB.net and VisualStudio still had drag-and-drop editors. So why would they need to be interns? Because people started organizing code differently in folders and linking DLLs?
cbushko 4y ago
The same goes for huge open source projects like Kubernetes. The amount of money to run the infrastructure for CI/CD and CDN is in the millions per year. Someone has to pay for that and the big companies are the ones that fit the bill. Google mostly pays for it but others have started contributing also. For example, Amazon recently announced that they are funding part of the infrastructure also.
- theteapot 4y ago
  How much does AWS make from just EKS? Tossing some change to support k8s ecosystem seem like a pretty good investment.
- mypalmike 4y ago
  *foot the bill
  - a_JIT_pie 4y ago
    *fit the bill - https://dictionary.cambridge.org/us/dictionary/english/fit-the-bill https://dictionary.cambridge.org/us/dictionary/english/fit-t...
    - moloch-hai 4y ago
      No. Foot is right, meaning "pay". "Fit the bill" is also used, but not in this context.
      - a_JIT_pie 4y ago
        Yes. _Fit_ is right, specifically in this context. Re-read the comment you're talking about. In fact, either work fine. I'm taking issue with the pedantry we're engaging in here (while admittedly adding to it).
        mypalmike 4y ago
        The context was clearly about payments. So it's foot. It's not particularly ambiguous even. I don't correct people to be pedantic or argumentative. I love being corrected and learning from others, but I suppose not everyone does.
nandalism 4y ago
As I said I love golang. I invested a lot of my own time into learning it and its ecosystem. The time developers spend learning a language and its libraries should not be discounted. Maybe we overestimate how much corporate backing is required to make a language a success. After all we had successful languages and ecosystems long before any corporations became interested in funding such things. You mention golang's crypto. Is it true that all that code is native to the go project or are they mostly just wrapping other open source libraries which have been created by 3rd parties? Any open source language could do the same without massive investment (many have).
- vluft 4y ago
  go's crypto is all original to go (other than possibly some assembly implementations ported from other projects), and nearly uniformly excellent. I would take the go TLS implementation over, say, openssl (which is what many/most other languages end up using) any day of the week.
- hgsgm 4y ago
  Name a popular language without corporate backing. C was corporate, AT&T. C++ was corporate, AT&T. Java was corporate, Sun. Maybe Perl wasn't corporate. Had a great run but faded. Python? Maybe, but Guido van Rossum worked at Google and Dropbox for many years. Ruby? Is popular because Rails, corporate. JavaScript? Mozilla.
  - goodpoint 4y ago
    Very much Python.
  - robryan 4y ago
    PHP? You could argue Facebook but they mostly went and built their own thing that at best was inspiration of later PHP versions. As far as I know currently the only real paid full time contributors are from the relatively newly formed PHP foundation.
  - stonemetal12 4y ago
    Lisp, and OCaml are about as close as I can get. I would argue Haskell (several of GHC's core team worked at MS though). I would also argue Python was popular before Guido worked at Google. Those 4 all came out of academia though so they had backing just not corporate backing.
tpoacher 4y ago
Replace "Go" with "Internet Explorer", and see how that reads: "My response to the plea in this article is simply "No thanks." If Internet Explorer gets that bad, I'd be happy to use "works best on internet explorer" banners, or migrate to another browser, or whatever needs to happen. But until then, I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. I want production quality websites and animations. That's hard. Internet Explorer has a high quality library of windows-specific functions. Hard. Internet Explorer has a fast browser which leverages windows-specific optimisations great. Hard. Internet Explorer has an incredibly liberal interpretation of web standards, making other browsers break 99% of the time, affecting most of my target users. Very hard. Some of those hard solutions are self-inflicted by the choices made in the browser, but the fact that they are so ubiquitous and integrated with the microsoft ecosystem so well is what makes it valuable. If the web standards are missing the many lovely MS-specific extensions of Internet Explorer, a more standards compliant browser would have less value. A standards compliant browser with a tiny user base by comparison would be even harder of a sell. I am by no means trying to say that Netscape is low quality or not interesting for anyone. In fact, I actually think Netscape is cool. It is not the only other smaller browser I like. I have a strong affection for Opera as well. There are unique properties that make these browsers desirable. Netscape addons are really cool for example. I like stuff like this. But: I also think Internet Explorer is a great piece of production-quality software. I know many people hate the browser now, especially now that the honeymoon has thoroughly ended. But I still like it. I feel highly creative in it, the ecosystem is good, and at the end of the day, I know I can make reliable, flashy websites in it. Corporate control is a shame, but the truth is that corporate control is not the problem at all. The problem is funding. Because anyone can try to deviate from web standards and implement windows-specific extension hacks in other browsers, but can you pay maintainers? Can you run the CI, the website and playground, host the CDN with the downloads? Etc. Sometimes the answer is yes, especially with how much SourceForge supports a lot of those things, but in general the answer is no. "Corporate control" is not the problem itself. Governance is just an outwardly visible consequence. The true control comes from maintainership and stewardship. Because if nobody is stepping up to the plate to take that role of introducing microsoft hacks in browsers, then whoever is doing it today effectively has control over the internet."
elcritch 4y ago
One small note, but Nim's comptime support is on par with Zig's. It's preferred using comptime and templates over macros when possible. Here's an example (1) of a compile time object to key value layer I did without macros. It's a basic wrapper to split an object's fields into separate key-value pairs for storage. The problem is that the storage system only has 16bit ints for keys which makes collision a large possibility. So this wrapper checks at compile time that there aren't duplicate keys. 1: https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/extras/nvsConfigObj.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/e...
KennyBlanken 4y ago
You're speaking about issues with corporate control in Go like it's some sort of theoretical thing. It's not. It's been here for ~5 years. Those "high quality library of cryptographic functions" you mentioned? Well, thanks to one Google employee, it is impossible in those "high quality" cryptographic functions to, say, disable in any way specific algorithms...except by modifying Go's source and recompiling it. This is (and I wish I were making this up) because said employee has decreed that TLS/1.3 and all the algorithms in it are the best thing since sliced bread (guess who was on the committee working on the TLS 1.3 spec!) and it couldn't possibly be insecure. Because, you know, history is not rife with examples of cryptographic functions (and perhaps more frequently, their implementations) being discovered to be vulnerable (in some cases, purposefully so thanks to NSA subterfuge.) Further, they stated that even if it were discovered to be insecure? Well, Google will just either fix it or disable the insecure part, and release an update, and if you can't apply that update in a timely fashion, you have "bigger problems": > Finally, about (removed) third point: if a security issue were to be found, we would publish a small security patch for all supported releases, like any other security vulnerability. A deployment that can't apply those timely has a bigger problem and won't be saved by TLS cipher suite configurability. Because when you wake up in the morning to a TLS/1.3 vulnerability reported in The Reg and go "oh shit", it's clearly not faster to push a configuration file change or change a bit of your own code to immediately disable the affected algorithm...than it is to wait for the mitigation to make its way through Golang's release process, get picked up by the distro you use and wind its way through that release process...all the while you're vulerable, and have been for weeks or months because Google bribes people to keep their mouths shut via the bug bounty program and/or 'responsible disclosure' policies. Because production environments always have the ability to push out new versions of a core package. Because it's never easier to push out a configuration or code change, both technically and administratively (ie change control.) Because it's not often easier to validate and if necessary roll back a configuration or code change versus a package change. Because clearly every organization that uses Golang as part of its infrastructure has the technical know-how and infrastructure to grab Go source code, modify it to disable a crypto algorithm, compile it, and package/distribute it. Because there's never a delay between when a vulnerability is discovered by blackhats, discovered by whitehats, reported to the project, mitigation makes it to release, the distro's package maintainer gets around to creating/modifying/applying the patch to whatever version they're actually still distributing, testing that / getting it signed off on, and pushed to update channels. So, there you have it. One ivory-tower asshole who has probably rarely worked on an infrastructure team, who does not seem aware of, much less care, about the potential consequences caused by his decision...for people who are not part of the same organization that maintains the programming language. I'm sure that if you work at Google and a problem with TLS/1.3 or Golang's implementation of it are discovered and reported to Google, you can count on that fix being made and deployed across Google's infrastructure almost instantaneously. The rest of us, it seems, can get fucked and be vulnerable for days or longer.

by jchw 4y ago

goodpoint 4y ago

Corporate control is very much a problem. A big one.

Tozen 4y ago

Based on the article, the person appears to be also talking about privacy, security, and freedom. Where the corporate tools can unexpectedly and stealthily be phoning home or the direction they go in are corporate controlled too much. This is less of an issue with truly/more so free and open source tools like Nim, Vlang, Free Pascal, Odin, Dlang, etc... They don't have the same kinds or levels of corporate gotchas attached to them. They are more "tools of the people". In various languages, corporations are more akin to users and donors, than they are dictating the direction and forcing their way, despite what the majority of users may want.

mattgreenrocks 4y ago

Maybe we should be investing more time into creating meta-platforms so that we don't need millions of dollars to bootstrap production-ready languages.

shadowgovt 4y ago
I don't think it's a platform problem... It's a money problem. I've got a toy language I've built at home for my own reasons. Lots of developers do. The difference (especially in these modern times) between my toy and Rob Pike's toy is that Rob is paid by Google to develop it, hammer out the details, work out the bugs, and support it. As are the whole team Google dedicated to it. Some languages get supported by volunteer armies (Lua comes to mind, last I checked), but TypeScript, Go, and Rust are supported / maintained by corporate money and it's hard to compete with that because a corporation can throw money at a language that isn't done yet while it's harder to get volunteers excited about a broken toolset.
- nandalism 4y ago
  I constantly hear that "we can't do it without corporations" and yet there are so many counter examples. Most of the corporations were built on free languages and ecosystems which existed before they did.
  - deleted 4y ago
    [deleted]
  - mattgreenrocks 4y ago
    There's been a shift away from vague distrust of corporations (think Slashdot) to full-on embrace. The fallout from that is we can't imagine platforms that don't require tens of millions of dollars to bootstrap, and we cling to the ones we have because they're so expensive. Too big to fail is not the hacker ideology I grew up with. Maybe that's gone now.
    - shadowgovt 4y ago

bob1029 4y ago

> I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything. The more developers who give me grief on some principled basis that "<megacorp> bad, so everything related is bad", the more I double-down on my position. These non-technical arguments are read as desperation and incompetence from my perspective in 2023.

stcroixx 4y ago
In the late 90's I used to sit next to a team of about 20 VB developers. When MS decided to make VB obsolete, those folks had to re-learn software development and were getting intern like opportunities because suddenly all that VB knowledge and experience was worth exactly zero. Hopefully y'all fare better when they decide to nuke C# and .NET.
- deleted 4y ago
  [deleted]
- fexecve 4y ago
  I was there in those days too. VB was a very beginner-friendly language, more akin to what we call today "low-code" than other languages. Those developers didn't have to "re" learn software development, as you think, instead they probably never knew software development well enough to use languages like VB.NET (which is what all of the VB devs I worked with ended up on). "C# and .NET" is equal to any language you can think of in terms of complexity, so C# devs are going to be just fine.
- tclancy 4y ago
  I'm not totally sure what that means. VB and the change to .NET are kind of a one-off event. A "VB developer" could mean anything from someone writing VB/ ASP in a text editor with minimal syntax highlighting to someone using a drag and drop editor and never writing code to someone who was really just writing fancy Excel macros. If you want to suggest some of the people working in a GUI only had trouble making the transition, I suppose it's possible, but .NET offered VB.net and VisualStudio still had drag-and-drop editors. So why would they need to be interns? Because people started organizing code differently in folders and linking DLLs?

cbushko 4y ago

The same goes for huge open source projects like Kubernetes. The amount of money to run the infrastructure for CI/CD and CDN is in the millions per year. Someone has to pay for that and the big companies are the ones that fit the bill. Google mostly pays for it but others have started contributing also. For example, Amazon recently announced that they are funding part of the infrastructure also.

theteapot 4y ago
How much does AWS make from just EKS? Tossing some change to support k8s ecosystem seem like a pretty good investment.
mypalmike 4y ago
*foot the bill
- a_JIT_pie 4y ago
  *fit the bill - https://dictionary.cambridge.org/us/dictionary/english/fit-the-bill https://dictionary.cambridge.org/us/dictionary/english/fit-t...
  - moloch-hai 4y ago
    No. Foot is right, meaning "pay". "Fit the bill" is also used, but not in this context.
    - a_JIT_pie 4y ago
      Yes. _Fit_ is right, specifically in this context. Re-read the comment you're talking about. In fact, either work fine. I'm taking issue with the pedantry we're engaging in here (while admittedly adding to it).
      - mypalmike 4y ago
        The context was clearly about payments. So it's foot. It's not particularly ambiguous even. I don't correct people to be pedantic or argumentative. I love being corrected and learning from others, but I suppose not everyone does.

nandalism 4y ago

As I said I love golang. I invested a lot of my own time into learning it and its ecosystem. The time developers spend learning a language and its libraries should not be discounted. Maybe we overestimate how much corporate backing is required to make a language a success. After all we had successful languages and ecosystems long before any corporations became interested in funding such things. You mention golang's crypto. Is it true that all that code is native to the go project or are they mostly just wrapping other open source libraries which have been created by 3rd parties? Any open source language could do the same without massive investment (many have).

vluft 4y ago
go's crypto is all original to go (other than possibly some assembly implementations ported from other projects), and nearly uniformly excellent. I would take the go TLS implementation over, say, openssl (which is what many/most other languages end up using) any day of the week.
hgsgm 4y ago
Name a popular language without corporate backing. C was corporate, AT&T. C++ was corporate, AT&T. Java was corporate, Sun. Maybe Perl wasn't corporate. Had a great run but faded. Python? Maybe, but Guido van Rossum worked at Google and Dropbox for many years. Ruby? Is popular because Rails, corporate. JavaScript? Mozilla.
- goodpoint 4y ago
  Very much Python.
- robryan 4y ago
  PHP? You could argue Facebook but they mostly went and built their own thing that at best was inspiration of later PHP versions. As far as I know currently the only real paid full time contributors are from the relatively newly formed PHP foundation.
- stonemetal12 4y ago
  Lisp, and OCaml are about as close as I can get. I would argue Haskell (several of GHC's core team worked at MS though). I would also argue Python was popular before Guido worked at Google. Those 4 all came out of academia though so they had backing just not corporate backing.

tpoacher 4y ago

Replace "Go" with "Internet Explorer", and see how that reads: "My response to the plea in this article is simply "No thanks." If Internet Explorer gets that bad, I'd be happy to use "works best on internet explorer" banners, or migrate to another browser, or whatever needs to happen. But until then, I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. I want production quality websites and animations. That's hard. Internet Explorer has a high quality library of windows-specific functions. Hard. Internet Explorer has a fast browser which leverages windows-specific optimisations great. Hard. Internet Explorer has an incredibly liberal interpretation of web standards, making other browsers break 99% of the time, affecting most of my target users. Very hard. Some of those hard solutions are self-inflicted by the choices made in the browser, but the fact that they are so ubiquitous and integrated with the microsoft ecosystem so well is what makes it valuable. If the web standards are missing the many lovely MS-specific extensions of Internet Explorer, a more standards compliant browser would have less value. A standards compliant browser with a tiny user base by comparison would be even harder of a sell. I am by no means trying to say that Netscape is low quality or not interesting for anyone. In fact, I actually think Netscape is cool. It is not the only other smaller browser I like. I have a strong affection for Opera as well. There are unique properties that make these browsers desirable. Netscape addons are really cool for example. I like stuff like this. But: I also think Internet Explorer is a great piece of production-quality software. I know many people hate the browser now, especially now that the honeymoon has thoroughly ended. But I still like it. I feel highly creative in it, the ecosystem is good, and at the end of the day, I know I can make reliable, flashy websites in it. Corporate control is a shame, but the truth is that corporate control is not the problem at all. The problem is funding. Because anyone can try to deviate from web standards and implement windows-specific extension hacks in other browsers, but can you pay maintainers? Can you run the CI, the website and playground, host the CDN with the downloads? Etc. Sometimes the answer is yes, especially with how much SourceForge supports a lot of those things, but in general the answer is no. "Corporate control" is not the problem itself. Governance is just an outwardly visible consequence. The true control comes from maintainership and stewardship. Because if nobody is stepping up to the plate to take that role of introducing microsoft hacks in browsers, then whoever is doing it today effectively has control over the internet."

elcritch 4y ago

One small note, but Nim's comptime support is on par with Zig's. It's preferred using comptime and templates over macros when possible. Here's an example (1) of a compile time object to key value layer I did without macros. It's a basic wrapper to split an object's fields into separate key-value pairs for storage. The problem is that the storage system only has 16bit ints for keys which makes collision a large possibility. So this wrapper checks at compile time that there aren't duplicate keys. 1: https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/extras/nvsConfigObj.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/e...

KennyBlanken 4y ago

You're speaking about issues with corporate control in Go like it's some sort of theoretical thing. It's not. It's been here for ~5 years. Those "high quality library of cryptographic functions" you mentioned? Well, thanks to one Google employee, it is impossible in those "high quality" cryptographic functions to, say, disable in any way specific algorithms...except by modifying Go's source and recompiling it. This is (and I wish I were making this up) because said employee has decreed that TLS/1.3 and all the algorithms in it are the best thing since sliced bread (guess who was on the committee working on the TLS 1.3 spec!) and it couldn't possibly be insecure. Because, you know, history is not rife with examples of cryptographic functions (and perhaps more frequently, their implementations) being discovered to be vulnerable (in some cases, purposefully so thanks to NSA subterfuge.) Further, they stated that even if it were discovered to be insecure? Well, Google will just either fix it or disable the insecure part, and release an update, and if you can't apply that update in a timely fashion, you have "bigger problems": > Finally, about (removed) third point: if a security issue were to be found, we would publish a small security patch for all supported releases, like any other security vulnerability. A deployment that can't apply those timely has a bigger problem and won't be saved by TLS cipher suite configurability. Because when you wake up in the morning to a TLS/1.3 vulnerability reported in The Reg and go "oh shit", it's clearly not faster to push a configuration file change or change a bit of your own code to immediately disable the affected algorithm...than it is to wait for the mitigation to make its way through Golang's release process, get picked up by the distro you use and wind its way through that release process...all the while you're vulerable, and have been for weeks or months because Google bribes people to keep their mouths shut via the bug bounty program and/or 'responsible disclosure' policies. Because production environments always have the ability to push out new versions of a core package. Because it's never easier to push out a configuration or code change, both technically and administratively (ie change control.) Because it's not often easier to validate and if necessary roll back a configuration or code change versus a package change. Because clearly every organization that uses Golang as part of its infrastructure has the technical know-how and infrastructure to grab Go source code, modify it to disable a crypto algorithm, compile it, and package/distribute it. Because there's never a delay between when a vulnerability is discovered by blackhats, discovered by whitehats, reported to the project, mitigation makes it to release, the distro's package maintainer gets around to creating/modifying/applying the patch to whatever version they're actually still distributing, testing that / getting it signed off on, and pushed to update channels. So, there you have it. One ivory-tower asshole who has probably rarely worked on an infrastructure team, who does not seem aware of, much less care, about the potential consequences caused by his decision...for people who are not part of the same organization that maintains the programming language. I'm sure that if you work at Google and a problem with TLS/1.3 or Golang's implementation of it are discovered and reported to Google, you can count on that fix being made and deployed across Google's infrastructure almost instantaneously. The rest of us, it seems, can get fucked and be vulnerable for days or longer.