O Linux tem que ser reescrito em Rust

[sync]

Caro Rodrigo
A linguagem Go me causou a mesma impressão, tenho estudado e experimentado com ela mas ainda não desenvolvi um projeto maior, só testes

[mrgadotti]

Trabalhei com um Network Server Lora escrito em Go, era muito prático fazer um cross compile...

[Rodrigo_P_A]

Vou falar a impressão que eu tive:
GO -> Li e entendi rápido como fazer cross-compile, integração ( lib shared para chamar do C ou de qualquer outro programa que use libs shared, ou seja, praticamente qualquer um)
GO -> dá pra gerar aplicação cruzada sem estar na máquina HOST de forma fácil e simples.

RUST -> Até agora, num entendi a vantagem que tanto dizem. Ainda não gerei um App cross pra testar.
Todo mundo foca em falar que é seguro, que a ferramenta é completa, ainda não entendi se é realmente tão bom assim investir tempo nele, sendo que já tenho muita experiência e não tenho problemas com C/C++.
Vi um cara falando absurdo de que programas em C/C++ geram comportamentos e funcionamento inesperado, esse tipo de argumento é de quem não sabe programar. Qualquer linguagem se você não souber o que está fazendo vai gerar comportamento inesperado ( já cometi vários erros assim ), mas está mais relacionado a falta de lógica e falta de saber o que está fazendo do que com a ferramenta em uso. ( exceto para linguagens gerenciadas, já passei raiva com GC /garbage collector do dotnet, ele sim gerava coisas inesperadas).

Em ambas o que eu percebi:
Fácil de baixar, fácil de compilar.
GO achei mais fácil ainda do que RUST.

Sobre C++ minha experiencia e opinião:
Talvez seja esse o ponto fraco de algumas ferramentas de C/C++, é mais complicado de fazer o setup para usar, gerar crosscompile do que as acima.

Na minha empresa estou migrando todo backend para c++, usando webserver, camada de acesso a banco e tudo escrito em C++, uma parte era feita em dotnet/outra em php, eu desistir dessas ferramentas.

Depois que a gente aprende a fazer, não tem comparação, eu tenho todas as libs e ambiente bem configurado para gerar aplicações multiplataforma nativa, sem dependência de pacotes instaláveis de terceiros.

Exemplo: Minha aplicação servidor eu empacoto em um instalador para linux, a aplicação toda com as libs em pacotadas tem 40MB, sem libs 9MB (qdo é só pra atualizar).
A atualização do servidor , leva poucos segundos.
Instalei nas principais distros, sem ter que ficar instalando pacotes de terceiros, mas realmente dá trabalho demais chegar nesse ponto.
Usa pouca memória, é rápido , atende muitas conexões.

Uma coisa em C/C++ que foi uma sacada da galera do Arduino, é o jeito de escrever, mesmo em C/C++ o jeito de escrever fica claro, limpo.
Muitos desenvolvedores que usam C/C++ escrevem de forma que não é muito legível, depois que a gente aprende dá pra entender rápido, mas para os novatos, é complicado e eu já passei por isso, teve uma época que eu achava o Dotnet uma maravilha, depois de muitos anos eu percebi que a maior sacada dos caras na minha opinião é o jeito simples de se escrever as coisas.

Eu copiei muita ideia do Dotnet mas uso em C++, exemplo, tenho rotina tipo:
System.IO.FIle.WriteText(nome_do_arquivo,"texto ou string");
e várias outras para banco de dados, webserver. Dentro dessa rotina num tem como ficar muito bonito, mas a aplicação que chama essas rotinas fica muito mais simples de entender, penso em um dia em organizar tudo e colocar lá no github.

[KrafT]

Todo mundo que trabalha com produção de verdade, sabe que não existe isso de "Reescrever tudo do zero". Se alguém fala isso é jovem sendo levado pelo hype, muitas vezes por que o professor do curso falou que era legal. Especialmente os que falam "Linguagem Assembler"

