¿Cuáles son tus herramientas de desarrollo favoritas?

 (lobste.rs)
33 puntos por GN⁺ 12 시간 전 | 8 comentarios | Compartir por WhatsApp
  • En la categoría de editores, se mencionan repetidamente Helix, Emacs, Neovim, Sublime Text, Zed y los IDE de JetBrains, y quedan claras las ventajas y desventajas de cada uno
  • En control de versiones, destaca la tendencia de jujutsu(jj) a reemplazar el CLI de git, y también se mencionan varias herramientas GUI de apoyo como Magit, lazygit y Sublime Merge
  • En shell, terminal y gestión del entorno, aparecen como stack principal Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin y fzf
  • El mensaje clave que más se repite es: "elige herramientas con buenos valores por defecto y evita la configuración infinita" y "con la edad, en vez de adaptar la herramienta a uno, uno se adapta a buenos valores por defecto" (aunque también hay opiniones en contra)

Contexto de la discusión

  • Hilo de preguntas en Lobsters: "¿Cuáles son las herramientas favoritas de un desarrollador?" con la idea de que "los desarrolladores tienen opiniones fuertes y es difícil elegir una sola herramienta"
  • Recibió más de 130 comentarios en 19 horas
  • Filosofía que apareció repetidamente: "con la edad, en vez de adaptar la herramienta a uno, adapto mis preferencias a herramientas con buenos valores por defecto", porque así "uno termina en el camino mejor probado y se encuentra con menos bugs"
    • Opinión contraria: "con la edad, disminuye la paciencia para soportar malos valores por defecto. Si no puedo dejarla utilizable en unos minutos, la cambio por otra herramienta"

