- O port em Rust do fish-shell está “em grande parte” concluído e, dependendo de como se calcula, o progresso fica entre 60% com base em SLOC de C++ removidas e 74% com base na proporção de SLOC de Rust em relação às SLOC de C++
- O maior trabalho restante é portar o reader e o sistema de entrada, com reader de 3,5 mil linhas, screen handling de 1,3 mil linhas, input de 1 mil linhas e pager de 700 linhas fortemente acoplados entre si
- Todo o código C++ será removido; a meta não é lançar um release parcial em Rust no meio do caminho, mas fazer com que um release como o fish 4.0 contenha apenas Rust e zero C++
- Um port para Windows nunca foi planejado, e a transição para Rust não é uma solução para o problema de suporte ao Windows; usuários de ambientes MSYS2/cygwin temem que a ausência desses targets em Rust possa impedir atualizações
- O desempenho do port concluído ainda não está definido; os resultados iniciais são animadores, mas em alguns casos há a possibilidade de ficar cerca de 20% mais lento, e avalia-se que o primeiro release em Rust precisará de uma beta
Situação do port em Rust
- A reescrita do fish-shell em Rust está “em grande parte” concluída
- O percentual de progresso varia conforme o critério usado para contar
- Com base em SLOC de C++ removidas, está em 60%
- Com base na proporção de SLOC de Rust em relação às SLOC de C++, está em 74%
- Parte do código é scaffolding duplicado que poderá ser removido quando o último chamador desaparecer
- Por exemplo,
wgetopt já foi traduzido para Rust, mas a versão em C++ permanece até que o último chamador em C++ seja portado
- Essa abordagem é mais simples do que adicionar código de conversão a todos os chamadores em C++
- Depois que o último chamador desaparecer, há partes que serão limpas em efeito dominó quando o código duplicado for removido
Grandes trabalhos ainda restantes
- O maior componente restante é o reader e o sistema de entrada
- O código relacionado é fortemente acoplado
- reader: 3,5 mil linhas
- screen handling: 1,3 mil linhas
- input: 1 mil linhas
- pager: 700 linhas
- Depois disso, restarão alguns códigos remanescentes e a remoção da dependência de C++ no sistema de build
- remoção do
cmake
- transição para que o
cargo cuide de todas as tarefas necessárias
- o
cargo também deve assumir o build e a instalação da documentação e dos arquivos de completion
- O build do fish não se limita a compilar código Rust, pois inclui vários artefatos auxiliares, então não é uma transição simples
- Esse trabalho não é do tipo adequado para uma “drive-by contribution”
Plano de release e fluxo de versões
- O fish-shell não planeja fazer um release parcial em Rust
- Por exemplo, o fish 4.0 será composto totalmente apenas por Rust e terá zero C++
- Embora betas e release candidates tenham sido geralmente descontinuados, esta transição é considerada uma mudança que justifica uma beta
- Antes, betas e release candidates foram descontinuados porque não recebiam testes suficientes
- Também se deseja um release intermediário 3.7.0 baseado em C++ antes de passar para a versão em Rust
- A ideia é servir como um ponto de partida melhor para plataformas que não conseguem lidar com a versão em Rust
- O 3.7.0 é uma versão com algumas mudanças do 3.6.1 backportadas
- O trabalho do 3.7.0 acontece no branch Integration_3.7.0
- Também há um CHANGELOG preliminar
- As principais mudanças incluem timeout de combinações de teclas, melhorias no history-pager, correções de glitches de renderização e glob mais rápido
Arquivos restantes e escopo específico
- Em 1º de dezembro de 2023, a lista de arquivos restantes era a seguinte
src/fish_indent_common.cpp
src/fish_indent.cpp
src/fish_key_reader.cpp
src/builtins/bind.cpp
src/builtins/commandline.cpp
src/fish_tests.cpp
src/pager.cpp
src/reader.cpp
- Essa lista mostra, por arquivo, o escopo restante de portabilidade do C++
Correções de mal-entendidos e restrições
- Todo o código C++ será removido
- Um port para Windows não está planejado e nunca foi planejado no passado
- C++ também é bem suportado no Windows, portanto Rust em si não resolve o problema do port para Windows
- O problema do port para Windows não é a linguagem, mas o fato de o Windows não ser Unix
- O nome e o mascote não serão alterados
- É provável que a tagline não receba “written in Rust”
- O fishshell.com pode mencionar que ele foi escrito em Rust
- Em uma discussão adicional de setembro de 2024, a posição de não colocar “written in rust” na tagline foi reafirmada
- O desempenho do port concluído ainda é desconhecido
- Os resultados iniciais são animadores
- Em alguns casos, também há a possibilidade de ficar cerca de 20% mais lento
- Mesmo após o fim do port inicial, o projeto não estará concluído, e ainda haverá muito a fazer
Preocupações de usuários de Windows e MSYS2/cygwin
- Um usuário afirmou usar o fish em um ambiente MSYS2 e explicou que, como o MSYS2 fornece utilitários POSIX, o fish funciona bem
- Como Rust não fornece targets para cygwin ou MSYS2, há a preocupação de que, após a reescrita em Rust, o fish não possa ser compilado para targets cygwin ou MSYS2
- Esse usuário avalia que a transição para Rust pode impedir atualizações para alguns usuários do fish no Windows
- Essa preocupação foi apresentada não como uma crítica ao trabalho ou à linguagem, mas como um lembrete da restrição de que o Windows não é Unix
1 comentários
Opiniões no Hacker News
Se entendi corretamente, é impressionante que estejam fazendo uma reescrita gradual de C++ para Rust e, ainda assim, mantendo tudo funcional até o fim
O ritmo de avanço também é muito rápido e, se você ainda não experimentou o fish, recomendo muito. É um shell confortável de usar mesmo sem personalização, porque os padrões são bons; desde que migrei do bash alguns anos atrás, não penso em voltar
De quebra, você não precisa ficar pesquisando no Google toda vez a sintaxe de loop
fordo bash, que é pouco usada e nada intuitivaEles dizem que “não planejam lançar uma versão parcialmente misturada com Rust” e, por exemplo, pretendem lançar o fish 4.0 como 100% Rust, 0% C++. Parece que também vão lançar antes a 3.7.0 só em C++, para servir como um ponto de partida melhor para plataformas que não conseguem lidar com a versão em Rust
https://github.com/fish-shell/fish-shell/discussions/10123#d...
for ((i = 0; i < 10; i++)); do echo $i; donePara percorrer um array, depois de definir
foo[0]=aefoo[1]=b, dá para fazer algo comofor i in ${foo[@]}; do echo $i; doneA motivação da reescrita está explicada com mais detalhes aqui
https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...
No fim, acho difícil vencer a narrativa geral do mundo do desenvolvimento de correr atrás do novo e brilhante. Mesmo assim, embora eu não use Fish, torço para que dê certo
Como alguém que usa e gosta do Fish diariamente em cerca de quatro sistemas operacionais, estou bem animado com essa reescrita e, considerando o tamanho e a complexidade da base de código, o ritmo é surpreendente
Acho que isso também deve facilitar contribuições de muita gente, inclusive eu. Algo que recebeu menos atenção, mas que me anima ainda mais, é o plano de fazer o fish usar UTF-8 em vez de
wchar_tno futuro. UCS2 e UTF-16 foram uma dor de cabeça para software, e Rust torna muito mais fácil lidar com UTF-8sizeof(wchar_t)é 2 bytes no MSVC, portanto UTF-16, e 4 bytes no gcc, portanto UTF-32Fish é um shell subestimado
Ele faz escolhas fortes, como abrir mão da compatibilidade POSIX, e o resultado é um shell muito bom. Uso há mais de 10 anos e ainda gosto
O scripting do shell Fish também é muito agradável de usar, quase como um bash ergonômico. Todo projeto tem seus defeitos, mas nunca me impediu de fato de fazer o que eu queria
Como usuário de
zsh + spaceship, tenho curiosidade sobre quais seriam os benefícios de migrar para Fish como shell principalNão uso muitos scripts bash, então a parte de scripting é menos importante
A grande vantagem do Fish é que ele chega perto de ser um shell ideal sem configuração. O autocompletar funciona de imediato, a navegação pelo histórico é fácil, há completação de comandos com base no histórico, e escolher o prompt é tão simples quanto abrir um navegador. Dá para personalizar profundamente como no zsh, mas só com os padrões ele já vira um shell bem bom
Desde então, gostei de praticamente não gastar tempo com manutenção da configuração do shell
O Fish faz por padrão muita coisa que exigia plugins no zsh. Plugins do zsh eram lentos, e a inicialização do shell passava de 3 segundos; o Fish, mesmo com plugins, inicia muito mais rápido
fish_prompt.fishno diretório correto e, dentro dele, escrevi a funçãofish_promptpara imprimir uma string na saída padrão e criar meu próprio prompt de shell, quase apaguei o zshFica difícil voltar ao jeito de enfiar várias coisas em
$PS1e torcer para funcionar. Recomendo usar por alguns dias. Você passa a perceber quais coisas que considerava óbvias são recursos específicos de cada shell. Na pior das hipóteses, você conclui “não é do meu gosto” e volta para o shell de que gosta, como bash/zshA maior parte do que eu quero já vem por padrão e, hoje, uso só um plugin,
fzf.fishHá uma boa chance de um dos shells mais rápidos ficar ainda mais rápido
Depois que migrei do zsh para o Fish, minha produtividade no terminal aumentou bastante
Segundo o link, eles dizem que, na prática, ainda não sabem como será o desempenho do port finalizado. Os resultados iniciais são animadores, mas em alguns casos existe uma possibilidade bem real de ficar cerca de 20% mais lento
Eles ficam praticamente lado a lado, e é bem provável que não haja um vencedor claro
Eu normalmente pensava nele mais como código de cola, que delega o trabalho para outros lugares. Pode ser uma questão de eficiência de pipes, ou talvez por causa dos malucos que escrevem programas inteiros em bash, mas, considerando as muitas melhorias de qualidade de vida que o Fish oferece, parece um pouco incomum apontar velocidade como a vantagem central
Uso Fish há 1 ano
Não gosto do fato de ele quebrar a compatibilidade com padrões a ponto de alguns scripts como
gvmenvmnão rodarem, mas ele já traz todos os recursos que eu normalmente configurava manualmente no zsh. Depois de tentar configurar zsh em várias máquinas e desistir, troquei tudo para o Fish padrãoEle já funciona bem, então não sei ao certo o que se ganha ao portá-lo para Rust. Se for por segurança, fico pensando se algo capaz de mexer maliciosamente no Fish já não estaria presente no sistema
O principal tem mais a ver com atrair contribuidores e adicionar modos assíncronos/paralelos em que os mantenedores possam confiar
[1] https://github.com/fish-shell/fish-shell/pull/9512
Fish é bom
Mudei de
ZSH+Preztopara usar apenas Fish, e não sinto falta de nada; é muito mais rápido. Nos servidores, todos têm bash e ainda uso scripts bash, mas para trabalho cotidiano no terminal o Fish é suficienteSempre tive curiosidade sobre o Fish, mas o fato de ser incompatível com POSIX me deixava com receio
Gostaria de saber se alguém pode compartilhar os problemas que teve com isso e as formas de contorná-los
A desvantagem é que exige um pouco de troca de contexto. Especialmente se você usou bash/zsh a vida toda. Para mim é fácil distinguir quando uso o shell como interface de usuário e quando uso bash/sh como interpretador, mas isso pode não ser intuitivo para todos
Além disso, depois que deixei de usar um shell compatível com POSIX como shell do dia a dia, passei a promover mais rapidamente para uma linguagem de uso geral scripts que antes eu resolveria em bash
bash script.shQuando comecei a usar Fish, a incompatibilidade com POSIX me incomodava, mas, depois de aprender um pouco da sintaxe diferente e superar isso, considero que a sintaxe mais sane do Fish valeu o esforço. Hoje uso o terminal com muito mais prazer
Além disso, em 90% do tempo não é necessário manter compatibilidade POSIX, e hoje muitos scripts e extensões também oferecem suporte ao Fish. Em ambientes corporativos, continuo usando o padrão Bash/zsh
Fico curioso sobre por que estão mudando para Rust
A base de código em C++ estava ficando difícil de lidar?
Em resumo, os pontos centrais são processamento de strings, threading e problemas com CMake