CTO da Azure: "Já chegou a hora de parar de iniciar novos projetos em C/C++"

 (twitter.com/markrussinovich)
22 pontos por xguru 2022-09-21 | 55 comentários | Compartilhar no WhatsApp
  • Se for um cenário que realmente exige uma linguagem sem GC, use Rust
  • É por segurança e confiabilidade
  • A indústria deveria declarar C/C++ como linguagens deprecated

Leituras relacionadas

55 comentários

 
ahwjdekf 2023-03-01

Até quem elogiava e usava Rust esse tempo todo diz que, quando se depara com async, bate uma forte frustração. Está surgindo até reclamação do tipo: será que com Rust nem deve fazer bibliotecas? (é complexo demais, exigente demais e difícil demais).
 
kernel00 2022-10-03

Tem gente por aí menosprezando sem nem saber quem é Mark Russinovich... ele é o autor do conjunto de ferramentas Sysinternals e do livro Windows Internals... é alguém que fazia ferramentas fazendo engenharia reversa do Windows e acabou se tornando Microsoft Fellow...
 
ahwjdekf 2022-09-25

Um post que zomba, em um vídeo curto, dos problemas dos fanáticos por Rust

https://twitter.com/cmuratori/status/1367627549816152064?lang=en
 
ahwjdekf 2022-09-25

O Rust ainda nem tem uma especificação oficial....
 
functor 2022-09-29

O C++ até "tem" uma spec formal, mas todas as implementações (gcc, clang, ...) são incompletas, né
 
lifthrasiir 2022-09-26

Esse é um argumento comum, mas, para alguém que já leu muitas especificações e também já implementou várias delas, eu realmente não sei qual é o significado prático de existir ou não uma especificação.

Existem várias estratégias de "especificação". Há formas de descrevê-la com foco no comportamento observável e formas de descrever o funcionamento interno; e também há a divisão entre usar linguagem natural ou um formato legível por máquina, como pseudocódigo ou definição matemática. Coisas como a documentação de referência da linguagem Python ou Rust são especificações que descrevem o comportamento observável em linguagem natural. Uma abordagem comum em padrões ISO e afins é descrever o funcionamento interno em linguagem natural, mas isso não garante que esse funcionamento interno corresponda à abordagem das implementações reais; em vez disso, define-se algo como: se uma implementação hipotética construída com base nesse funcionamento interno e uma implementação real se comportam da mesma forma na aparência, isto é, são observationally equivalent, então ela está em conformidade com o padrão. O ECMAScript é descrito em linguagem natural, mas sua estrutura real está, na prática, no nível de um pseudocódigo escrito em linguagem natural; e também há casos como o WebAssembly, que fornece tanto uma especificação em linguagem natural quanto uma definição matemática para o funcionamento interno.

Do ponto de vista de implementação, especificações em linguagem natural são mais ou menos tudo a mesma coisa. Como precisam ser produzidas separadamente da implementação real, é natural que às vezes as duas acabem se distanciando uma da outra, e erros também acontecem com frequência. Se o comportamento observável é mais fácil de implementar ou se o funcionamento interno é mais fácil de implementar depende da situação, mas, do ponto de vista de linguagens de programação, não há propriamente uma justificativa obrigatória para escolher um dos dois lados. Nesse sentido, Rust já tem uma especificação, e é correto dizer que essa especificação fornece informação suficiente a ponto de permitir o surgimento de outras implementações alternativas.

Se você quer simplesmente julgar a maturidade de um padrão com base em ele ter se tornado ou não um padrão ISO, então deixo aqui a notícia de que eu encontrei cerca de 100 bugs no padrão ISO/IEC 18181-1 JPEG XL (e, por causa disso, a 2nd amendment está sendo adiada)...
 
xguru 2022-09-25

Até no Hacker News já houve mais de 800 comentários... aqui também está pegando fogo... https://news.ycombinator.com/item?id=32905885
 
kayws426 2022-09-25

Muito obrigado pelo seu esforço.
Enquanto isso... vi um texto dizendo que, quando algo de que uma pessoa gosta é atacado, devemos ter cuidado para não atribuir a reação dela à sua personalidade, e achei isso uma boa colocação, porque provavelmente é muito difícil manter esse tipo de atitude em situações reais.
 
ahwjdekf 2022-09-24

Tem um comentário no tweet que chamou a atenção.

People end up writing Rust code the "unsafe way". - omitido - Rust nunca teve a intenção de substituir essas coisas.
 
kayws426 2022-09-24

A esta altura, vou deixar um link para quem quiser saber quem é Mark Russinovich.
https://en.m.wikipedia.org/wiki/Mark_Russinovich
 
ahwjdekf 2022-09-24

