Como o Haskell moldou o design de linguagens modernas além da programação funcional

Por que o Haskell importa além da programação funcional

Haskell costuma ser apresentado como “a linguagem funcional pura”, mas seu impacto vai bem além da divisão funcional/não-funcional. Seu sistema de tipos estático e forte, a inclinação por funções puras (separando computação de efeitos colaterais) e o estilo orientado a expressões — onde o fluxo de controle retorna valores — fizeram a linguagem e sua comunidade levarem a sério correção, composabilidade e ferramentas.

Essa pressão não ficou confinada ao ecossistema Haskell. Muitas ideias práticas foram absorvidas por linguagens mainstream — não copiando a sintaxe superficial do Haskell, mas importando princípios de design que tornam bugs mais difíceis de escrever e refatorações mais seguras.

O que “influência” realmente significa

Quando se diz que Haskell influenciou o design de linguagens modernas, raramente se quer dizer que outras linguagens passaram a “parecer Haskell”. A influência é principalmente conceitual: design guiado por tipos, padrões seguros por padrão e recursos que tornam estados ilegais mais difíceis de representar.

Linguagens pegam os conceitos subjacentes e os adaptam às suas restrições — frequentemente com trade-offs pragmáticos e sintaxes mais amigáveis.

Por que linguagens não-funcionais adotam ideias do Haskell

Linguagens mainstream vivem em ambientes bagunçados: UIs, bancos de dados, redes, concorrência e grandes equipes. Nesses contextos, recursos inspirados em Haskell reduzem bugs e facilitam a evolução do código — sem exigir que todos “virem totalmente funcionais”. Mesmo adoções parciais (tipagem melhor, tratamento explícito de valores ausentes, estado mais previsível) costumam valer a pena rapidamente.

O que você vai tirar deste artigo

Você verá quais ideias do Haskell mudaram expectativas em linguagens modernas, como elas aparecem em ferramentas que você talvez já use e como aplicar os princípios sem copiar a estética. O objetivo é prático: o que pegar emprestado, por que ajuda e onde estão os trade-offs.

Tipos estáticos fortes como expectativa padrão

Haskell ajudou a normalizar a ideia de que tipagem estática não é só uma caixa do compilador — é uma postura de design. Em vez de tratar tipos como dicas opcionais, Haskell os trata como a principal forma de descrever o que um programa tem permissão para fazer. Muitas linguagens mais novas adotaram essa expectativa.

Tipagem estática como característica de produto

Em Haskell, tipos comunicam intenção tanto para o compilador quanto para outros humanos. Essa mentalidade levou projetistas a verem tipos estáticos fortes como um benefício para o usuário: menos surpresas tardias, APIs mais claras e mais confiança ao mudar código.

Desenvolvimento guiado por tipos: deixando tipos moldarem APIs

Um fluxo de trabalho comum em Haskell é começar escrevendo assinaturas de tipos e tipos de dados, então “preencher” implementações até que tudo passe na checagem de tipos. Isso estimula APIs que tornam estados inválidos difíceis (ou impossíveis) de representar e incentiva funções menores e compostáveis.

Mesmo em linguagens não-funcionais, você vê essa influência em sistemas de tipos expressivos, generics mais ricos e checagens em tempo de compilação que previnem categorias inteiras de erros.

Erros melhores e refatorações mais seguras como objetivo

Quando tipagem forte é o padrão, as expectativas sobre ferramentas aumentam. Desenvolvedores começam a esperar:

• mensagens de compilador acionáveis que expliquem por que o código está errado
• refatorações que falhem rapidamente em tempo de compilação em vez de quebrar em tempo de execução

O trade-off

O custo é real: há uma curva de aprendizado e às vezes você briga com o sistema de tipos antes de entendê-lo. O retorno são menos surpresas em runtime e uma trilha de design mais clara que mantém bases de código grandes coerentes.

Tipos algébricos de dados: modelos melhores para estados do mundo real

Algebraic Data Types (ADTs) são uma ideia simples com impacto desproporcional: em vez de codificar significado com “valores especiais” (como null, -1 ou string vazia), você define um pequeno conjunto de possibilidades nomeadas e explícitas.

Dois ADTs comuns: Maybe/Option e Either/Result

Haskell popularizou tipos como:

