The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

74 lines
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
stdlib](@/links/go-xml-vulnerability.md)[^1] and some people said it was not a big
deal.
The problem is not the vulnerability in itself, though.
<!-- more -->
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".
---
[^1]: From now on, I'll use "stdlib" for "standard libraries", the
libraries/modules that come with a language.