Só mais uma coisa. As pessoas que usavam C++ e viviam causando erros e criando bugs, aí diziam: "ah, isso não dá, vamos para Rust, que está na moda hoje em dia... dizem que nem precisa se preocupar com erros de memória..." Essas pessoas são iguais. Também vão acabar criando bugs parecidos em Rust... e depois vai ter muita gente pensando: "então qual vai ser a próxima linguagem para aprender e tentar?" É gente que nem chegou a lidar direito com desreferenciamento de ponteiro em C++ e fica aí babando ovo do Rust.
 
ahwjdekf 2022-09-24

Esse tipo de pessoa vai simplesmente ignorar tudo aquilo que o Rust aponta como ponto forte — propriedade, referências, empréstimos — porque já dá erro na compilação e dor de cabeça, e acabar misturando unsafe e usando como se fosse C++.
 
functor 2022-09-29

Já que todo mundo vai morrer mesmo, por que viver?
Parece quase o mesmo nível de lógica disso.
 
budlebee 2022-09-25

Parece aquele argumento de que, já que quem causa acidentes de qualquer forma não usa cinto de segurança e ignora o semáforo, então cinto e semáforo não têm muita utilidade.
Dá até para dizer que quem é bom vai se sair bem fazendo qualquer coisa, e quem não é bom vai se sair mal fazendo qualquer coisa, mas se seguir essa lógica não dá nem para discutir a utilidade das ferramentas.
 
cr543l 2022-09-23

O problema é que a linguagem é difícil demais de usar, então é uma observação correta mesmo.
 
iolothebard 2022-09-23

Quando sair um Visual Rust, aí eu reconheço... rs
 
binaryeast 2022-09-21

C/C++ agora realmente parecem estar indo para o lugar do latim. Para fins acadêmicos, qualquer um deveria estudá-las, mas dominá-las é algo quase impossível e, por serem um sistema antigo, também têm muitas partes que hoje em dia são irracionais...
 
dalinaum 2022-09-21

É curioso como usam tranquilamente linguagens em que tudo é unsafe, mas dizem que uma linguagem na qual o unsafe pode ser usado de forma limitada é absolutamente inaceitável.
 
functor 2022-09-22

Acho que é uma espécie de síndrome de Estocolmo
 
williameom 2022-09-21

O Espírito de C

1. Confie no programador.  
2. Não impeça o programador de fazer o que precisa ser feito.  
3. Mantenha a linguagem pequena e simples.  
4. Ofereça apenas uma forma de realizar uma operação.  
5. Faça com que seja rápido, mesmo que não haja garantia de portabilidade.
 
functor 2022-09-22

Na minha opinião pessoal, acho que o ponto 1 já está errado haha, porque as pessoas são propensas a erros por natureza..
 
heal9179 2022-09-21

No C++, basta usar ativamente smart pointers e memory pools...
Acho que, na prática, não há tantas situações em que seja preciso lidar diretamente com ponteiros.

Eu penso que código thread-safe, no fim das contas, depende da capacidade do próprio programador.
Independentemente da linguagem usada, quando a pessoa não tem habilidade suficiente,
acabamos vendo código seguro, mas com desempenho ruim, ou então código perigoso.
 
hiyama 2022-09-23

Confiar a habilidade de um programador dirigir um carro ou pilotar um avião é assustador demais....
 
functor 2022-09-22

Código thread-safe, no fim das contas, é uma questão da capacidade do próprio programador <- eu considero essa ideia perigosa, porque memory / thread safety não fica apenas no nível de o programa travar ou ficar lento; isso evolui para vulnerabilidades de segurança, então não acho que isso deva ser deixado a cargo da habilidade individual de uma pessoa.

Diversos métodos para prevenir isso de antemão vêm sendo pesquisados, e eles amadureceram a ponto de dar origem a linguagens como Rust e outras ferramentas; acho que o impacto do software na vida cotidiana se tornou grande demais para ignorar isso e simplesmente colocar a culpa no indivíduo por não utilizá-los.
 
mastotron 2022-09-21

As pessoas, por serem humanas, inevitavelmente cometem erros, e por mais inteligente que seja o programador, ele também está sujeito a errar. Bugs de memória, no fim das contas, também surgem de erros...

Hoje em dia, em vez de depender que as pessoas façam tudo certo por conta própria, talvez uma abordagem melhor seja oferecer desde o início um ambiente em que seja difícil cometer erros.
 
ahwjdekf 2022-09-21

Se quisermos usar Rust na nossa empresa, o uso de unsafe é proibido. Só com uma regra dessas dá para pensar em confiar de fato na segurança oferecida pela linguagem. Mas isso faz algum sentido?
 
mastotron 2022-09-21