• Maybe a — o valor ou está presente (Just a) ou ausente (Nothing).
• Either e a — você obtém um de dois resultados, comumente “erro” (Left e) ou “sucesso” (Right a).

Isso transforma convenções vagas em contratos explícitos. Uma função que retorna Maybe User te diz de cara: “um usuário pode não ser encontrado”. Uma função que retorna Either Error Invoice comunica que falhas fazem parte do fluxo normal, não são um pensamento excepcional.

Por que ADTs vencem nulos e valores mágicos

Nulos e sentinelas forçam o leitor a memorizar regras escondidas (“vazio significa ausente”, “-1 significa desconhecido”). ADTs movem essas regras para o sistema de tipos, então elas ficam visíveis onde o valor é usado — e podem ser verificadas.

Por isso linguagens mainstream adotaram “enums com dados” (uma variação direta de ADT): enum do Rust, enum com valores associados do Swift, sealed classes do Kotlin e discriminated unions do TypeScript permitem representar situações reais sem adivinhação.

Dica de design: torne estados inválidos irrepresentáveis

Se um valor pode estar em apenas alguns estados significativos, modele esses estados diretamente. Por exemplo, em vez de uma string status com campos opcionais, defina:

• Draft (sem info de pagamento ainda)
• Submitted { submittedAt }
• Paid { receiptId }

Quando o tipo não pode expressar uma combinação impossível, categorias inteiras de bugs desaparecem antes do runtime.

Pattern matching e tratamento exaustivo de casos

Pattern matching é uma das ideias mais práticas do Haskell: em vez de espiar valores com uma série de condicionais, você descreve as formas que espera e deixa a linguagem direcionar cada caso para o ramo certo.

Legibilidade sem boilerplate

Uma longa cadeia if/else costuma repetir as mesmas checagens. Pattern matching transforma isso em um conjunto compacto de casos claramente nomeados. Você lê de cima para baixo como um cardápio de possibilidades, não como um quebra-cabeça de ramos aninhados.

Ramificações mais seguras com ajuda do compilador

Haskell empurra uma expectativa simples: se um valor pode ter N formas, você deveria tratar todas as N. Quando esquece uma, o compilador avisa cedo — antes dos usuários verem um crash ou um caminho de fallback estranho. Essa ideia se espalhou: muitas linguagens modernas podem checar (ou pelo menos encorajar) tratamento exaustivo ao fazer correspondência sobre conjuntos fechados como enums.

Onde aparece fora do “FP puro”

Pattern matching aparece em recursos mainstream como:

• Enums / sum types: match do Rust, switch do Swift, when do Kotlin, expressões switch modernas do Java e C#.
• Tratamento de erros: fazer match em resultados Result/Either em vez de checar códigos de erro.
• Manipulação de mensagens/estado: estados de UI como Loading | Loaded data | Failed error.

Quando preferir isso ao if/else

Use pattern matching quando você ramifica pelo tipo de valor (qual variante/estado ele é). Mantenha if/else para condições booleanas simples (“este número é \u003e 0?”) ou quando o conjunto de possibilidades é aberto e não será conhecido de forma exaustiva.

Inferência de tipos: menos ruído, mais intenção

Inferência de tipos é a habilidade do compilador de deduzir tipos por você. Você ainda tem um programa estaticamente tipado, mas não precisa escrever cada tipo explicitamente. Em vez de escrever “esta variável é um Int” em todo lugar, você escreve a expressão e o compilador deduz o tipo mais preciso que mantém o programa consistente.

Por que faz o código parecer mais simples (sem ficar mais arriscado)

Em Haskell, inferência não é um recurso de conveniência acoplado — é central. Isso mudou o que desenvolvedores esperam de uma linguagem “segura”: você pode ter checagens em tempo de compilação sem se afogar em boilerplate.

Quando a inferência funciona bem, ela faz duas coisas ao mesmo tempo:

• Mantém o código conciso, porque detalhes locais não exigem anotações repetidas.
• Mantém o código honesto, porque o compilador verifica cada ponto de uso.

Isso também melhora refatorações. Se você muda uma função e quebra seu tipo inferido, o compilador diz exatamente onde está o descompasso — muitas vezes antes dos testes em runtime.

Quando tipos explícitos ainda valem a pena

