3.4 KiB
+++ title = "Go problem is not the XML vulnerability" date = 2020-12-15
[taxonomies] tags = ["go", "golang", "thoughts", "stdlib", "patterns"] +++
Yesterday I posted some comments about the vulnerability in go XML stdlib1 and some people said it was not a big deal.
The problem is not the vulnerability in itself, though.
Also, the problem is just partially related the fact that it can't be reliable
fixed. And it is not related with the "http" library had a DoS problem. And it
is not related with the natural number functions (and specifically
divRecursiveStep) had an error that put Etherium network down. And it is not
related with the "ssh" library had a vulnerability that had to be fixed.
The problem is the pattern.
I'm don't expect projects to be some mythical "everything should be flawless". Heck, with the exception of the "xml" issue in the original post, all other issues are already fixed.
But there is a pattern emerging from go stdlib that shows that little care was
taken when building it. And, along with this pattern, we have the issue that
this is in the stdlib. Stdlibs should, even more than just provide an
infrastructure for bigger applications, be reference implementations. For
example, if you want to see how the heck Python managed to add SQLite, you just
need to check Python stdlib (FFI); you can check the source (FFI); or if you
want to know how can sets in Python be fast (faster then everything else in
Python, that is) you can also check the stdlib (it is written in C); or how they
managed to make "namedtuples" create objects dynamically (eval). All those
describe how you can build something that connects to something external, that
is fast or that is magical.
And the pattern shows that go stdlib is doing it wrong. It seems the go team focused too much in "adding value" and too little in "being a reference".
Another example that there is something wrong with the language: in four months, the problem with the ordering could not be fixed. In half of that time, I can write binding for libxml2 in Python, or even Rust, even if I'm not that experienced with Python or Rust FFI. That means that the layer that gives the stdlib access to external things is taking too much control, in a way that you can't let external libraries use their own structures without that being messed up with the runtime. If the FFI had enough freedom to just expose the top layers, writing their own implementation of a XML parser in C and just exposing to the top layers would be completely doable in four months -- even without the use of libxml2.
All those are patterns of things going wrong with the language architecture. And that's why I said that anything half-serious shouldn't be written in go in the first place.
I'm someone that likes to say something controversial from time to time. At the start of this year, in one event, I said that any technical leader worth its salt wouldn't recommend go for anything. And I stand by that. Tech leaders should see this kind of problem appear and take steps to not be dragging into some hole they can't get out, and the pattern of architectural problems with go was emerging a long time already.
PS: You may have noticed that I typed "go" instead of "Go" in most of this post. This is on purpose; I don't believe the language deserves getting a capital "G".
-
From now on, I'll use "stdlib" for "standard libraries", the libraries/modules that come with a language. ↩︎