<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
        <title><![CDATA[Márcio Sobel - Blog]]></title>
        <description><![CDATA[falando abobrinhas online]]></description>
        <link>https://blog.marciosobel.dev</link>
        <image>
            <url>https://blog.marciosobel.dev/rss_icon.png</url>
            <title>Márcio Sobel - Blog</title>
            <link>https://blog.marciosobel.dev</link>
        </image>
        <generator>RSS for Node</generator>
        <lastBuildDate>Wed, 17 Jun 2026 12:28:43 GMT</lastBuildDate>
        <atom:link href="https://blog.marciosobel.dev/pt/feed" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[Astro vs. Nuxt: Qual você deveria usar para o seu blog?]]></title>
            <description><![CDATA[Se você está querendo iniciar um blog, provavelmente vai se deparar com essas duas opções tão populares. Neste post, vou dissertar sobre os pontos positivos e negativos de cada um.]]></description>
            <link>https://blog.marciosobel.dev/pt/astro-vs-nuxt</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/pt/astro-vs-nuxt</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Olá! Nesses últimos dias, eu dei uma olhada no <a href="https://astro.build/">Astro</a>, uma framework para websites que tem como seu foco principal o conteúdo; ou seja, ela foi feita pensando diretamente em artigos, documentações e blogs.<br />O maior benefício dela é dado pelo Javascript <em>mínimo</em>. Isso me chamou muita atenção. Eu comentei <a href="https://blog.marciosobel.dev/pt/my-first-blog-post/">no meu primeiro post</a> que havia pensado bastante entre usar o Astro ou <a href="https://gohugo.io/">Hugo</a> para o meu blog, mas acabei escolhendo o <a href="https://nuxt.com/">Nuxt</a> por ser uma framework feta para construir websites do zero, o que me daria mais flexibilidade para moldar o site para ficar no meu estilo.<br />Entretanto, decidi testar o Astro, e ver o que seria dele para mim. Quem sabe eu não o uso no lugar do <code>Nuxt</code> nesse blog?<h2>Por que Astro?</h2>Logo de cara, o que mais me chamou atenção no Astro foi seu foco em conteúdo estático. Isso significa que ele não foi feito para ter muita interatividade: botões, requisições, formulários... Ele foi feito para coisas que mudam <em>muito pouco</em>, como documentação, artigos, <em>landing pages</em> e blogs.<br />Ele possui suporte <em>first-level</em> para Markdown, linguagem que uso para escrever os meus posts. Também, ele evita ao máximo enviar código Javascript para o usuário; isso significa que os sites sempre são super leves.<br />Bom, eu decidi testar o Astro pois eu fiquei com uma pulga atrás da orelha em relação ao <code>Nuxt</code>: ele leva consigo o runtime de Javascript do <code>Vue</code> junto. Apesar de ser pouca coisa, eu queria que o meu blog fosse o mais simples e leve possível. E assim começou minha jornada!<h2>Recriando o meu blog com Astro</h2>Vamos lá, primeiro vamos ver o que eu quero conseguir aqui.<ul><li>Escrever meus posts em Markdown e não me preocupar com como eles vão parar no site; quero apenas escrever, subir na nuvem e o build do Astro deve atualizar a listagem e gerar os links de acordo;</li><li>Ter o site em dois ou mais idiomas.</li></ul><br />É, o blog é bem simples; mas, acredito que, com essas exigências, vai dar para sujar bem as mãos na framework.<h3>Dando início ao projeto</h3>Essa é a parte mais fácil e a mais direta de toda essa jornada. Só precisei rodar:
<pre class="code "><code>pnpm create astro@latest</code></pre>
E seguir o passo a passo do robôzinho cuti cuti.<br />A arquitetura é bem simples, rotas baseadas por arquivos... Tudo super intuitivo. Eu não usei nenhum template, então para mim só tinha um <code>index.astro</code>, com a tela toda em branco, apenas com um <code>h1</code> escrito "Astro".<br />Bom, vamos começar a riscar alguns itens da lista.<h3>Listando todos os posts</h3>Comecei criando uma pasta <code>posts/</code>, e coloquei os posts do blog nela. Como o Astro já foi feito pensado em lidar com posts, então foi bem fácil. Basta criar um arquivo <code>content.config.ts</code> com o seguinte código:
<pre class="code typescript"><code class="language-typescript">const blog = defineCollection({
  loader: glob({ base: &quot;posts&quot;, pattern: &quot;**/*.{md,mdx}&quot; }),
});

export const collections = { blog };</code></pre>
Isso foi bem fácil. Eu usei o <code>zod</code> para criar um schema para os <em>frontmatters</em>, os metadados, dos posts.<br />Então, no arquivo <code>index.astro</code>, o <em>entrypoint</em> do website, eu coloquei o seguinte:<h2>```astro</h2>import { getCollection } from "astro:content";
const posts = await getCollection("blog");<h2>if (!posts) return Astro.redirect("/404");</h2><h1>Blog</h1>
<ul>
  {posts.map((post) => (<pre class="code poetry"><code>&lt;li&gt;
  &lt;a href={post.id}&gt;{post.data.title}&lt;/a&gt;
&lt;/li&gt;</code></pre>  ))}
</ul>
<pre class="code "><code>Eeeee isso funcionou? Foi muito fácil!

No Astro, qualquer código executado entre as &quot;fences&quot; (`---`) é executado apenas em *build time*. Isso significa que nossa aplicação até o momento está com um total de zero  Javascript!
### Gerando páginas dinamicamente
Após a criação da página de listagem de posts, eu queria criar uma página para cada post. Para isso, eu precisava de uma *rota dinâmica*, ou seja, precisaria que o Astro gerasse as páginas para mim.

Gostaria de aproveitar este momento e dizer que a documentação do Astro é muito boa! Definitivamente seria muito mais trabalhoso fazer isso sem ela.

Enfim, eu criei um arquivo `[slug].astro`. Este arquivo aceita qualquer valor como entrada, e eu posso usar esse valor via código.
```astro
---
const { slug } = Astro.params;
---
&lt;p&gt;Slug: {slug}&lt;/p&gt;</code></pre>
Então usei isso para pegar o ID de um post. Felizmente, o Astro já possui uma função específica para pegar um item de uma coleção: <code>getEntry</code>. Ela recebe a coleção e o ID para buscar. Após isso, precisava saber como mostrar o conteúdo <code>markdown</code> em <code>HTML</code>. Então me deparo com a função <code>render</code>, que útil!<h2>```astro</h2>import { getEntry, render } from "astro:content";
const { slug } = Astro.params;
const post = await getEntry("blog", slug);
if (!post) return Astro.redirect("/404");<h2>const { Content } = await render(post);</h2><Content />
<pre class="code "><code>E em teoria era para funcionar super bem... Mas o Astro não consegue saber todas as rotas possíveis para o `[slug].astro`, o que o impedia de deixar o site limpo de javascript. Para contornar isso, temos que dizer ao Astro **todas as rotas possíveis**. Fazemos isso exportando uma função `getStaticPaths`, que *felizmente* pode ser `async`, onde retornamos uma lista com todas as variáveis completadas. Também podemos passar props para cada página, o que significa que podemos passar todos os posts diretamente!
```astro
---
import { getCollection, render } from &quot;astro:content&quot;; // agora, pegamos a coleção inteira!

export async function getStaticPaths() {
  const posts = await getCollection(&quot;blog&quot;);
  return posts.map((post) =&gt; ({
    params: { slug: post.id },
    props: { post }, // podemos passar o post diretamente para a página!
  }));
}

const { post } = Astro.props; // E o post é garantido que existe!
const { Content } = await render(post);
---
&lt;Content /&gt;</code></pre>
Okay! Isso foi bem fácil.<br />Testando os diferentes posts, vi que um deles estava renderizando os acentos errado. Por exemplo, ao invés de da palavra <code>água</code>, o HTML renderizado retornava <code>Ã¡gua</code>. Fiquei confuso do motivo, e aparentemente o Astro não define mais o charset do documento como UTF-8 por padrão. Fiquei bem confuso pois <a href="https://docs.astro.build/en/guides/markdown-content/#frontmatter-layout-property">só vi isso sendo citado em um lugar das docs</a>? Mas tudo bem, perdi um tempinho nessa parte.<h3>Lidando com diferentes idiomas</h3>Caso você nunca tenha notado, este blog está disponível tanto em Português do Brasil, quanto em Inglês. Até o momento em que escrevo este post, todos os posts estão disponíveis nos dois idiomas. Não sei se em algum momento eles vão divergir e ter conteúdos diferentes.<br />Enfim, ter múltiplos idiomas é algo necessário. Como o bom programador que sou™, quis deixar dinâmico o suficiente para ter a menor dor de cabeça possível caso eu queira escrever em algum outro idioma. Primeiro, alterei o arquivo <code>content.config.ts</code> para ter os posts separados:
<pre class="code typescript"><code class="language-typescript">function createCollection(suffix: string) {
  return defineCollection({
    loader: glob({ base: `posts/${suffix}`, pattern: &quot;**/*.{md,mdx}&quot; });
  });
}