Programadores Haskell ainda escrevem assinaturas de tipo com frequência — e isso é uma lição importante. Inferência é ótima para variáveis locais e funções auxiliares pequenas, mas tipos explícitos ajudam quando:

• Publicando APIs: uma assinatura é documentação e contrato para chamadores.
• Lendo código complexo: tipos explicam intenção mais rápido que comentários.
• Trabalhando com generics avançados: às vezes o compilador precisa de orientação, ou o tipo inferido é correto tecnicamente mas difícil de entender.

A inferência reduz ruído, mas tipos continuam sendo uma poderosa ferramenta de comunicação.

A expectativa que definiu para linguagens modernas

Haskell ajudou a normalizar a ideia de que “tipos fortes” não deveriam significar “tipos verbosos”. Você vê essa expectativa em linguagens que fizeram da inferência uma comodidade padrão. Mesmo quando pessoas não citam Haskell diretamente, o patamar mudou: desenvolvedores querem checagens de segurança com cerimônia mínima — e ficam desconfiados ao repetir o que o compilador já sabe.

Pureza e a ideia de controlar efeitos colaterais

“Pureza” em Haskell significa que a saída de uma função depende apenas de suas entradas. Se você a chama duas vezes com os mesmos valores, obtém o mesmo resultado — sem leituras escondidas do relógio, sem chamadas de rede surpresa, sem escritas furtivas em estado global.

Essa restrição parece limitadora, mas atrai projetistas porque transforma grandes partes de um programa em algo mais próximo da matemática: previsível, composável e mais fácil de raciocinar.

Separando lógica do mundo bagunçado

Programas reais precisam de efeitos: ler arquivos, falar com bancos, gerar números aleatórios, logar, medir tempo. A grande ideia do Haskell não é “evitar efeitos para sempre”, mas “tornar efeitos explícitos e controlados”. Código puro cuida das decisões e transformações; código com efeitos é empurrado para as bordas onde pode ser visto, revisado e testado de forma diferente.

Mesmo em ecossistemas que não são puros por padrão, você vê a mesma pressão de design: fronteiras mais claras, APIs que comunicam quando I/O acontece e ferramentas que recompensam funções sem dependências ocultas (por exemplo, caching mais fácil, paralelização e refatoração).

Diretriz prática: isole efeitos para testabilidade

Uma forma simples de pegar essa ideia em qualquer linguagem é dividir o trabalho em duas camadas:

• núcleo puro: funções que transformam dados de entrada em saída
• casca de efeitos: código que lê entradas (HTTP, disco, tempo), chama o núcleo puro e escreve saídas

Quando testes exercitam o núcleo puro sem mocks para tempo, aleatoriedade ou I/O, eles ficam mais rápidos e confiáveis — e problemas de design aparecem mais cedo.

Mônadas e tratamento moderno de efeitos

Mônadas são frequentemente introduzidas com teoria intimidadora, mas a ideia do dia a dia é mais simples: elas são uma forma de sequenciar ações enquanto fazem cumprir regras sobre o que acontece a seguir. Em vez de espalhar checagens e casos especiais, você escreve um pipeline com aparência normal e deixa o “container” decidir como os passos se conectam.

Sequência com regras embutidas

Pense em uma mónada como um valor mais uma política para encadear operações:

• Se o valor está “ausente”, pule o resto.
• Se ocorreu um erro, pare e carregue o erro.
• Se o trabalho é assíncrono, mantenha a cadeia rodando quando o resultado chegar.

Essa política é o que torna efeitos gerenciáveis: você pode compor passos sem reimplementar o fluxo de controle cada vez.

Exemplos familiares: Option, Result e async

Haskell popularizou esses padrões, mas você os vê por toda parte hoje:

• Valores opcionais: Option/Maybe evita checagens nulas ao encadear transformações que short-circuitam em “none”.
• Tratamento de erro: Result/Either transforma falhas em dados, permitindo pipelines limpos onde erros fluem ao lado dos sucessos.
• Workflows assíncronos: Task/Promise (e tipos similares) permitem encadear operações que rodam depois, mantendo a sequência legível.

Como isso aparece na sintaxe mainstream

Mesmo quando linguagens não falam “mónada”, a influência é visível em:

• pipelines Result/Option (map, flatMap, andThen) que mantêm lógica de negócio linear.
• async/await, frequentemente uma superfície mais amigável sobre a mesma ideia: sequenciar passos com efeitos sem callback spaghetti.

