 |
Lançado Nim 2.2.12 |
v2.2.12 da nim-lang no github
Aproveitem também para assistir a NimConf 2026 que contem duas playlists. A primeira se chama NimConf 2026 - social & workflow track e a segunda NimConf 2026 - project track.
Saiba mais sobre a linguagem Nim clicando aqui
 |
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
 |
Lançada Nim 2.2.10 e NimConf 2026 |
No dia 24 de Abril, a equipe da linguagem de programação Nim anunciou o lançamento da versão 2.2.10 (dois meses após o lançamento da versão 2.2.8) que contem 76 commits que trazem 36 correções de bugs. Todas as alterações podem ser conferidas clicando aqui.
E gostaria de aproveitar para divulgar o NimConf 2026 que ocorrerá no dia 20 de Junho no canal da própria linguagem.
Mais sobre a nim-lang 2.2.10 podem ser conferido clicando aqui
Mais sobre a linguagem Nim pode ser conferida clicando aqui OU clicando aqui em nimLang
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
 |
Lançado Nim 2.2.8 |
No dia 23 de Fevereiro de 2026 , o time da linguagem Nim anunciou o lançamento da versão 2.2.8, o quarto patch release para a versão 2.2 adicionando 89 commits trazendo correções de bugs (o total de 39 correções) e melhorias. A correção mais importante foi a parte de código multi-threaded pesado que torna o alocador mais estável, mas ainda querem trabalhar para ter o -d:userMalloc.
Todas as novidade do Nim 2.2.8 podem ser conferidas Nim Blog
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
 |
Lançado Nim 2.2.6 |
No dia 31 de Outubro foi anunciado o lançamento da versão 2.2.6 da linguagem Nim depois de seis meses do lançamento da versão 2.2.4. Essa versão contem 141 commits trazendo 53 correções de bugs e melhorias. Uma dessas melhorias está no desempenho que já era bom, agora o compilador é esperto para produzir uma operação para retorno de obj.field que anteriormente ele fazia uma cópia. O async do Nim está mais estável por ter sido reeescrito.
Não vou me estender aqui sobre esta nova versão já que possuo bastante material aqui no blog promovendo a linguagem Nim, porém todas as alterações na versão 2.2.6 pode ser conferidas clicando aqui.
Baixe a versão 2.2.6 clicando aqui
Para saber mais sobre a linguagem nim, clique aqui ou aqui em nimlang
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
 |