Quando se tem base instalada, veja Bancos e COBOL, ou mesmo sistemas de governos, militares e aeroespaciais, o custo de "reescrever tudo" é impraticável. Vejam o que roda nos robozinhos da Nasa em Marte. Não é com plaquinhas Arduino e "programado em Arduino". Talvez RUST?

Agora, novos módulos feitos em linguagens mais adequadas para cada caso, pq não? Quantos games tem o motor feito em C++ que "interfaceia" com scripts como LUA, e por aí vai.

Eu tenho cada vez menos paciência para lidar com jovens. Graças a todos os deuses que a humanidade já inventou, quando eu era jovem, meus superiores tinham muito mais paciência do que eu tenho hoje, pq eu aprontei tanto que deveria ter sido demitido recursivamente.

[tcpipchip]

Concordo!

"Qualquer linguagem se você não souber o que está fazendo vai gerar comportamento inesperado", sim, mas a maioria não alerta sobre isto! Isto que me chamou a atenção! E não é um alerta, são vários!

[tcpipchip]

GO -> Li e entendi rápido como fazer cross-compile, integração ( lib shared para chamar do C ou de qualquer outro programa que use libs shared, ou seja, praticamente qualquer um)
GO -> dá pra gerar aplicação cruzada sem estar na máquina HOST de forma fácil e simples.

EXATAMENTE!!!!!!!!!!!!!!

Entender CROSS-COMPILE é show!

[xultz]

A questão é que, novamente, não existe o melhor que serve para tudo. Isso se aplica a muitas coisas, como linguagem de programação, microcontrolador, sistema operacional, carro, instrumento musical, qualquer coisa.
Então quando alguém defende que novos códigos para o kernel Linux devem ser escritos em Rust, isso quer dizer que todos devem usar Rust para todas as coisas que venham a programar? Logicamente que não, cada caso é um caso, a linguagem de programação é somente uma ferramenta, e devemos sempre procurar a melhor ferramenta para apertar cada parafuso que a vida colocar na nossa frente.
Particularmente eu gosto de Python, mas isso quer dizer que tudo que eu decidir fazer de hoje em diante deve ser em Python? Sob hipótese alguma, o Python é adequado para um universo bem limitado de problemas. E isso também se aplica a C, ao C++, ao Go, ao Rust, e todo o resto. Seria muito conveniente se houvesse uma solução que fosse adequada para todas as situações, e então poderíamos focar em estudar somente esta solução, mas ela não foi inventada ainda.
O que realmente um profissional deve focar é compreender no que uma determinada linguagem brilha, e aplicá-la quando houver a necessidade. Isso é o que diferencia o profissional do fanboy.

[tcpipchip]

É isto ai Xultz

Aparece o problema, escolher a melhor linguagem para resolve-lo!

[eletroinf]

Antigamente havia esta mesma discussão aqui neste mesmo fórum, com as mesmas pessoas.
Diferença? Naquela época só tinha a "briga" entre Assembly e C. Agora tem muito mais opções.
Ah, o Kraft voltou pistola

Um abraço a todos vocês!

[tcpipchip]

Inicio dos anos 80 eu discutia COBOL, FORTRAN, ALGOL, LTD e MUMPS

[xultz]

Eu discutia sobre rotear placa de circuito impresso em papel polegadado ou com o Tango. Eu defendia fazer no papel (porque não sabia usar o Tango e meu computador era um MSX).
Ai meu reumatismo...

[tcpipchip]

Eu discutia sobre rotear placa de circuito impresso em papel polegadado ou com o Tango. Eu defendia fazer no papel (porque não sabia usar o Tango e meu computador era um MSX).
Ai meu reumatismo...

Eu pensava em como piratear o Tango que meu chefe comprou!
Ele tirou todas as unidades de discos dos computadores na época

[Rodrigo_P_A]

Eu gosto de escrever os programa em binário em uma folha de papel

[tcpipchip]

eu tambem! Mas uso cartao perfurado!

[Rodrigo_P_A]

eu tambem! Mas uso cartao perfurado!

vc é moderno