A chave: foque no caso de uso — compor computações que podem falhar, estar ausentes ou rodar depois — em vez de memorizar termos teóricos.

Type classes e a ascensão de traits/protocolos

Type classes são uma das ideias mais influentes do Haskell porque resolvem um problema prático: como escrever código genérico que ainda dependa de capacidades específicas (como “pode ser comparado” ou “pode ser convertido para texto”) sem forçar tudo numa hierarquia de herança única.

O que type classes resolvem (sem herança)

Em termos simples, uma type class deixa você dizer: “para qualquer tipo T, se T suporta essas operações, minha função funciona.” Isso é polimorfismo ad-hoc: a função pode se comportar diferente dependendo do tipo, mas você não precisa de uma classe base comum.

Isso evita a armadilha clássica orientada a objetos em que tipos não relacionados são encaixados sob um tipo abstrato só para compartilhar uma interface, ou onde você acaba com árvores de herança profundas e frágeis.

Como a ideia aparece em outras linguagens

Muitas linguagens mainstream adotaram blocos semelhantes:

• traits do Rust: contratos explícitos de capacidade, muito usados para generics e comportamento de operadores.
• protocols do Swift: estilo orientado a protocolos que incentiva comportamento construído a partir de peças pequenas.
• C# / Java (interfaces + generics): usados cada vez mais de forma orientada a capacidades, mesmo com herança disponível.

O fio comum é que você pode adicionar comportamento compartilhado por conformidade em vez de por “é-um”.

Coerência e ambiguidade: detalhes que importam

O design do Haskell também destaca uma restrição sutil: se mais de uma implementação puder se aplicar, o código fica imprevisível. Regras sobre coerência (e evitar instâncias ambíguas/sobrepostas) são o que impedem que “genérico + extensível” vire “misterioso em runtime”. Linguagens que oferecem múltiplos mecanismos de extensão frequentemente precisam fazer trade-offs semelhantes.

Dica de API: componha, não construa torres

Ao projetar APIs, prefira traits/protocolos/interfaces pequenos que se componham bem. Você terá reuso flexível sem forçar consumidores a hierarquias profundas — e seu código fica mais fácil de testar e evoluir.

Imutabilidade como padrão mais seguro

Imutabilidade é um hábito inspirado no Haskell que continua pagando dividendos mesmo se você nunca escrever uma linha de Haskell. Quando dados não podem ser alterados depois de criados, categorias inteiras de bugs “quem mudou esse valor?” desaparecem — especialmente em código compartilhado onde muitas funções tocam os mesmos objetos.

Menos bugs acidentais em código compartilhado

Estado mutável costuma falhar de forma chata e cara: uma função auxiliar atualiza uma estrutura “por conveniência” e código posterior passa a depender silenciosamente do valor antigo. Com dados imutáveis, “atualizar” significa criar um novo valor, então mudanças são explícitas e localizadas. Isso tende a melhorar a legibilidade também: você pode tratar valores como fatos, não como contêineres que podem ser modificados em outro lugar.

Estruturas persistentes tornam a imutabilidade prática

Imutabilidade parece desperdício até você conhecer o truque que linguagens mainstream pegaram da programação funcional: estruturas de dados persistentes. Em vez de copiar tudo a cada mudança, versões novas compartilham a maior parte da estrutura com a versão antiga. É assim que você obtém operações eficientes mantendo versões anteriores intactas (útil para undo/redo, caching e compartilhamento seguro entre threads).

Onde “imutável por padrão” aparece hoje

Você vê essa influência em recursos e orientações: bindings final/val, objetos congelados, views somente-leitura e linters que empurram times para padrões imutáveis. Muitas bases de código hoje começam por “não mutar a menos que haja necessidade clara”, mesmo quando a linguagem permite mutação livremente.

Conselho prático

Priorize imutabilidade para:

• estado compartilhado entre módulos ou equipes
• dados passados entre threads/tarefas
• modelos de domínio core (pedidos, usuários, faturas)

Permita mutação em bordas estreitas e documentadas (parsing, loops críticos de performance) e mantenha-a fora da lógica de negócio onde a correção importa mais.

Racicínio sobre concorrência moldado por ideias funcionais