Fil-C, uma implementação das linguagens C e C++ com suporte a segurança de memória |
Filip Pizlo, que é diretor senior de engenharia de linguagem da Epic Games e que também já foi gerente da JavaScriptCore na Apple além de possuir 15 anos de experiencia na construção de linguagens de alto nível com alto desempenho, desenvolveu uma implementação das linguagens C e C++ com suporte a segurança de memória (algo que todo mundo está cobiçando agora).
Fil-C utiliza a combinação de garbage collection chamado FUGC (Fil's Unbelievable Garbage Collector que, sendo mais específico, é um parallel concurrent on-the-fly grey-stack Dijkstra accurate non-moving garbage collector) e invisible capabilities (cada ponteiro na memória possui capability correspondente, não visível para o espaço de de endereço C). Cada operação fundamental em C é verificada pela capability. Todos os erros de segurança de memória são capturados como Fil-C panics.
Já existe uma lista de programas que funcionando sendo compilados com o Fil-C com mínimas ou zero mudanças. Tanto que Filip criou sua própria distribuição From Scratch (baseado no Linux From Scratch 12.2) com suporte a segurança de memória chamada Pizlix onde Filip adiciona alguns componentes ao seu userland compilado com o Fil-C. O kernel do Pizlix é compilado com o Yolo-C.
O Fil-C está na versão 0.673 e sob licença Apache 2 (já que basicamente o Fil-C é um fork do LLVM), BSD 2-clause, MIT e GPL 2.1.
Pizlix: Memory Safe Linux From Scratch
Leia também Rust no kernel Linux: A guerra sem trégua
|
 |
Rust no kernel Linux: A guerra sem trégua |
Em 2023 eu escrevi o artigo Rust no Linux: Um caso de amor e ódio e depois dessa nova temporada de Rust no kernel, eu estava pensando em fazer um vídeo porém, como ando muito ocupado, preferi escrever aqui no blog mesmo.
Bom, a treta de Rust no kernel Linux continua. Tentaram de todas as formas e contra todos os gostos promover Rust no kernel Linux, houve resistência por parte de muitos desenvolvedores e até mesmo de Linus Torvalds mas por fim, foi feita a adoção. Depois disso houveram novos problemas, o principal responsável por Rust no kernel saiu do projeto e em Fevereiro desse ano, começou o processo tudo de novo; ninguém dá trégua nessa bagaça. Muitos desenvolvedores não apoiam sua adoção mas a cartada final dada por Greeg Kroah-Hartman:
"Adicionar outra linguagem não deveria ser um problema, já lidamos com coisas muito piores no passado."
"Sim, bases de códigos de linguagens mistas são grosseiras e difíceis de manter, mas somos desenvolvedores de kernel, droga. A gente vem mantendo e fortalecendo o Linux por mais tempo que qualquer um já pensou que fosse possível"
Não tem como discordar do Gregg nesse ponto já que nós sysadmins passamos bastante por situações parecidas, mas alguns até mesmo abandonaram o desenvolvimento como Karol Herbst que deixou o desenvolvimento do driver nouveau depois que adotaram o driver Nova como substituto do Nouveau; Christoph Hellwig bateu de frente com todos (inclusive com Linus) e esse debate parece não tem fim.
Estamos em um período de transição na tecnologia onde novos processadores, novos chips e novas linguagens estão surgindo. Muito se fala hoje em dia sobre segurança de memória (apesar que este assunto já dura mais de 30 anos) e seus benefícios; Em 2017 foram reportados cerca 40 CVEs somente do kernel Linux relacionados a falhas de segurança de memória. Então, se for para o bem, sim eu acredito que uma linguagem que possua recursos relacionados a segurança de memória deva ser adotada no desenvolvimento do Linux, mas Rust não é esta linguagem; outras linguagens são muito mais interessantes para se integrar ao kernel Linux do que Rust, como é o caso de Lua e Nim. Bom, o argumento que podem apresentar é que Lua é uma linguagem interpretada por scripts. Sim, porém o NetBSD possui drivers escritos em Lua, o carregador de boot do FreeBSD é escrito em Lua e o interpretador do rpm é escrito em Lua:
Lua é uma linguagem que facilmente se comunica com a linguagem C e C se comunica com tudo; geralmente é comum incorporar códigos C a alguma aplicação Lua para se comunicar com outras coisas. Lua na verdade já nasceu tendo como uma de suas características ser amigável com a linguagem C; inclusive um dos melhores recursos da linguagem Lua é exatamente o design de sua API que lhe permite integrar seu código a bibliotecas C ou fazer com que scripts Lua sejam executados de forma muito rápida junto ao código C dos jogos. Alias, se precisar portar seu código Lua para C, se torna uma tarefa muito mais fácil do que qualquer outra linguagem. E SIM, LUA POSSUI SUPORTE A SEGURANÇA DE MEMÓRIA!
Eu conheci Lua por volta de 2007 ou 2008 em um PDF como uma linguagem para integrar a linguagem C e fazer coisas que a linguagem C não faz; depois eu descobri que Lua já era amplamente utilizada em muitas aplicações como desenvolvimento da maioria dos jogos (inclusive liderando a parte de scripts de jogos e já até ganhou prêmios na parte de jogos), aplicações industriais, estações espaciais e petrolíferas, sistemas embarcados, os sites Wikipedia e Github são implementados em Lua, Netflix faz forte uso de Lua, Adobe Photoshop Lightroom, Ultradefrag, VLC, nmap, wireshark (1, 2), snort (1, 2), Metaplace, teclados da Logitech. Lua é um grande caso de sucesso e mais presente do que imaginamos sem essa necessidade de propaganda e comoção que foi feito em cima de Rust.
Nim é outra linguagem muito mais apropriada e interessante para o kernel Linux (existem ao menos dois sistemas operacionais escritos em Nim) e seus recursos únicos, que eu vou descrever mais a frente, são muito mais interessantes do que Rust.
Muitos projetos se beneficiarão de Rust e há exemplo real disso que é o caso do Android que se beneficiou de Rust tendo redução de 76% para 24% de seus bugs; por outro lado o port do fish shell de C++ para Rust não resultou em nenhum benefício, não entregou nenhum novo recurso e quando estes surgiram, não estavam vinculados a linguagem Rust... já por outro lado, outros projetos poderão ser afetados ao adotar Rust tanto que há programas que estão sendo migrados de Rust para outras linguagens como é o caso do gerenciador de pacotes da distribuição Glaucus Linux que foi portado de Rust para Nim (sintax mais simples e mais fácil de manter, melhor desempenho e menos uso de memória, de CPU) e a linguagem Roc que está sendo reescrita de Rust para Zig pela sua eficiência no processo de compilação ser maior e possuir menos dependências (1; 2. Valeu Nilton por compartilhar estas informações); o projeto Prisma que migrou de Rust para JavaScript e que tornou seu código 90% menor, mais de 3,4 vezes mais rápido, utilizar menos uso de CPU, ter menos complexidade no deploy e mais fácil de a comunidade fazer contribuições (23 de Julho de 2025: Prisma ORM Rust to TypeScript Migration: Rationale, Benchmarks, & GA launch, Prisma ORM without Rust: Latest Performance Benchmarks). Outro grande exemplo de projeto que foi prejudicado ao adotar Rust é o Ubuntu que ao adotar o Rust coreutils, teve seu desempenho afetado em até 17 vezes se comparado com as ferramentas tradicionais.
É questão de adotar o que se adéqua ou não a necessidade corretamente (aprendam isso). Honestamente, esta terceira opção é a mais provável que venha acontecer com o kernel Linux. Sim, eu vejo isso acontecer e sou bem pessimista quanto a Rust.
Não é de hoje que tentam substituir a linguagem C como menciona o próprio autor da linguagem C Plus Prolog (ou simplesmente C+P) que descreve sobre a linguagem C como sendo a única linguagem útil* (*portável, com desempenho que mais se aproxima de Assembly e consegue se comunicar com tudo) e que cientistas vem tentando há quase 50 anos encontrar uma solução para (digamos) substituir a linguagem C. E alguns até criaram C mais parecida com a linguagem Prolog e outros criaram o inverso, Prolog parecido com C."
O grande problema não é a linguagem Rust, o problema é mais uma questão psicológica. Os usuários estão querendo adotar Rust de forma eufórica e irracional, sem pesar na balança as vantagens e desvantagens assim como todas as linguagens possuem, sem pensar nas consequências; só estão querendo adotar acreditando que Rust é a oitava maravilha do mundo que solucionará todos os problemas da humanidade. A maioria não são desenvolvedores e os que são, além de nunca nem mesmo terem explorado o real potencial da linguagem C, estão cheios de amores por Rust... Rob Landley, autor do toybox que eu sempre menciono, disse em seu artigo de 21/09/2024 da melhor forma:
"Eu desisti de Rust porque todo puritano de Rust que eu encontro há anos trata NÃO escrever código em Rust como um pecado... ...A multidão "all must rust away" não conseguem explicar as vantagens de Rust a não ser "não é C"...
A única coisa que vemos é essa frescura de "rewrite in Rust", o que é uma bela de uma burrice já que o kernel Linux possui quase 1 Gigabyte somente de código na linguagem C. Levariam vários anos só para porta-lo para Rust e mais muitos outros anos somente para torna-lo estável (reescrever drivers será uma mão de obra intensa e que introduzirá mais problemas do que soluções — reescritas sempre introduzem bugs). Por vezes eu já vi desenvolvedores sugerir aos desenvolvedores de Rust desenvolverem as mesmas soluções do zero ao invés de ficarem querendo reescrever tudo em Rust. O autor da linguagem Hare sugeriu:
"Um grupo motivado de talentosos desenvolvedores de sistema operacional em Rust poderiam construir muito rápido um kernel compatível como Linux do zero e sem necessidade de se envolverem na política LKML"...
"Eu acho que se o montante de esforços sendo colocados no Rust-for-Linux fossem aplicados em um novo sistema operacional compatível com Linux, poderíamos ter algo pronto para produção para alguns casos de uso dentro de alguns anos."
..."desenvolver um sistema operacional baseado em um design comprovado como o do Linux é muito mais fácil e pode ser feito muito rápido. Eu trabalho em meu próprio sistema operacional de novo design (um microkernel) há alguns anos e ainda está travado no design e precisa urgentemente ser repensado; por outro lado eu escrevi um clone aceitável do Unix em menos de 30 dias."
O MIT também já desenvolveu um kernel assim chamando Biscuit o e apresentou no Usenix de 2018. Biscuit é kernel monolítico POSIX escrito na linguagem Go e é tão compatível com Linux que roda as aplicações do próprio Linux sem nenhuma necessidade de modificação do código fonte das aplicações. Por que a galera de Rust não acata essa proposta? Outro grande exemplo de escrever algum programa do zero e não de porta-lo é o bzip2; no meu artigo Qual o futuro do Bzip2? descrevi que os novos mantenedores foram questionados se portariam bzip2 para Rust, o que foi respondido que eles preferem trabalhar no suporte a multithreading em C, que para Micah é algo que seria muito interessante principalmente nas futuras versões 1.2 ou 2.0, do que qualquer coisa em Rust (lembram-se que eu mencionei que muitos que estão cheios de amores por Rust nunca nem mesmo exploraram o real potencial da linguagem C? Aqui está uma prova disso) e por fim foi indicada a implementação do Bzip2 em Rust desenvolvida do zero.
Lanldey também argumenta sobre o desenvolvimento de um sistema operacional escrito em Rust do zero e ainda apresenta a percepção das intenções da comunidade Rust:
"Se quizerem escrever um novo sistema operacional inteiramente em Rust, com kernel e userspace e toolchain, tudo em Rust, eu respeitaria isso e desejaria tudo de bom para eles. Mas não é o que eles querem. eles acreditam que lhes é devido Linux e eles querem sequestrar Linux (ainda que majoritariamente escrito em C)"... ..."E eles acreditam que ADICIONAR COMPLEXIDADE ADICIONAL resultará em sistemas melhores"
Sim, essa é percepção que se passa; não é que querem ter uma linguagem secundária no kernel Linux com a intenção de melhorar sua segurança e sim de aos poucos dominar o kernel substituindo todo o código por Rust para se autopromover. Rescrever algo em Rust pode se tornar uma cilada; imaginem a complexidade será reescrever o código rust para outra linguagem; você pode acabar ficando atrelado a ela (coincidência ou não, já vi desenvolvedores reclamando de coisas parecidas do projeto GNU).
O que esquecem de nós contar é exatamente os contras da linguagem: Curva de aprendizado terrível; difícil de debugar; complexa (não é a toa que o autor do minibase diz que o Rust coreutils o forneceu uma grande inspiração por lhe mostrar como não escrever o coreutils); tempo de compilação enorme; ecossistema pequeno; otimizada para a maioria dos processadores i686 e x86_64 porém, em outras plataformas como armel, armhf, armv7, mips{64}, powerpc{64} e riscv{64} carece de suporte de primeira classe, fora "recursos" de Rust que podem causar erros e bugs no LLVM; utilizar HLL pode causar perdas de desempenho, uso excessivo de CPU, memória e I/O; foram o tamanho dos biários ser enorme.
 |
| Diferença de tamanho dos binários UUtils e toybox |
.jpg)
Se gabam unicamente de segurança de memória sem mencionar à que custo... E tudo tem um custo. O artigo The benefits and costs of writing a POSIX kernel in a high-level language faz uma ótima análise descrevendo os benefícios de escrever seus programas e sistemas operacionais em linguagens com segurança de memória ao custo de sacrificar o desempenho que foi de 5% a 15%. Segurança de memória pode também afetar os seus programas; o autor da linguagem C3 descreve em seu artigo Por que eu parei tudo e comcei a escrever em C de novo:
"...Quem consegue escrever um jogo de estratégia com milhares de units cada tendo sua própria versão de mundo sem ter um garbage collector rodando o inferno? De fato meu amigo tentou escrever o jogo e falhou. Garbage collectors são péssimos e todos os meu projetos em Lisp possuem aplicações muito limitadas apenas por causa do garbage collector. ..."
Ok, o segundo argumento que podem querer apresentar é que Rust não utiliza garbage-collection por acreditarem não ser um recurso eficiente. Ao invés disso, Rust aplica a técnica de analisar o código fonte durante o processo de compilação para garantir que não haja brechas de segurança; PORÉM este tipo de recurso já é empregado na linguagem C há muito, mas muito tempo. A biblioteca dietlibc emprega ao menos seis linker warnings (avisos) durante o processo de compilação para ajudar os desenvolvedores escrever melhores códigos:
E esse é um dos grandes problemas; Rich Felker, autor da biblioteca musl, descreveu em seu artigo intitulado Overcommit que "há um monte de mal entendidos relacionados a gerenciamento de memória no Linux que levam à um monte de programas ruins que falham de forma robusta com condições de baixa memória e geram mitos". OK, gerenciamento de memória e segurança em memória são coisas diferentes, mas a mesma situação se aplica-se a ambos os casos, ou seja, não vai adiantar nada adotar outra linguagem se os desenvolvedores não souberem tratar corretamente seus códigos.
Falando em musl, além de também fazer a mesma coisa por trabalhar com o conceito de quality safe code (visando ser correta no senso conformidades padrões e segurança) é utilizada para encontrar bugs através do recurso fail-safe da biblioteca.
A Red hat adicionou a flag -FORTIFY_SOURCE aos compiladores GCC e Clang para detectar falhas como buffer over flow (1). O GCC também possui (desde 1998) a extensão StackGuard que é uma Stack Smashing Protection (SSP) (1) que ajuda o compilador detectar e prevenir ataques buffer-overflow que alias, o OpenBSD faz forte uso deste recurso.
O tinycc possui a opção -b (bound checker) há no mínimo 15 anos... E o GCC há uns 10... E se perguntar para boa parte dos que estão estão com fascínios por Rust, eles nem sabem disso...
 | ||