Editores de texto / IDE

  • Helix

    • "un punto de equilibrio adecuado entre capacidad de personalización y una gran experiencia por defecto"
    • Al usarlo junto con jujutsu, después de cambiar de commit hay que recargar manualmente los archivos abiertos; como solución temporal se usa un atajo para :reload-all
    • Un PR de monitoreo de archivos (#14544) está siendo desarrollado por un maintainer
    • También hay muchos casos de usuarios que no logran adaptarse al modelo de selection-first y vuelven a vim
    • Fork con soporte parcial de atajos de vim: evil-helix

  • Emacs

    • Muchos usuarios respondieron simplemente "Emacs"
    • Magit recibió tantos elogios que se menciona por separado
    • Flujo de migración por áreas: Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired

  • Neovim

    • "Retiré mi .vimrc de más de 10 años y migré por completo a Neovim"
    • Tendencias en distribuciones de plugins:
      • LazyVim: la más pulida; se recomienda desactivar los atajos de flash.nvim
      • AstroNvim: alternativa más ligera
      • Kickstart.nvim: punto de partida simple orientado a personalización
      • MiniMax: configuración inicial creada por el equipo de mini.nvim

  • IDE de JetBrains

    • Se recomienda mucho el depurador de PyCharm: funciona incluso dentro del REPL de Django, soporta HTML/CSS/JS de plantillas y permite hacer cherry-pick por hunk
    • Si usas 2 o más productos de JetBrains, la licencia All Products sale más barata

  • Sublime Text / Zed

    • "Sublime Text está subestimado"; hubo quien dijo usarlo a diario desde hace más de 20 años
    • Incluso si se programa en otra parte, se sigue usando por su rapidez y buffers sin guardar persistentes
    • También aparece la tendencia de probar Zed como reemplazo por el crecimiento excesivo de VSCode

  • Kate / Notepad++

    • También se mencionan, en respuestas breves, Kate en el mundo Linux y Notepad++ en Windows

Control de versiones

  • jujutsu (jj) — la herramienta más mencionada del año

    • "No pensé que abandonaría el CLI de git, pero al final eso fue lo que pasó"
    • "Es raro encontrar una herramienta que sea más fácil y al mismo tiempo más potente; jujutsu logra ambas cosas"
    • Hay comentarios de que rebase y amend de commits se vuelven agradables
    • Desventaja: los valores por defecto no están muy pulidos y hace falta ajustar color/template; el valor por defecto fue descrito como "texto vómito de unicornio arcoíris de alto contraste"

  • Herramientas de apoyo para Git

    • tig: "una versión mejorada de git log", útil para staging interactivo
    • Magit: pieza central para usuarios de Emacs
    • Sublime Merge: "una capa GUI sobre git, pero muy bien hecha"; también puede integrarse con jj usando merge-editor = "smerge"
    • lazygit: hace que uno se anime a intentar tareas complejas como rebase, revert, stash y múltiples remotes
    • delta: al configurarlo como pager de git ofrece diffs con resaltado de sintaxis; combinado con lazygit permite alternar entre side-by-side e inline
    • difftastic: diff basado en sintaxis, no en líneas
    • git revise: "debería venir incluido por defecto en git"
    • Beyond Compare: herramienta de diff/merge/sincronización de carpetas usada durante 20 años

Shell / terminal

  • Fish

    • "Hace todo lo que hacen bash y zsh, pero ofrece una gran experiencia sin casi configuración"
    • Cuando hace falta, también puede ejecutar scripts de bash tal cual
    • Se valora como una herramienta en la que uno sigue descubriendo atajos útiles (por ejemplo, historial de directorios con alt+<left|right>)

  • Emuladores de terminal

    • WezTerm: copiar/pegar solo con teclado (ctrl+shift+space), duplicar una pestaña en el mismo sistema con ctrl+shift+t, cliente SSH y multiplexor integrados
    • Ghostty: integración nativa con macOS — popover de diccionario con Cmd+Ctrl+D, drag-and-drop, pestañas nativas y gran calidad de renderizado de fuentes
    • kitty: "un ejemplo de buena herramienta donde los valores por defecto simplemente funcionan y aun así hay mucho margen de configuración"

  • tmux

    • el primer comando que ejecutan al abrir una sesión de terminal
    • Sirve como protección ante cierres de SSH o terminales cerradas por error, y permite mantener el mismo patrón entre Mac y NixOS

  • Starship

    • Puede integrarse en cualquier shell, aunque su desventaja es que en repositorios grandes los comandos de git status y branch se vuelven lentos

Gestión del entorno / dependencias

  • Nix / NixOS

    • "Quizá sea síndrome de Estocolmo, pero después de usarlo ya no puedo volver a otras distribuciones de Linux ni a otros sistemas de build"
    • Con nix shell por proyecto se minimizan los paquetes del sistema y se pueden fijar versiones exactas sin contaminar el PATH global
    • "Da mucha confianza pensar que seguirá funcionando igual dentro de 1 año o 5 años"
    • "Una vez superada la curva de aprendizaje, se siente mágico. Así es como debió haber sido la configuración del SO desde el principio"

  • mise

    • Gestor de versiones de herramientas que reemplaza a direnv, e incluso se integra en CI liviano
    • "un reemplazo estrictamente mejor que asdf"
    • Al descubrir mise activate, se puede eliminar direnv por completo
    • Con mise watch y su sistema de tareas permite acciones por proyecto y ejecutar trabajos cuando cambian archivos

  • Dev Containers

    • Su ventaja es poder compartir el entorno de despliegue docker/container con el entorno de desarrollo
    • Desventaja: el tooling aún está inmaduro (el CLI de referencia ni siquiera implementa un comando stop)

  • chezmoi

    • Permite mantener un entorno de desarrollo consistente entre equipos de trabajo y personales, incluyendo alias de git, configuración de Neovim, access tokens e instalación de otras herramientas

Depuración / profiling

  • rr — depurador de record/replay

    • "la herramienta principal para depurar C/C++; una vez grabado, puede reproducirse de forma determinista infinitas veces"
    • Permite vigilar direcciones de memoria y rebobinar hasta el último punto de escritura
    • "temporal debugging bisection": junto con watchpoints, permite buscar hacia adelante y hacia atrás el punto donde ocurre una corrupción de memoria

  • Pernosco

    • Depurador con viaje en el tiempo + análisis de flujo de datos
    • Fue de ayuda decisiva para el manejo de foco en procesos multiproceso de contenido de Firefox y para compatibilidad de Chrome con about:blank

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: herramienta todoterreno para depuración gráfica, superior en funciones básicas al depurador Metal de XCode
    • Tracy: "si hicieras un profiler con recursos ilimitados, terminarías construyendo Tracy"
    • RemedyBG: depurador muy cómodo para el trabajo diario

  • XCode Instruments

    • En profiling 3D/GPU ofrece anotaciones del costo de ejecución por línea
    • Permite analizar la causa de los stalls: espera de lectura de memoria, espera de sincronización y divergencia del flujo de control
    • "la ventaja de un ecosistema que controla hardware, drivers, lenguaje de sombreado Metal y tooling de punta a punta"

  • Otros

    • strace, extrace, perf — combinación indispensable para depuración
    • gdb — sigue apareciendo muchas veces como respuesta corta

Búsqueda / procesamiento de texto

  • fzf: integración con búsqueda inversa del shell, "el nivel de fuzzy es el justo"
    • Con el patrón rg '' | fzf se puede buscar texto en todo el repo y, al elegir una coincidencia, devolver de inmediato algo como vim foo.rs +123 al prompt del shell
  • ripgrep: "funciona correctamente desde el primer momento; nunca he sentido la necesidad de configurarlo"
  • septum: búsqueda interactiva de código — consultas condicionales como "contiene triangle, vertex y mesh en 7 líneas o menos, pero excluye physics"
  • fastmod / spacemod: reemplazo masivo
  • autojump: con j whatevs permite moverse mediante fuzzy matching al historial de directorios usados
  • zoxide: similar a autojump, con navegación más fluida
  • awk: sigue siendo muy potente para tareas de "extraer un poco y retocar un poco"
  • entr: "vigila estos archivos y ejecuta esto" — ideal para disparar pruebas automáticamente en un codebase

JSON / datos / herramientas de transformación

  • jq: estándar de facto para procesar JSON; se recomienda leer el manual completo, y también el jq track de Exercism
    • gojq: mensajes de error muy superiores al jq nativo, y soporte para entrada YAML, lo que permite reutilizar la misma muscle memory
  • fx: drill-down de salidas JSON grandes
  • hexdump: especialmente hexdump -C, útil para depuración embebida — patrón picocom --baud 115200 /dev/ttyUSB | hexdump -C
  • hexyl: visor hexadecimal con color
  • bat: reemplazo de cat con resaltado de sintaxis
  • choose, fd: reemplazos de cut y find, respectivamente

Historial del shell / portapapeles / notas

  • Atuin: sincronización del historial del shell y búsqueda basada en contexto de directorio o repositorio git
  • CopyQ: gestor de portapapeles para unos 2000 elementos; ayuda a recuperar trabajo anterior cuando se pierde una nota
  • histprune: personalización de Ctrl+R en fzf; con alt+D elimina entradas del historial al instante
  • Obsidian: migración desde Logseq; guardar en Markdown puro favorece el trabajo con LLMs/agentes
  • Joplin: AGPLv3, con apps de escritorio, móvil y web; backend WebDAV/OneDrive/S3 y almacenamiento directo en archivos .md

Build / automatización de tareas

  • just: reemplazo de make — enfocado en tareas más que en builds, con una interfaz consistente y agnóstica del lenguaje como just lint
    • "Permite alternar por target entre el modo línea por línea de make y el modo script completo en shell/python/node"
    • Desventajas: escribe scripts embebidos en $TMPDIR antes de ejecutarlos y usa su propio lenguaje de plantillas (uncanny valley)
  • Task (go-task): alternativa basada en YAML, con enfoque batteries-included
  • universal-test-runner: detecta automáticamente cómo correr las pruebas de un repo y las ejecuta, con pass-through de argumentos adicionales
  • chezmoi: gestión consistente de dotfiles e instalación de herramientas entre distintas máquinas

HTTP / red / secretos

  • Hurl: "olvídate de las apps HTTP GUI que quieren recolectar información" — permite expresar solicitudes tipo curl en un formato de texto simple, ideal para pruebas integradas
  • curl: mencionado muchas veces como respuesta breve
  • SOPS: cifrado de secretos con claves age/SSH, usando patrones como sops exec-env secrets.yaml -- some command
  • Mutagen: sincronización bidireccional de archivos en tiempo real sobre SSH, útil para trabajar en máquinas remotas
  • forge: reemplazo del CLI de GitHub, con soporte para Codeberg y una experiencia más rápida y ordenada

Otros / flujo de trabajo

  • Quarto: presentaciones rápidas con markdown
  • Nushell: shell influido por PowerShell, útil para escribir con fiabilidad scripts de transformación grandes como GeoPackage → PostGIS o PostGIS view → PMTiles; desventaja: al estar antes de 1.0, se rompe con actualizaciones frecuentes
  • Typst: mencionado como reemplazo de LaTeX, con preferencia por su sintaxis basada en call-by-value
  • Topiary: formateador multilenguaje
  • Hunk: visor de diff en terminal orientado a revisión primero para agentic coders, con el patrón de dejar abierto --watch junto al agente que programa
  • Raycast / Alfred: lanzadores para macOS, con snippets, portapapeles y búsquedas web parametrizadas
  • Ergodox EZ: teclado usado por 10 años, con alta satisfacción en personalización y consumo energético
  • Joplin / Fossil: autoalojamiento de notas y wiki
  • AeroSpace / Sway: gestores de ventanas en mosaico

Meta-mensajes que se repiten

  • "elige herramientas con buenos valores por defecto y evita la configuración infinita" — Helix, Fish, ripgrep y mise se mencionan como ejemplos representativos de esta filosofía
  • Perspectiva contraria: también hay casos de personas que, tras ajustar herramientas sin parar, terminaron construyendo su propio sistema ideal — "ahora solo lo retoco unas pocas veces al año"
  • Subproducto de la era de los agentes de IA: crece la idea de que herramientas como jq, Markdown y texto estructurado facilitan la colaboración con LLMs — el Markdown puro de Obsidian, el modo watch de hunk y la recomendación de estudiar el manual de jq apuntan en la misma dirección
  • Ventaja de macOS en depuración gráfica: se considera que el profiling de GPU en XCode Instruments es abrumadoramente superior al de Linux/Windows
  • Renacimiento del CLI vs tipografía: al mismo tiempo que el ecosistema de herramientas de terminal se enriquece, también aparece la observación de que salidas largas de LLM/agentes se leen mejor en navegadores o apps dedicadas por la tipografía

Lecturas relacionadas

8 comentarios

 
kirinonakar 24 분 전

He probado varias, pero ninguna me termina de convencer, así que estoy creando una yo mismo. Estoy tomando solo las funciones que necesito como referencia de notepad++, VS Code, Zed y Obsidian.
 
xguru 10 시간 전

Últimamente he estado usando mucho juntos estos tres: cmux, tmux y mux.
Si inicio sesión por ssh en un servidor conectado con tailscale, me muestra agrupadas las sesiones existentes de tmux con fzf, y desde ahí elijo a cuál entrar.

cmux - Terminal para macOS basado en Ghostty para agentes de código con IA
Show GN: mux – gestor de sesiones de tmux que convierte sesiones de código con IA en vistas previas en vivo
 
edunga1 2 시간 전

En Mac, ¿no hay que presionar Enter dos veces para escribir en coreano en la terminal? (dos veces: una para completar la composición en coreano y otra para ingresarlo)
La única que no tenía este problema era wezterm, así que me cambié a esa.
 
onixboox 3 시간 전

Me gusta zed
 
snisty 5 시간 전

Ya me convertí en alguien que no puede vivir sin Claude Code. + tmux..
Y para agregar, vscode como editor de texto..
Si no, un IDE imprescindible como Visual Studio para compilar..
 
hwhang0917 8 시간 전

fzf, jq, rg, awk ❤️
 
jjpark78 10 시간 전

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,
 
GN⁺ 12 시간 전
Opiniones de Lobste.rs

  • Uso Helix como editor de texto. Para mí tiene el equilibrio justo entre personalización y una excelente experiencia por defecto
    Por la misma razón uso Fish como shell de terminal. Viene genial de fábrica y casi no hace falta ajustarlo para usarlo como quiero
    A medida que envejezco, cada vez me gusta más adaptar mis gustos a herramientas con buenos valores por defecto diseñados con intención, en vez de estar tocando la configuración sin fin
    Atuin está muy bueno para sincronizar el historial del shell entre máquinas remotas y para buscar historial contextual según el directorio actual o el repositorio git. Tiene otras funciones, pero yo solo uso esas
    Mise también me gusta por varias razones, pero sobre todo es mi administrador de versiones de herramientas favorito. Reemplazó al direnv que usaba antes y en proyectos personales incluso empecé a integrarlo poco a poco en flujos ligeros de CI

    • El camino que sigue buenos valores por defecto es el camino más probado, así que te encuentras con menos bugs. En general es una decisión sensata
    • No es que solo existan “adaptar tus gustos a los valores por defecto” y “estar tocando la configuración sin fin”. En mi experiencia n=1, seguí, seguí y seguí ajustando la configuración hasta llegar al punto que quería, y ahora casi no la toco
      Apenas unas cuantas veces al año. Mi Emacs quedó como una caja de herramientas Studley hecha a mi medida
    • Quiero que me guste Helix. De verdad es un proyecto muy pulido y sus valores por defecto son atractivos, pero tengo demasiada memoria muscular de Vim acumulada
      En cambio, hace unos meses finalmente adopté Neovim por completo y retiré mi .vimrc, que había crecido orgánicamente por más de 10 años. Me dio algo de pena, pero ahora le tengo menos envidia a Helix
      Mise también está bueno y prácticamente no requiere configuración. Fish también lo empecé a usar hace unos meses y, salvo algunas funciones de usuario, lo uso casi tal cual viene
      Ripgrep también hace “simplemente lo correcto” en su estado por defecto, tanto que ni siquiera sé si alguna vez intenté configurarlo
    • ¿Cómo se aprende a usar bien Helix? Estoy tratando de salir de Neovim porque toda esa estructura de plugins que arrastra más de 50 repositorios me preocupa demasiado por los ataques a la cadena de suministro
    • De verdad me identifico con eso. A medida que envejezco, me cuesta entender a la gente que dedica tanto tiempo a juguetear con herramientas y software. No me parece divertido ni vale la pena

  • Emacs

  • Tal vez sea síndrome de Estocolmo, pero Nix. No es perfecto, pero una vez que pude trabajar de forma más expresiva y eficiente con Nix, prácticamente me arruinó otras distribuciones de Linux y los metassistemas de build
    Ya que estamos, pwntools también es una herramienta divertida de usar fuera de los CTF. Por ejemplo, está buenísimo para manipular sockets a nivel de bits desde un REPL de Python

    • Me gustan tanto Nix como pwntools. Como colega jugador de CTF, me da curiosidad: si tienes un entorno de pwn para CTF basado en Nix, me interesa saber cómo lo armaste
      Yo siempre levantaba una VM nueva de Ubuntu en libvirt, le metía las herramientas y trabajaba ahí; ¿hay alguna forma basada en Nix que recomendarías?

  • Emacs, por supuesto, y en particular Magit

  • Nix. Tiene una curva de aprendizaje. Pasé años rodeado de usuarios y evangelizadores de Nix antes de intentarlo en serio, pero al final está bastante bien
    Al trabajar en varios proyectos, me cansé de que cada uno usara herramientas distintas para gestionar dependencias a nivel sistema. Una para la versión de Node, otra para la de Python, y así
    También me harté de los fallos de build difíciles de depurar por incompatibilidades entre proyectos. Se rompe $foo en el Proyecto A, lo actualizas con Homebrew, y ahora se rompe $foo en el Proyecto B
    También agota que el proceso de build dependa de varias dependencias instaladas en el sistema, muchas veces ocultas, y por eso falle “por alguna razón”
    Moví todo lo posible a un nix shell por proyecto. Mantengo los paquetes a nivel sistema lo más livianos posible, y en cada proyecto fijo las herramientas exactas que necesita: dependencias, runtimes, compiladores, etc., con versiones concretas
    No contamino el PATH global ni otros proyectos. Si hoy me funciona, tengo bastante confianza en que también funcionará dentro de 1 o 5 años
    Y cuando quiero actualizar herramientas, puedo hacerlo sin preocuparme por afectar otros proyectos; si aparece una regresión, es fácil volver atrás o fijar solo una dependencia concreta en una versión anterior
    También es mejor cuando tus compañeros usan Nix en los proyectos. El tiempo extra de configurar y mantener el nix shell se comparte, y además tienes bastante confianza en que todos tienen el mismo entorno de desarrollo

    • Por razones parecidas, últimamente me enganché bastante con Dev Containers. Me parece que la idea es muy buena, pero por desgracia la calidad de las herramientas no acompaña
      Por ejemplo, ni siquiera el CLI de referencia implementa todavía el comando stop. Aun así, si usas Docker/contenedores para despliegue, tiene la ventaja de que puedes compartir mucha configuración entre el entorno de desarrollo y el de despliegue
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/) es un software tan mágico y tan bueno que ya no podría vivir sin él

    • Es una herramienta que antes habría necesitado todos los días. Buen hallazgo. Pienso guardarla en mi second brain para poder encontrarla cuando la vuelva a necesitar
    • Tengo curiosidad, ¿dónde es donde más valor le sacas a rr? Entiendo a grandes rasgos la explicación de la página principal del proyecto
      La idea de grabar un fallo una vez y luego depurarlo de forma determinista todas las veces que quieras claramente parece útil
      Pero pregunto por la experiencia real porque todavía no tengo esa sensación de “wow, este bug/flujo de trabajo específico habría sido imposible de resolver sin rr”

  • Vengo del mundo de la administración de sistemas, así que estoy mucho más del lado de “usar buenos valores por defecto con mínima configuración”. Pero hace poco hubo dos cosas que me rompieron ese hábito
    Ya se habló mucho aquí de jujutsu(jj), pero sinceramente da muchísimo gusto usarlo. Nunca pensé que dejaría el CLI de git, pero aquí estamos
    Durante años evité aprender a usar y configurar nvim, pero nvchad me permitió empezar. El nombre es terrible, pero para mí es una excelente configuración inicial con el nivel justo de opinión sin dejar de ser minimalista
    Claro que ahora ya uso desde cero mi propia configuración mínima
    Fuera de eso, uso bastante Python, así que también tengo que decir que las herramientas de astral siguen siendo un placer de usar. Ojalá Anthropic las cuide bien

    • Con jujutsu pasa el doble. Primero, el cambio en sí ya está bueno, y luego los valores por defecto de jj no están tan pulidos, así que te obliga a meterle mano una vez más
      Si no usas texto tipo vómito de unicornio arcoíris de alto contraste sobre fondo oscuro, hace falta bastante ajuste de colores y plantillas

  • En realidad es Emacs. Poco a poco fui moviendo mis tareas de computación a Emacs y empecé a aceptar sus valores por defecto
    Emacs es realmente fácil de personalizar, y muchas combinaciones de teclas hacen lo correcto en todos los modos
    La lista de cosas que voy migrando lentamente es Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired
    Quarto también está bastante bien para hacer presentaciones rápido con Markdown. Uso Nix y nix-darwin para todos mis dotfiles

    • Para el caso de uso de dired, vale la pena mirar Dirvish

  • Emacs. No lo uso muy seguido, pero escribir parsers con ragel es un placer

  • Sublime Text definitivamente está subestimado por demasiada gente

    • Quería que me gustara Sublime Text, pero su modo vi no coincidía lo suficiente con la memoria muscular que traía de Vim, así que no logré quedarme ahí
      Creo que se llamaba algo como “vintage”. Hoy en día, cuando estoy en una situación en la que me habría gustado que me gustara Sublime Text, uso Zed