Haskell não apenas popularizou programação funcional — também ajudou muitos desenvolvedores a repensar o que é “boa concorrência”. Em vez de ver concorrência como “threads + locks”, promoveu uma visão mais estruturada: mantenha mutação compartilhada rara, torne comunicação explícita e deixe o runtime lidar com muitas unidades de trabalho pequenas e baratas.

Threads leves e design focado em mensagens

Sistemas Haskell frequentemente usam threads leves gerenciadas pelo runtime, não threads pesadas do SO. Isso muda o modelo mental: você pode estruturar trabalho como muitas tarefas pequenas e independentes sem pagar um grande overhead cada vez que adiciona concorrência.

Em alto nível, isso combina naturalmente com passagem de mensagens: partes separadas do programa comunicam-se enviando valores, não agarrando locks em torno de objetos compartilhados. Quando a interação primária é “envie uma mensagem” em vez de “compartilhe uma variável”, condições de corrida comuns têm menos lugares para se esconder.

Por que pureza e imutabilidade facilitam código paralelo

Pureza e imutabilidade simplificam o raciocínio porque a maioria dos valores não muda após a criação. Se duas threads leem os mesmos dados, não há dúvida sobre quem os modificou “no meio”. Isso não elimina bugs de concorrência, mas reduz dramaticamente a superfície de ataque — especialmente os acidentais.

Influência sobre concorrência mais segura em outros lugares

Muitas linguagens e ecossistemas se moveram para essas ideias via modelos de ator, canais, estruturas de dados imutáveis e orientação “share by communicating”. Mesmo quando uma linguagem não é pura, bibliotecas e guias de estilo cada vez mais conduzem times a isolar estado e passar dados.

Dica de design

Antes de adicionar locks, reduza primeiro estado mutável compartilhado. Particione estado por dono, prefira passar snapshots imutáveis e só então introduza sincronização onde o compartilhamento for inevitável.

Testes baseados em propriedades inspirados pelo QuickCheck

QuickCheck não só adicionou mais uma biblioteca de testes ao Haskell — ele popularizou uma mentalidade de teste diferente: em vez de escolher alguns inputs de exemplo manualmente, você descreve uma propriedade que deve sempre valer e a ferramenta gera centenas ou milhares de casos aleatórios para tentar quebrá-la.

O que o QuickCheck normalizou

Testes unitários tradicionais documentam comportamento esperado para casos específicos. Testes baseados em propriedades complementam isso explorando os “unknown unknowns”: casos-limite que você não pensou em escrever. Quando ocorre uma falha, ferramentas no estilo QuickCheck geralmente encolhem a entrada que falhou até o menor contraexemplo, o que facilita entender o bug.

Como a ideia se espalhou

O fluxo gerar–falsificar–reduzir foi adotado amplamente: ScalaCheck (Scala), Hypothesis (Python), jqwik (Java), fast-check (TypeScript/JavaScript) e muitos outros. Mesmo times que não usam Haskell adotam a prática porque ela escala bem para parsers, serializadores e código pesado em regras de negócio.

Propriedades iniciais que valem a pena

Algumas propriedades de alto impacto reaparecem:

• Round-trips: codificar e depois decodificar devolve o valor original.
• Leis de ordenação: ordenar produz uma lista ordenada e que é uma permutação da entrada.
• Invariantes: “saldo nunca fica negativo”, “IDs são únicos”, “um valor validado continua válido após normalização”.

Quando você consegue enunciar uma regra em uma frase, geralmente dá para transformá-la numa propriedade e deixar o gerador achar os casos estranhos.

Expectativas de compilador e ferramentas que o Haskell ajudou a definir

Haskell não só popularizou recursos de linguagem; ele moldou o que desenvolvedores esperam de compiladores e ferramentas. Em muitos projetos Haskell, o compilador é tratado como um colaborador: ele não apenas traduz código, ele aponta riscos, inconsistências e casos não cobertos.

Warnings como orientação, não ruído

A cultura Haskell tende a levar avisos a sério, especialmente sobre funções parciais, ligações não usadas e correspondências não-exaustivas. A mentalidade é simples: se o compilador pode provar que algo é suspeito, você quer saber cedo — antes que vire um relatório de bug.

Essa atitude influenciou outros ecossistemas onde “builds sem warnings” virou norma. Também encorajou times de compiladores a investir em mensagens mais claras e sugestões acionáveis.

