Go and the XML problem

content/thoughts/go-problem-is-not-the-xml-vulnerability.md

@@ -0,0 +1,73 @@
++++
+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.

content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md

@@ -0,0 +1,75 @@
++++
+title = "O problema de go não é a vulnerabilidade"
+date = 2020-12-15
+
+[taxonomies]
+tags = ["go", "golang", "padrões", "xml", "vulnerabilidade"]
++++
+
+Ontem eu postei [alguns comentários sobre a vulnerabilidade da biblioteca XML
+do go](@/links/go-xml-vulnerability.pt.md) e algumas pessoas disseram que isso
+não era grande coisa.
+
+O problema não é a vulnerabilidade em si, no entanto.
+
+<!-- more -->
+
+Ainda, o problema é só parcialmente com relação ao fato que a vulnerabilidade
+não pode ser corrigida de forma confiável. E não é em relação à biblioteca
+"http" que tinha um problema de negação-de-serviço. E não é em relação à
+biblioteca de números naturais (e mais especificamente `divRecursiveStep`) que
+causou um erro na rede de Etherium. E não é em relação que a biblioteca "ssh"
+tinha uma vulnerabilidade que foi corrigida.
+
+O problema é o padrão.
+
+Eu não espero que as coisas tenham aquele toque místico de "tudo tem que ser
+perfeito". Poxa, com a exceção do problema da biblioteca "xml", todos os outros
+problemas já foram corrigidos.
+
+Mas existe um padrão surgindo na biblioteca padrão do go que mostra quão pouco
+cuidado foi tomado na sua construção. E, junto com esse padrão, tem o
+problema que isso está na biblioteca padrão. Bibliotecas padrão deveriam, além
+de prover uma infra-estrutura para aplicações maiores, serem implementações de
+referencia. Por exemplo, se você quiser saber como é que diabos o Python fez
+para adicionar suporte ao SQLite, basta você olhar a biblioteca padrão (FFI);
+ou se você se perguntar como é que sets em Python são tão rápidos (tão rápidos
+com relação ao resto das coisas em Python, quero dizer), você também
+pode consultar a biblioteca padrão (sets são escritos em C); ou como é que eles
+fizeram para que "namedtuples" criassem objetos magicamente (`eval`). Essas
+partes descrevem como você deve construir algo que conecte com algo externo,
+que seja rápido ou que seja mágico.
+
+E esse padrão mostra que a biblioteca padrão do go está fazendo as coisas de
+forma errada. Parece que o time de go focou muito em "adicionar valor" e muito
+pouco em "servir de referência".
+
+Outra indicação que tem algo errado com a linguagem: em quatro meses, o
+problema da ordenação não pode ser corrigido. Em metade desse tempo eu consigo
+escrever *bindings* da libxml2 em Python, ou até mesmo em Rust, mesmo não tendo
+experiência alguma com o FFI de Python ou Rust. Isso significa que essa camada
+que dá acesso a biblioteca padrão à coisas externas está tendo muito controle,
+de forma que estruturas externas não podem ser usadas sem que sejam bagunçadas
+pelo runtime. Se o FFI tivesse liberdade suficiente para expor somente a camada
+mais externa, escrever uma implementação de parser XML em C e só expor as
+camadas superiores seria completamente viável em quatro meses -- mesmo sem usar
+a libxml2.
+
+Todos esses padrão mostram que tem algo de errado com a arquitetura da
+linguagem. E é por isso que eu disse que qualquer coisa no mínimo semi-séria
+não deveria ser escrita em go.
+
+Eu sou uma pessoa que diz coisas controversas de tempo em tempos. No começo
+desse ano eu disse, em um evento, que um líder técnico que valesse o seu
+próprio salário não recomendaria go para coisa alguma. E eu mantenho essa
+posição. Líderes técnicos devem ver esse tipo de problema aparecer e tomar
+ações para evitar que o projeto caia num buraco que seja complicado de sair
+depois. E esse padrão de problemas com go já tem aparecido a muito tempo.
+
+PS: Vocês devem ter notado que eu digitei "go" e não "Go" na maior parte desse
+post. Isso é proposital; eu não acredito que a linguagem mereça ser chamada com
+um "G" maiúsculo.
+
+<!-- 
+vim:spelllang=pt:
+-->