Claro, em empresas que usam Rust provavelmente existe um consenso de que não se deve usar unsafe a menos que seja realmente necessário. Mais do que isso, eu recomendaria que você mesmo tentasse programar diretamente em Rust... Não seria preciso usar na prática para descobrir quantas vezes de fato surgirá a necessidade de usar unsafe?
 
ahwjdekf 2023-02-15

Em bibliotecas conhecidas como o tokio, encheram tudo de unsafe.
 
novemberoscar 2022-09-21

Parece que há bastante comentário tratando isso como tudo ou nada, como se não fosse All então não tivesse valor algum

Há a vantagem de poder distinguir e isolar explicitamente unsafe / safe, e de fazer com que alguém que causaria 100 bugs de memória acabe causando 10; ainda assim, o raciocínio de que, de qualquer forma, existe unsafe / mesmo assim bugs de memória continuam acontecendo => portanto não há nada em que seja melhor que C++... não sei bem se essa é uma avaliação realista 😅
 
ruinnel 2022-09-22

Pelo número de comentários, parece isso mesmo.....
Mas a situação parece ser mais: há muitos comentários escritos por uma pessoa com uma opinião de tudo ou nada...
 
csjune 2022-09-21

Eu também concordo com este comentário. Quanto mais você enxerga algo de forma binária, mais acaba apenas saindo no prejuízo.

No trabalho real, o normal é pesar os prós e contras e, no fim, escolher aquilo que traz mais vantagens. Pelas características do setor, se não for um caso em que inevitavelmente seja preciso usar C/C++ agora, acho que as vantagens obtidas ao usar Rust são grandes, e por isso as áreas em que Rust é utilizado estão se ampliando cada vez mais.

Quem está migrando para Rust também não é bobo; se continuam usando, é porque viram na prática que, no fim das contas, ele oferece algo melhor do que C++, haha
 
alstjr7375 2022-09-21

Nada... Tudo
 
functor 2022-09-21

Hoje em dia, poucas pessoas discordariam de que Rust é o próximo C++. Afinal, ele foi adotado até como linguagem oficial no kernel Linux.
Ainda assim, fica a dúvida se Rust é realmente uma linguagem fácil de usar... Graças à análise estática feita para prevenir problemas de segurança de memória com antecedência, o tempo de compilação pode ser bem doloroso, e semânticas como ownership são difíceis, então ela exige muito mais estudo do que linguagens de uso geral como Python ou Java.
 
dalinaum 2022-09-21

O tempo de compilação provavelmente é um grande problema do próprio LLVM. Como o Facebook está se esforçando para melhorar a seleção de instruções do LLVM, a situação deve melhorar.
 
functor 2022-09-22

Pesquisei e realmente é isso mesmo. Eu achava que se gastava muito tempo com verificação de tipos relacionada a ownership, mas o backend do LLVM é grande mesmo..
 
ahwjdekf 2022-09-21

Quando o Rust apareceu pela primeira vez, eu fiquei muito interessado e estudei um pouco... mas assim que vi a parte de unsafe, desisti na hora. Simplesmente não consegui encontrar uma justificativa racional para aprender e usar isso. De qualquer forma, qualquer programa minimamente complexo acaba tendo que usar unsafe. Mas aí a segurança da qual o Rust tanto se orgulha vai embora. Por que usar isso?
 
mastotron 2022-09-21

Em Rust, unsafe só é necessário quando se faz programação de baixo nível; ao escrever aplicações comuns, pode-se considerar que quase não há necessidade de usá-lo.

Além disso, mesmo que ocorra um problema de memória dentro de um bloco unsafe, há a vantagem de que a linguagem garante que a parte onde o problema ocorreu está dentro do bloco unsafe, o que facilita a depuração.
 
functor 2022-09-21

Se, ao ver unsafe, você vai perguntar "por que usar isso?", então já não deveria usar C/C++ desde o começo, não é?
 
ahwjdekf 2022-09-21

O C++ também continua evoluindo e, se é para usar algo unsafe, então eu simplesmente usaria C++; não sinto que haja tanta necessidade de aprender e usar Rust.
 
functor 2022-09-21

Nem toda programação em Rust exige unsafe.
Como manipulações de memória minuciosas a ponto de precisar de unsafe geralmente ficam concentradas no desenvolvimento de bibliotecas, acho que no lado do desenvolvimento de aplicações — onde provavelmente haverá a maior demanda — quase não vai haver motivo para usar unsafe.
Também é verdade que o C++ continua evoluindo, mas o legado necessário para manter a compatibilidade retroativa pesa demais. Se o incômodo é a ponto de reclamar por causa de um único unsafe, então acho que você vai se incomodar com todos os recursos do C++ também haha
 
alstjr7375 2022-09-21

Por isso unsafe não é recomendado.
Se você usar algo seguro, tudo fica mais seguro do que C/C++, onde tudo é praticamente equivalente a unsafe.
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
 