export const collections = {
  &quot;blog-en&quot;: createCollection(&quot;en&quot;),
  &quot;blog-pt&quot;: createCollection(&quot;pt&quot;),
};</code></pre>
E então criei um arquivo <code>i18n.ts</code> com o seguinte código:
<pre class="code typescript"><code class="language-typescript">const entries = {
  en: {
    &quot;all-posts&quot;: &quot;All posts&quot;,
  },
  pt: {
    &quot;all-posts&quot;: &quot;Todos os posts&quot;,
  },
};

export type Locales = keyof typeof entries;
export const locales = Object.keys(entries) as Locale[];
export const defaultLocale: Locale = &quot;en&quot; as const;

import { getCollection as getContentCollection } from &quot;astro:content&quot;;

export function getCollection(locale: Locale = defaultLocale) {
	return getContentCollection(`blog-${locale}`);
}</code></pre>
A arquitetura das páginas ficou assim:
<pre class="code "><code>src/
├── content.config.ts
├── i18n.ts
├── pages/
│   ├── [lang]/
│   │   ├── [slug].astro
│   │   └── index.astro
│   ├── [slug].astro
└── └── index.astro</code></pre>
E todo lugar que eu precisasse do idioma selecionado, foi só colocar <code>const { lang = defaultLocale } = Astro.params</code>.<br />Daí em diante, tudo funcionou perfeitamente bem. Eu criei um componente que coloca o sufixo do idioma no URL, e assim eu podia trocar de idiomas. Tudo funcionou perfeitamente e, até o momento, <em>zero</em> Javascript!<h3>Onde as coisas começaram a desandar...</h3>No Astro, o markdown é renderizado para um HTML. A renderização é bem básica: links viram <code>&lt;a&gt;</code>, headings viram <code>&lt;h1&gt;</code>, <code>&lt;h2&gt;</code>... Tudo normal. Acontece que eu queria uma pequena customização: se você quiser testar neste post, todo título é clicável. Eu deixei assim pois, caso alguém queira compartilhar apenas um tópico específico do post, é possível. Para isso, eu criei um componente de <code>Prose</code> no Nuxt, que me permite dar um <em>override</em> nas tags geradas com o markdown.<br />No Astro, entretanto, isso não é possível. Não de uma maneira simples. Eu tinha duas escolhas:<ol><li>Usar <code>MDX</code> para escrever os posts no lugar do markdown e chamar os componentes conforme necessários, ou;</li><li>Usar um plugin do rehype para alterar as tags no momento de renderização.</li></ol><br />Como não gosto de <code>mdx</code>, eu fui com a segunda opção. Acontece que isso gerou um código muito feio, pouco funcional (bugava muito) e que eu não ia entender poucos dias depois. Mas, tudo bem, eu o fiz ainda assim.<br />E pronto, após adicionar o  css, eu tinha uma réplica exata do meu blog, 100% funcional.<h2>Veredito e comparação</h2>Bom, o blog inteiro não ficou imune de Javascript. É possível pesquisar por posts e tem como alternar entre tema claro e escuro. Eu buildei o site e quis ver o quão pesado ele estava.<br /><blockquote>As métricas estão na medida <code>&lt;tamanho_comprimido&gt;/&lt;tamanho_real&gt;</code>. O site sempre será baixado comprimido e é descomprimido localmente. Você pode acessar o post de referência <a href="https://blog.marciosobel.dev/switching-to-nixos/">aqui</a>.  Todos os caches foram desabilitados nas medidas.</blockquote><br />Meu blog, com <code>Nuxt</code>, a listagem de todos os posts utiliza <strong>228 kB / 569 kB</strong>. Acessar um post utiliza <strong>351 kB / 657 kB</strong>.<br />A réplica, com <code>Astro</code>, na tela de listagem, utiliza <strong>164 kB / 166 kB</strong>. Acessar um post utiliza <strong>257 kB / 260 kB</strong><br />É possível notar que o Astro usa 28% menos rede que o Nuxt na listagem, e 27% menos ao visualizar um post, sendo a sua maior diferença nos dados descomprimidos, possuindo uma diferença de 71% na listagem e 60% ao visualizar um post!<h2>Conclusão: com qual framework vou ficar?</h2>A diferença no bundle final é certamente notável. O Astro entrega um site muito mais leve, apenas com o conteúdo que você escolhe entregar. Mas, apesar disso, eu decidi me manter com o Nuxt. Eis o motivo: eu gosto de mexer nas coisas de lá pra cá. Achei o Astro para este meu caso de uso pouco maleável, especialmente na parte de modificar o output do markdown. E, apesar dele ser bem mais leve, é apenas no conteúdo não comprimido; na parte de rede, a diferença não é tão gritante assim,. Os celulares e computadores hoje nem se esforçam direito para compensar essa diferença. Então aceito fazer esse sacrifício em troca de uma DX melhor.<br />Todavia, o Astro com certeza me conquistou com seu charme e simplicidade. Com certeza vou utilizá-lo para gerar documentação de possíveis libs minhas no futuro. Eu não cheguei a explorar todo o potencial dele e, se eu estivesse começando do zero, eu provavelmente pegaria um template e construiria a partir dele.<br />E esta foi minha review do Astro, espero que tenham tido uma boa leitura. Até a próxima!]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Porque eu troquei para o NixOS (E porque você também deveria)]]></title>
            <description><![CDATA[Recentemente, eu troquei para o NixOS, deixando todo o meu sistema declarativo. Nesse post, eu vou explicar os prós, os contras, e se migrar pode ser uma boa opção para você.]]></description>
            <link>https://blog.marciosobel.dev/pt/switching-to-nixos</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/pt/switching-to-nixos</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Sat, 28 Mar 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Oi! Recentemente, mudei para o <a href="https://nixos.org">NixOS</a> e foi uma das melhores coisas que já fiz. Meu sistema nunca esteve tão estável e, ao mesmo tempo, tão permissivo. Também sinto que tenho muito mais controle: o que está instalado, onde cada config fica, serviços ativos, daemons e por aí vai. O repositório <code>nixpkgs</code> é <strong><em>gigante<strong><em>. Sério: <a href="https://repology.org/repositories/graphs">ele é maior que o AUR</em></strong></em></strong></a>!<br />Vou explicar o porquê de ele ser tão bom, os pontos negativos e se você deve ou não usá-lo. Mas primeiro, vamos falar sobre o que sequer <em>é</em> o NixOS e como ele se destaca de outras distros Linux.<h2>O que é o Nix?</h2>Antes de falar do NixOS, deixe-me apresentar o <code>nix</code>. O <code>nix</code> é um <em>gerenciador de pacotes funcional</em>. Isso significa que ele trata pacotes como valores em uma linguagem de programação puramente funcional (como Haskell). Os pacotes não são instalados onde você esperaria (como em <code>/usr/bin</code>); em vez disso, eles vão para o <code>/nix/store</code>. E cada pacote tem seu próprio subdiretório exclusivo. Veja o Firefox, por exemplo:<br /><pre class="code "><code>/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/</code></pre><br />Esse hash (<code>b6gvzjyb...</code>) é o identificador único que captura todas as dependências desse pacote. Graças a esse sistema de hashing, você pode ter várias versões do mesmo pacote <em>ao mesmo tempo</em>, sem ter que lidar com conflitos de dependência ou quebras no sistema.<br />Além disso, devido ao identificador único, o <code>nix</code> consegue remover pacotes não utilizados usando um <em>garbage collector</em>. Isso significa que seu sistema sempre tem apenas o que você realmente quer!<h2>O que é o NixOS?</h2>O NixOS leva o gerenciador de pacotes <code>nix</code> ao limite, aplicando sua filosofia a um sistema operacional inteiro. Isso significa que seu kernel, drivers, resolução de monitor, aplicativos e configurações são todos descritos de maneira funcional e declarativa.<br />O sistema não segue os <a href="https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html">padrões FHS</a>, o que significa que não existe <code>/bin</code>, <code>/lib</code> ou <code>/usr</code>. Tudo o que ele contém está na <em>nix store</em>.<br />A configuração do sistema pode ser encontrada em <code>/etc/nixos/</code>, onde você verá dois arquivos:<br /><ul><li><code>hardware-configuration.nix</code>: Gerado automaticamente pelo sistema. Você provavelmente nunca precisará mexer aqui (pelo menos assim espero!).</li><li><code>configuration.nix</code>: Onde a configuração do seu sistema realmente mora. É aqui que você diz ao Nix quais pacotes devem estar instalados, quais serviços ou daemons devem rodar, qual interface de desktop usar, etc.</li></ul><br />Aqui está um exemplo de como instalar o <code>git</code>:
<pre class="code nix"><code class="language-nix"># configuration.nix
{
	# ...
	environment.systemPackages = [pkgs.git];
}</code></pre>
...E é isso. Se você quiser desinstalar, basta remover o <code>pkgs.git</code> da lista. Simples assim!<br />Contudo, salvar o arquivo não instalará o <code>git</code> sozinho. Isso seria um pesadelo. Você precisa <em>rebuildar</em> seu sistema. E digo isso literalmente. Rodar <code>nixos-rebuild</code> vai reconstruir todo o seu sistema do zero, instalando ou desinstalando qualquer pacote que você adicionou ou removeu, parando ou iniciando serviços, e assim por diante.<br />Isso pode parecer um pouco preocupante, mas não se preocupe! Graças à <em>nix store</em>, seu sistema faz um backup completo antes de cada rebuild. Então, se você por acaso deletar seu driver de vídeo sem querer, pode simplesmente selecionar a build anterior no gerenciador de boot. Para reconstruir seu sistema, é só rodar:
<pre class="code "><code>nixos-rebuild switch</code></pre>
Isso vai reconstruir seu sistema e mudar para ele imediatamente (sem precisar reiniciar o computador). Você também pode voltar facilmente para a configuração anterior usando o argumento <code>--rollback</code>.<br />Se você quiser apenas ver como as mudanças afetam seu sistema sem criar um backup (como um rebuild "descartável"), pode simplesmente rodar:
<pre class="code "><code>nixos-rebuild test</code></pre>
Existem muitas outras formas de reconstruir seu sistema, até mesmo como criar uma VM, mas não vou falar sobre isso aqui. Além do mais, esses dois são provavelmente os comandos que você mais usará de qualquer maneira.<br />Bem, essa é uma explicação simples de como o <code>nix</code> e o NixOS funcionam. Você provavelmente vai querer se aprofundar, e para isso não posso recomendar outro canal mais do que o <a href="https://www.youtube.com/@vimjoyer">Vimjoyer</a>. Lá, você encontrará mais sobre a linguagem <code>nix</code>, como criar módulos, como organizá-los e tudo mais.<h2>Você deveria migrar para o NixOS?</h2><h3>Prós</h3>Primeiro, vou falar para quem eu acho que o NixOS vale a pena:<h4>Desenvolvedores</h4>O NixOS oferece uma DX incrível. Ele suporta ambientes de desenvolvimento isolados e reproduzíveis, o que significa que o argumento "funciona no meu PC" agora realmente significa que funciona. Você pode pensar nisso como containers Docker, só que melhor! Além disso, você pode usar o NixOS para declarar a estrutura de um servidor, ou seja, se você mudar de arquitetura (trocando de host, por exemplo), pode ter todas as suas configurações e serviços ativos em segundos apenas copiando o arquivo <code>configuration.nix</code> da máquina antiga!<h4>Entusiastas</h4>Se você gosta de explorar tecnologia, fazer <em>ricing</em>, criar suas próprias configs ou apenas fuçar em geral, o NixOS é um prato cheio! Ele é familiar o suficiente para você se sentir confortável, mas diferente o suficiente para manter as coisas interessantes e divertidas de mexer.<h3>Contras</h3>Agora, eu acho que o NixOS <strong>não</strong> é uma boa opção para você se:<h4>Você quer apenas que as coisas funcionem rápido</h4>Se você só quer baixar o VSCode e quer que ele funcione na hora, ou se você só usa o navegador, ou até se acha que configurar o Neovim sozinho dá "trabalho demais", então acho que o NixOS não é para você. Configurar o NixOS é tedioso e demora. Mesmo que você possa copiar o arquivo de outra pessoa para ter um ponto de partida sólido, acredito que não adaptar o sistema às suas próprias necessidades é um desperdício do potencial do OS e resultará apenas em uma experiência frustrante se você precisar mudar algo depois.<h4>Você é novo no Linux</h4>Se você é novo no mundo Linux, acho que o NixOS é demais para você. Vá explorar o Ubuntu, Mint ou até o Fedora. Depois, você pode mergulhar no Arch, Void ou NixOS. Entenda como o Linux funciona e como ele é construído para, então, ser capaz de ver como sistemas de baixo nível o moldam para extrair o máximo dele.<h2>Conclusão</h2>É isso! Talvez eu faça mais posts compartilhando as coisas que descubro no sistema. Enquanto isso, você pode encontrar meus <em>dotfiles</em> atuais <a href="https://github.com/marciosobel/dotfiles">aqui</a>. Até a próxima!]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Rust é a MELHOR linguagem de programação]]></title>
            <description><![CDATA[E eu posso provar.]]></description>
            <link>https://blog.marciosobel.dev/pt/rust-is-the-best-programming-language-ever</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/pt/rust-is-the-best-programming-language-ever</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Mon, 19 Jan 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Você já deve estar farto de ouvir que "Rust é seguro", "Rust é a linguagem de programação mais amada do mundo", "Rust é o futuro".<br />Apesar dessas afirmações possuirem bases concretas, pouco se fala sobre os <em>reais</em> pontos positivos do Rust. Vou citar alguns fatores positivos além da segurança, robustez e velocidade da linguagem.<h2>Modelo de Domínio claro</h2>Rust permite fazer a modelagem de um domínio de uma maneira clara e concisa. Os enums com superpoderes permitem definir regras que outras linguagens precisam de um boilerplate maior.<br />Vou dar um exemplo:
<pre class="code rust"><code class="language-rust">enum DownloadStatus {
    Inactive,
    Processing { progress: u32 },
    Error(String)
    Done,
}</code></pre>
Temos aqui um enum que nos dá informações sobre um download. Em outras linguagens, provavelmente seria necessário criar uma classe, com todos os metadados necessários (que podem ser <code>null</code>), e teria que fazer vários <em>workarounds</em> para fazer a checagem correta. Com o Rust, não só não tem como um metadado ser <code>null</code>, como também é muito fácil acessá-los, com a segurança de que estão sempre válidos.<h2>Switch statements poderosíssimos</h2>No universo da programação, o <code>switch</code> é usado para checar valores iguais. Na programação moderna, está se tornando cada vez mais abundante o uso de <code>match</code>: um novo <code>switch</code> que permite utilizar patterns para validações.<br />Aqui vai um exemplo de um <code>match</code> no Rust:
<pre class="code rust"><code class="language-rust">let value = 5;
match value {
    0..=10 =&gt; println!(&quot;Número entre 0 e 10!&quot;),
    11 | 13 | 17 | 19 =&gt; println!(&quot;Número primo!&quot;),
    n if n % 2 == 0 =&gt; println!(&quot;Número par!&quot;),
    n =&gt; println!(&quot;Não sei o que fazer com o número {n}&quot;),
}</code></pre>
Também é possível fazer <em>pattern matching</em> em um <code>if</code>. Utilizando o exemplo anterior de <code>DownloadStatus</code>:
<pre class="code rust"><code class="language-rust">let status = DownloadStatus::Error(&quot;Falha ao baixar&quot;.into());
if let DownloadStatus::Error(error) = status {
    eprintln!(&quot;Erro no download: {}&quot;, error);
}</code></pre>
Pode parecer apenas um <em>boilerplate</em> mas os <code>enum</code>s com esses <code>pattern matching</code>s tornam o código mais robusto e seguro conforme a codebase cresce!<h2>Mutabilidade explícita</h2>Outro ponto muito positivo do Rust é a sua mutabilidade explícita. Tudo é imutável por padrão:
<pre class="code rust"><code class="language-rust">let x = 10;
x = x * 2; // O código falha aqui</code></pre>
O código falha pois <code>x</code> é imutável. Para deixá-la mutável, temos que adicionar a keyword <code>mut</code>:
<pre class="code rust"><code class="language-rust">let mut x = 10;
x = x * 2;</code></pre>
Neste exemplo, não parece grande coisa. Mas é uma informação muito útil quando estamos falando de argumentos de funções:
<pre class="code rust"><code class="language-rust">let mut meuTexto = String::from(&quot;Olá, mundo&quot;);
printText(&meuTexto);
changeText(&mut meuTexto);</code></pre>
Fica claro se uma função vai alterar uma variável ou não. Em C ou Go, passar o endereço de uma variável deixa sua mutabilidade para a implementação da função, forçando o desenvolvedor a ler a documentação ou ver seu código.<h2>Macros!</h2>É possível fazer <em>metaprogramming</em> no Rust — ou seja, um código que escreve código Rust. Macros em Rust são praticamente uma linguagem nova, mas as crates <a href="https://crates.io/crates/syn"><code>syn</code></a> e <a href="https://crates.io/crates/quote"><code>quote</code></a> deixam o processo mais intuitivo e fluido, recomendo muito ver <a href="https://youtu.be/SMCRQj9Hbx8">esse vídeo</a> para entender melhor. Não vou me aprofundar muito em macros aqui, daria pra fazer um post inteiro só sobre eles (quem sabe um dia).<h2>Configuração em TOML</h2>Admito, eu <em>amo</em> <code>TOML</code>. Mais do que <code>YAML</code>, e infinitamente mais que <code>JSON</code>. É uma linguagem clara, mínima e você consegue ler toda a <a href="https://toml.io/en/v1.1.0">spec</a> em uns 15 minutos. Rust usa TOML para definir versão, dependências, features, configuração do formatter... É ótimo!<h2>Nem tudo são flores</h2>Claro, Rust não é perfeito. Principalmente no início, onde você tem que lutar contra seus fundamentos para programar em Rust. Ele possui vários problemas na DX, como verbosidade, compile-time longo (mesmo em debug), e nem me deixe encostar em lifetimes. Talvez eu faça uma versão maligna desse post só falando do lado ruim de Rust.<h2>Conclusão</h2>O Rust possui ótimos fundamentos, um sistema de macro maravilhoso e o <code>cargo</code> é sensacional. Com certeza é uma linguagem moderna, robusta, rápida e segura. Ganhar por vários anos consecutivos o título da linguagem mais amada do mundo não é surpresa. Espero que eu tenha conseguido cobrir alguns dos pontos da linguagem que mais gosto com clareza, além dos pontos óbvios de muitos outros posts da internet (a segurança, ser <em>blazingly fast</em>, etc.)<br />Caso esteja começando a usar Rust em algum projeto, lembre-se de deixar bem claro que o usa, como se fosse um usuário de Arch (btw). O culto deve se proliferar. 🦀]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Meu primeiro post]]></title>
            <description><![CDATA[Bem vindo ao meu blog!]]></description>
            <link>https://blog.marciosobel.dev/pt/my-first-blog-post</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/pt/my-first-blog-post</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Sun, 11 Jan 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Olá, seja bem vindo ao meu blog. Ainda estou começando, então provavelmente as minhas habilidades de escrita não vão estar tão altos haha. Contudo, estou muito feliz de finalmente ter um lugarzinho para postar minhas coisinhas.<br />Para um primeiro post, tentei pensar em algum assunto legal para "marcar" bem, mas isso só iria me fazer ficar em um loop infinito de ideias, então vou começar com...<h2>Como fiz esse blog</h2>O primeiro desafio foi pensar em <em>como escrever.</em> Acabei escolhendo markdown, pois já estou familiarizado com a escrita dele.<br />O próximo passo era escolher <em>onde escrever</em>. Há diversas opções (pensei bastante em usar Astro ou Hugo), mas, como queria ter mais controle sobre o site em si, acabei optando pelo Nuxt.<br />O Nuxt me permite não apenas ter controle da aparência do meu site, como também tem este <a href="https://content.nuxt.com/">módulo maravilhoso</a> que me permite colocar todos os posts em uma pasta, exatamente o que queria!<br />Outra coisa muito boa que o Nuxt me dá liberdade de fazer é organizar meus posts por idioma. Pretendo fazer posts em inglês e português (dependendo da força de vontade).<br />Também lembrei que uso Linux (Arch, btw.) e criei um symlink da pasta dos posts para o meu vault do Obsidian. Isso significa que posso escrever os meus posts diretamente dele!<br />Bom, até que a parte de criar o blog em si foi bem simples, parece que o que estava me impedindo de criar um era só... eu mesmo. Agora só preciso decidir...<h2>O que pretendo fazer por aqui?</h2>Um blog não é como um Twitter (atualmente X), Bluesky, Threads, ou qualquer rede social em que as pessoas postam atualizações; é um cantinho único, pessoal, sem algoritmos ou restrição de conteúdo.<br />Eu sempre tive esses momentos onde vejo algum assunto legal, ou eu faço algo que acho legal, mas acabo guardando pra mim, pois tenho gostos muito abrangentes que às vezes não se entrelaçam com o meu círculo social. Então escrever um blog seria um lugar onde eu posso só tagarelar sobre qualquer coisa, colocá-las numa caixinha e deixar solto. Vai que alguém se interessa!]]></content:encoded>
        </item>
    </channel>
</rss>