Bound checker no tinycc
|
 |
| Opção -b em invoke no manual do tinyCC |
Fora o recurso ASan (AddressSanitizer) que é um plugin detector de erros de memória para C/C++ utilizado inclusive no Google Chrome do Android, no Chrome OS, simulador do iOS, Linux, Mac, e Windows de 64 bits e disponível no LLVM há mais ou menos uns 15 anos (1, 2, 3), -fstack-protector, -fsanitize=safe-stack, UBSan (-fsanitize=bounds) e o SafeCode. Alias, a própria Wiki do ASan sugere o uso da ferramenta como cgroups para limitar o consumo de memória. Por que não incluir Pledge a esta lista? Ou seja, existem vários mecanismos para se utilizar somente com a linguagem C, mas a solução que encontraram foi adotar outra linguagem que pode gerar uma série de outros problemas... ... ... Enquanto isso Rust possui um recurso chamado unsafe que a galera de rust se refere como o "segredinho sujo" que eles utilizam em todos os lugares mas está tudo bem... São eles que estão usando... não é?
Está certo que utilizar recursos como verificação do código fonte acaba gerando binários um pouco maiores por acabar adicionando mecanismos de segurança, mas em Rust isso tinha que ser tão exagerado? O Rust coreutils por exemplo, contendo apenas apenas 87 comandos e sendo linkado dinamicamente, possui o tamanho de mais de 12MB enquanto o toybox, sendo linkado estaticamente e contendo 233 comandos (quase três vezes mais que o Rust Coreutils), ocupa apenas 724KB (mais de 17 vezes menor levando em conta sua ligação estática e a quantidade de comandos). Já houve quem dissese que isso acontecem em Rust apenas em X86 por conta das dependências e não ocorre em embarcados. O que não é verdade pois geralmente Rust gera binários praticamente do mesmo tamanho.
O interessante mesmo é poder decidir quando utilizar segurança de memória. No livro Nim in action descreve que algumas linguagens de programação, como C, não possuem segurança de memória porque ela permite que programas sem atribuição possa acessar a memória. Por outro lado, linguagens possuem segurança de memória oferecem essa segurança ao custo de não permitir que programas acessem detalhes de baixo nível da memória quando se faz necessário; e é aí que Nim se torna uma linguagem muito interessante. Por padrão Nim já oferece proteção contra erros de memória porém, porém Nim oferece as duas opções (escrever códigos com ou sem segurança de memória) permitindo que você decida quando utilizar cada uma delas. Ainda no livro Nim in Action descreve que "...há situações quando muitos querem evitar garbage collectors; eles são considerados por muitos ser inadequados para certas aplicações como embarcados e jogos. Por essa razão, Nim possui suporte a um número diferente de garbage collectors com diferentes aplicações em mente. Garbage collector pode também ser removido completamente, lhe dando a habilidade de você mesmo gerenciar memória." ... "Aplicações escritas em Nim são muito rápidas, em muitos casos, tão rápidas quanto aplicações escritas em C, e mais de trinta vezes mais rápido do que aplicações escritas em Python. Eficiência é maior prioridade, e alguns recursos toram otimização de código fácil. Isso vai de mãos dadas com um soft real-time garbage collector, que lhe permite especificar o montante de tempo que deve ser gasto coletando memória. Esse recurso se torna importante durante desenvolvimento de jogos, onde um garbage collector comum pode desacelerar a renderização de frames na tela se utilizar muito tempo coletando memória. Também é útil em sistemas real-time que precisam rodar em frames de tempo muito estrito." Nim, além de por padrão já proteger seu programa contra todos os tipos de erro de memória, possui também recursos muito mais interessantes como meta programação, style intensitivity; seu type system (que apesar de ser estática, incorpora o recurso type inference que lhe permite acelerar o desenvolvimento do seu código sem sacrificar a segurança), type safety e type-checking dinâmico; Generics (que lhe permite reutilizar o código sem sacrificar type safety) e muito mais.
(13/08/2025) Linguagens como C e C++ possui suporte a segurança em memória, mas algo que é feito manualmente. Os desenvolvedores que devem verificar seus próprios códigos e identificar o problema (algo que já vimos aqui Rich Felker denunciando). Os desenvolvedores do Busybox por exemplo fazem isso muit bem, no dia 03/08/2025, Denys Vlasenko corrigiu o vazamento de memória causado pela otimização do compilador.
Vale ressaltar que essas técnicas de memory safety também são possíveis na linguagem C e C++ não somente manualmente como muitos acreditam mas também através de garbage collector para C e C++ que foi desenvolvido pelos três pesquisadores Hans-J. Boehm, Demers e Weiser (por isso o nome bdwgc) em meados da década de 90... Este recurso lhe permite utilizar garbage collector nas duas linguagens quando quiser bastabdo definir #include "gc.h" em seu código. O bdwgc também oferece o recurso Leak Detector.
(28/03/2025) No dia 26 de Fevereiro de 2025 a equipe de desenvolvedores do XFS implementou o recurso garbage collection no zoned do XFS todo desenvolvido em C (e que vai para o kernel 6.15-rc). E no dia 19 de Março foi adicionado a opção gc_pressure no mount do XFS para evitar um risco no garbage collection em circunstancias distintas. O que nos leva a questionar se realmente se faz necessário a adoção de uma linguagem secundária no kernel Linux somente pelo recurso de segurança em memória ao custo de perda de desempenho, binários enormes, alto consumo de memória, CPU e etc sendo que tal recurso já está presente de tantas formas (linguagens mais adequadas, algoritmos, bibliotecas, flags, extensões), há tanto tempo (uns há quase trinta anos) e que já poderiam estar sendo empregados...
 |