ahwjdekf 2022-09-21

Se não existisse esse mecanismo ambíguo chamado unsafe, talvez Rust pudesse se tornar uma verdadeira alternativa ao C++.
 
jjpark78 2022-09-21

Eu só fico pensando como seria se a FFI fosse um pouco mais amigável... Tenho uma lembrança bem dolorosa de quando tentei trocar estruturas compostas com uma biblioteca externa via FFI.
 
alstjr7375 2022-09-21

Até mesmo Rust para Rust não é fácil.. https://github.com/rodrimati1992/abi_stable_crates
 
jjpark78 2022-09-21

Parece uma declaração bastante natural se for vista como uma extensão da situação em que a MS vem apoiando ativamente o Rust.
 
colus001 2022-09-21

Até o teimoso do Torvalds adotou Rust, então não vejo necessidade de continuar usando de propósito uma linguagem que cada vez menos gente aprende.
 
ahwjdekf 2022-09-21

Bugs relacionados à memória não vão simplesmente desaparecer só porque se usa Rust. As pessoas que criam bugs vão produzir bugs em qualquer linguagem que lhes derem. Estamos usando C++ de forma eficiente e sem problema nenhum, então acabar com ele para quê? Realmente soltou uma fala bombástica sobre a qual não se devia falar levianamente.
 
functor 2022-09-21

É difícil dizer que C/C++ vem sendo usado de forma eficiente e sem problemas, porque historicamente já houve inúmeros bugs relacionados à memória em C/C++, e provavelmente eles continuam acontecendo em algum lugar até hoje. (Graças a isso, muitos pesquisadores de PL/SE conseguiram ganhar a vida, mas enfim.)
Segundo o anúncio da Microsoft, 70% dos bugs de segurança estão relacionados à memória (https://zdnet.com/article/…)
O resultado de uma investigação do projeto Chromium foi parecido (https://www.chromium.org/Home/chromium-security/memory-safety/): novamente, quase 70% eram bugs relacionados à memória.
 
jjpark78 2022-09-21

A maioria dos bugs no kernel do Windows são erros relacionados à memória, e eu me lembro de ter visto em algum lugar uma matéria antiga dizendo que, nas partes que estão sendo desenvolvidas em Rust, esse tipo de erro diminuiu drasticamente..

Como a própria linguagem foi concebida com uma estrutura que recomenda ativamente readonly, acho difícil negar que ela tem um design de linguagem mais seguro do que C++. Só que, por causa disso, surgiu esse conceito inédito de ownership, o que acaba tornando a programação mais difícil.

Também existe a vantagem de desempenho de que, estatisticamente, um código Rust feito mais ou menos acaba rodando mais rápido do que um código C++ muito bem projetado.
 
lordang 2022-09-21

Parece que ele disse algo que pode causar polêmica. kkk
Pessoalmente, acho que o C++ já é antigo demais, então acaba travado pela compatibilidade com versões anteriores e evolui mais lentamente de forma moderna.
Além disso, como tentam manter a compatibilidade retroativa de forma rigorosa enquanto adicionam recursos modernos, existem maneiras demais de fazer a mesma coisa, e acho que isso acaba criando uma barreira de entrada ainda maior para iniciantes.
Eu também acho que, nesta altura, Rust é melhor do que C++. Já deu dessa época de ficar com os olhos vermelhos caçando bugs relacionados ao gerenciamento de memória.
 
jjpark78 2022-09-21

Sim, é isso mesmo... se for um projeto de desenvolvimento começando do zero, realmente não há motivo para escolher C++...
 
kandk 2022-09-21

Concordo totalmente
 
loblue 2022-09-22

Mesmo que eu queira usar Rust, por enquanto só dá para usar de forma complementar; no trabalho ainda não tenho ocasião de usá-la de fato.
Por isso também é difícil pegar familiaridade de verdade, e se eu fico um tempinho sem mexer, acabo esquecendo...
Com certeza quero usar porque gosto... haha
 
koreacglee 2022-09-23

Um monte de gente que nunca sequer tentou escrever um memory pool para melhorar a eficiência do uso do heap fica aí falando de RUST pra caramba rs
O CTO da Azure obviamente não é uma opinião que represente o padrão da indústria e, mesmo se limitar à Microsoft, de jeito nenhum é uma opinião que represente a posição da empresa; no fim das contas, talvez não passe de alguém soltando do nada uma visão totalmente subjetiva... Quem não sabe fazer C++ direito vai por acaso saber fazer Rust direito? Enfim, tá cheio de gente só falando pelos cotovelos.
 
functor 2022-09-26

Seu jeito de falar já revela, sem deixar margem para dúvida, a sua vulgaridade. Força aí.