Engenheiros de DevOps escrevem políticas do Kubernetes em Rego. Newton escreve regras de conformidade financeira de US$ 5 milhões na mesma linguagem.
Essa escolha de design me fez parar quando li na documentação oficial da Newton em blog.newton.xyz: "Rego é a mesma linguagem que as equipes de TI já usam para conformidade e imposição de políticas dentro de empresas tradicionais."
A justificativa é documentada e simples. Desenvolvedores de empresas já conhecem Rego. As instituições podem escrever e auditar suas próprias políticas de conformidade sem aprender uma sintaxe nova. Menos atrito de adoção significa integração mais rápida.
Esse argumento é real. O contraponto também é real.
Rego foi projetada para controle de acesso em infraestrutura de software. "Permita que este serviço leia este segredo" e "bloqueie esta transferência para este destinatário sancionado" são escritos na mesma linguagem, mas não são o mesmo problema. Controle de acesso a software falha com uma solicitação negada. Falhas de conformidade financeira movem dinheiro para lugares onde não deveria ir, acionam medidas regulatórias e expõem as instituições a responsabilidade legal. Os perfis das consequências são diferentes em ordens de magnitude.
SQL foi originalmente projetada para consultar bancos de dados relacionais. Quando instituições financeiras começaram a usá-la para monitoramento de transações em tempo real, passaram anos descobrindo casos-limite que a linguagem nunca foi desenhada para lidar nesse nível de risco. Ferramentas familiares em um novo domínio não significam automaticamente que servem ao propósito.
A Newton está apostando que Rego é expressiva o suficiente para cobrir casos-limite de conformidade financeira para os quais nunca foi desenhada. A familiaridade do desenvolvedor corporativo é a vantagem. O encaixe em um domínio não testado é a parte que ninguém está examinando.
$NEWT #Newt @NewtonProtocol
Essa escolha de design me fez parar quando li na documentação oficial da Newton em blog.newton.xyz: "Rego é a mesma linguagem que as equipes de TI já usam para conformidade e imposição de políticas dentro de empresas tradicionais."
A justificativa é documentada e simples. Desenvolvedores de empresas já conhecem Rego. As instituições podem escrever e auditar suas próprias políticas de conformidade sem aprender uma sintaxe nova. Menos atrito de adoção significa integração mais rápida.
Esse argumento é real. O contraponto também é real.
Rego foi projetada para controle de acesso em infraestrutura de software. "Permita que este serviço leia este segredo" e "bloqueie esta transferência para este destinatário sancionado" são escritos na mesma linguagem, mas não são o mesmo problema. Controle de acesso a software falha com uma solicitação negada. Falhas de conformidade financeira movem dinheiro para lugares onde não deveria ir, acionam medidas regulatórias e expõem as instituições a responsabilidade legal. Os perfis das consequências são diferentes em ordens de magnitude.
SQL foi originalmente projetada para consultar bancos de dados relacionais. Quando instituições financeiras começaram a usá-la para monitoramento de transações em tempo real, passaram anos descobrindo casos-limite que a linguagem nunca foi desenhada para lidar nesse nível de risco. Ferramentas familiares em um novo domínio não significam automaticamente que servem ao propósito.
A Newton está apostando que Rego é expressiva o suficiente para cobrir casos-limite de conformidade financeira para os quais nunca foi desenhada. A familiaridade do desenvolvedor corporativo é a vantagem. O encaixe em um domínio não testado é a parte que ninguém está examinando.
$NEWT #Newt @NewtonProtocol