Tipagem forte aumentou as expectativas para ferramentas de refatoração

Quando uma linguagem tem tipos estáticos expressivos, as ferramentas podem ser mais confiantes. Renomeie uma função, mude uma estrutura de dados ou divida um módulo: o compilador te guia até cada ponto de uso que precisa de atenção.

Com o tempo, desenvolvedores passaram a esperar esse loop de feedback apertado em outros lugares também — melhor jump-to-definition, refatores automáticos mais seguros, autocomplete mais confiável e menos surpresas em runtime.

Tornar o caminho errado mais difícil

O Haskell influenciou a ideia de que linguagem e ferramentas devem te guiar para código correto por padrão. Exemplos incluem:

• empurrões para funções totais via avisos de exaustividade
• apontar código morto e imports não usados cedo
• destacar tipos ambíguos ou excessivamente gerais que escondem intenção

Não se trata de ser estrito por si só; é sobre reduzir o custo de fazer a coisa certa.

Trate warnings como parte da revisão de código

Um hábito prático: faça dos avisos do compilador um sinal de primeira classe em revisões e CI. Se um warning for aceitável, documente por quê; caso contrário, corrija. Isso mantém o canal de avisos significativo — e transforma o compilador num revisor consistente.

O que pegar emprestado (e o que evitar) na influência do Haskell

O maior presente do Haskell ao design moderno de linguagens não é um recurso isolado — é uma mentalidade: torne estados ilegais irrepresentáveis, torne efeitos explícitos e deixe o compilador cuidar do trabalho chato. Mas nem toda ideia inspirada no Haskell cabe em qualquer lugar.

Quando pegar emprestado ajuda

Ideias ao estilo Haskell brilham ao projetar APIs, buscar correção ou construir sistemas onde concorrência pode ampliar pequenos bugs.

• ADTs + pattern matching ajudam a modelar estados reais (por exemplo, Pending | Paid | Failed) e forçam quem chama a tratar cada caso.
• Design guiado por tipos (tipos fortes, inferência, funções puras pequenas) reduz código “stringly-typed” e torna refatores mais seguros.
• Efeitos explícitos (mesmo sem mónadas) melhoram clareza: separe cálculos puros de I/O, tempo, aleatoriedade e logs.

Se você constrói software full-stack, esses padrões se traduzem bem em escolhas de implementação do dia a dia — por exemplo, usar unions discriminadas do TypeScript numa UI React, sealed types em stacks móveis modernos e resultados explícitos de erro em fluxos de backend.

Quando faz mal

Problemas surgem quando abstrações viram símbolo de status em vez de ferramenta. Código hiper-abstrato pode esconder intenção atrás de camadas de helpers genéricos, e truques de tipos “engraçados” podem retardar a adoção. Se colegas precisam de um glossário para entender um recurso, provavelmente ele está fazendo mais mal do que bem.

Checklist de adoção gradual

Comece pequeno e itere:

1. Introduza sum types/enums para estados de domínio; remova strings mágicas.
2. Prefira funções totais e matching exaustivo (trate avisos de não-exaustividade como erros).
3. Isole efeitos nas bordas (áreas de I/O) e mantenha o core puro.
4. Adicione testes baseados em propriedades para invariantes complicadas (parsers, serializadores, regras de negócio).
5. Só então considere ferramentas mais pesadas (sistemas de efeitos, features avançadas de tipos) se a dor persistir.

Nota prática para times que entregam rápido

Se quiser aplicar essas ideias sem reconstruir toda a pipeline, ajude colocá-las na forma como você estrutura e itera o software. Por exemplo, times que usam Koder.ai (uma plataforma vibe-coding para construir apps web, backend e mobile via chat) frequentemente começam num fluxo orientado ao planejamento: defina estados de domínio como tipos explícitos (por exemplo, unions do TypeScript para estado de UI, sealed classes do Dart para Flutter), peça ao assistente para gerar fluxos tratados de forma exaustiva e então exporte e refine o código fonte. Como o Koder.ai pode gerar frontends React e backends Go + PostgreSQL, é um lugar conveniente para reforçar “tornar estados explícitos” cedo — antes que checagens nulas e strings mágicas se espalhem pela base de código.

Leitura adicional

• /blog/type-safety-explained
• /blog/pattern-matching-guide