| Garbage Collection no zoned do XFS |
 |
| Garbage Collection no f2fs |
E o mais interessante de tudo: Se lembram do artigo da Casa promovendo que todos deveriam migrar de linguagens como C e C++ para linguagens com segurança de memória? Pois é, estranhamente parece que a Casa Branca voltou atrás e não vai mais promover segurança de memória já que o mesmo link está indisponível.
Bom, eu acho que agora sim neste segundo artigo eu tenha abordado elementos o suficiente para pensar no assunto; o assunto de segurança em memória vai muito além do que simplesmente adotar uma linguagem com tal recurso achanado que solucionará os problemas de forma definitiva.
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
 |
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
 |
Lançado Nim 2.2.2 |
A equipe da linguagem Nim anunciou no dia 05 de Fevereiro de 2025 o lançamento da versão 2.2.2; quatro meses após o lançamento da versão 2.2.0 e contem 203 commits, trazendo bugfixes (um total de 35) e melhorias. A lista completa de mudanças está disponível aqui.
A versão Nim 2.2.2 pode ser baixada diretamente neste link ou através do comando choosenim (garanta somente que a versão do choosenim é a 0.8.5 ou superior):
$ choosenim update self
$ choosenim update stable
Nim version 2.2.2 released - Nim Blog
Leia mais sobre a linguagem Nim clicando aqui
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
|
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
 |
Hare: Uma nova linguagem C? |
Assim como C, Hare pode ser utilizada para escrever sistemas operacionais, ferramentas de sistemas, software de rede de computadores e várias outras ferramentas de baixo nível e de tarefas de alto desempenho. Já existem relatos de sistemas operacionais escritos em Hare como o sistema operacional microkernel Helios inspirado no seL4 e um clone do Unix chamado Bunix que por ter sido inspirado no design do Linux, levou menos de 30 dias para um único desenvolvedor escrevê-lo e aprender bastante coisas sobre sistemas operacionais de kernel monolítico.
 |
| Processo de boot do Bunnix |
Outros projetos também já foram implementados em Hare como OpenGL, Raytracer, gerenciador de senha, ferramenta de criptografia, bindings para GUIs simples, um substituto para o cron, um shell rc inspirado na implantação do plan9 e muito mais.
Outra característica é que Hare compartilha alguns recursos da linguagem Go como defer e design de biblioteca. Um fator que acredito que poderia atrair mais usuários e desenvolvedores para a linguagem Hare seria a adicionar as macros que não foram possíveis adicionar na linguagem C e assim dando origem a linguagem Odin.
Hare está disponível sob os termos da the Mozilla Public License (MPL) e é tão pequena que cabe em um floppy disc de 3½". Ainda está na versão 0.24.2 e só entrará para uma versão comercial quando chegarem na versão 1.0.
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
|
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
 |
Lançado Nim 2.2 |
No dia 02 de Outubro, a equipe da linguagem Nim anunciou o lançamento da tão esperada versão 2.2 conforme descrito no lançamento da versão 2.0.6. Na verdade foram lançadas duas versão; a 2.2 como nova versão estável e a 2.0.10 como patch release da 2.0.
VALE LEMBRAR QUE ESSE MÊS ACONTECERÁ A NIMCONF 2024
A versão 2.2.0 contem quase 1000 novos commits trazendo melhorias no gerenciamento de memória ORC, na linguagem, no compilador em si e 80 desses commits são relacionados a bugfixes. Dessas correções estão relacionadas ao generics, typedesc (em particular em expressões arbitrarias para types) e static types (em particular valores em generic types) tornando esses recursos estáveis. Houveram melhorias também no C++ interop; seu backend em java script agora possui suporte a lambda lifting para closures e closure iterators. Methods agora possuem suporte a implementações baseadas em um VTable ao utilizar --experimental:vtables; tuple unpacking agora ficou mais poderoso possuindo suporte a underscores para descartar valores:
var a, c: int
(a, _, c) = (1, 2, 3)
Suas declarações de variáveis agora possuem suporte a declarações type annotations, mas somente para tuple inteiro.
let (a, b): (int, int) = (1, 2)
let (a, (b, c)): (byte, (float, cstring)) = (1, (2, "abc"))
Um switch experimental --experimental:openSym foi adicionado para lidar com erros de capturas de símbolos dentro de generic routines & templates. Para autores de macro, ele adiciona um novo node kind nnkOpenSym que pode precisar ser tratado de forma diferente (similar ao nnkOpenSymChoice).
O Nim 2.2.0 embarca o Nimble 0.16.1 que funciona parecido com o cargo na linguagem Rust.
Nim versions 2.2.0 and 2.0.10 released - Nim Blog (nim-lang.org)
Adquira o livre Mastering Nim: A complete guide to the programming language clicando aqui
Mais sobre a linguagem Nim pode ser conferido aqui no blog
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
|
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
 |
Acelerando o desenvolvimento do Kernel com virtme-ng |
Andrea demonstra que grande parte do processo de desenvolvimento do kernel é geralmente dedicado a instalá-lo, rebootar o sistema, testá-lo, debuga-lo, coletar resultados e repetir essa mesmo operação que é muito lento e desgastante.
O virtme-ng fornece uma base para bootar o kernel recompilado ou qualquer outra imagem do kernel dentro de um ambiente copy-on-write virtualizado no sistema atual. O virtme-ng é escrito na maior parte em Python e faz uso de ferramentas como QEMU ou KVM, virtiofs, e overlayfs para esta finalidade.
A ideia é simplificar o trabalho dos desenvolvedores do kernel criando um sendbox para teste que ofereça desempenho próximo do ambiente real sem a necessidade de um ambiente de teste. Nesse Webinar será demonstrado como utilizar o virtme-ng com exemplos práticos e cenários reais.
Clique aqui para se registrar do evento da linuxfoundation.org
Mais sobre o virtme-ng pode ser lido no LWN.net
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
|
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
|
Lançado Nim 2.0.8 |
Há mais ou menos 10 dias foi lançada a versão 2.0.6 da liguagem Nim. No dia 03 de Julho de 2024 a equipe da linguagem lançou a versão 2.0.8 (seu quarto patch release) contendo 20 commits e trazendo melhorias importantes.
Agora o alocador Nim é muito mais estável com a opção --threads:on; possui melhor suporte ao gcc14, otimização de setLen(0) para strings e seqs ilimitados; otimização de move for utilizado com --mm:refc. Também houveram oito correções de bugs.
A lista completa de novidades pode ser conferida clicando aqui.
Open Collective ou via Bitcoin: 1BXfuKM2uvoD6mbx4g5xM3eQhLzkCK77tJ. Outras duas formas são através de suporte comercial e adquirindo o livro Mastering Nim: A complete guide to the programming language (English Edition) pode ser adquirido clicando aqui.
Há outros títulos de livros da linguagem Nim que podem ser conferidos clicando aqui
Mais sobre a linguagem de programação Nim pode ser conferida aqui no blog
|
| QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :) |
|
| E não esqueçam de conferir também o meu mini curso de atributos no Linux |
