Was sind eure Lieblings-Entwicklertools?

 (lobste.rs)
33 Punkte von GN⁺ 12 시간 전 | 8 Kommentare | Auf WhatsApp teilen
  • Im Bereich Editoren werden Helix, Emacs, Neovim, Sublime Text, Zed und JetBrains-IDEs immer wieder genannt, wobei die jeweiligen Trade-offs klar sichtbar werden
  • Bei der Versionsverwaltung fällt besonders der Trend auf, dass jujutsu(jj) die git-CLI ersetzt; außerdem werden viele GUI-Hilfstools wie Magit, lazygit und Sublime Merge erwähnt
  • Bei Shell, Terminal und Umgebungsverwaltung tauchen Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin und fzf als zentraler Stack auf
  • Die wiederkehrende Kernbotschaft lautet: „Wählt Tools mit guten Defaults und vermeidet endloses Konfigurieren“ sowie „Mit dem Alter passt man sich eher guten Defaults an, statt Tools an sich selbst anzupassen“ (bei gleichzeitigen Gegenstimmen)

Hintergrund der Diskussion

  • Auf Lobsters wurde im Thread „Was ist das Lieblings-Tool von Entwicklern?“ die Frage gestellt; dabei hieß es, dass Entwickler so meinungsstark seien, dass sich kaum ein einzelnes Tool benennen lasse
  • Innerhalb von 19 Stunden kamen mehr als 130 Kommentare zusammen
  • Eine wiederkehrende Philosophie: „Mit dem Alter passe ich meine Vorlieben eher an Tools mit guten Defaults an, statt Tools an mich anzupassen“, weil man dann „auf dem am besten getesteten Pfad bleibt und dadurch weniger Bugs erlebt“
    • Gegenposition: „Mit dem Alter sinkt die Toleranz für schlechte Defaults. Wenn ich ein Tool nicht in wenigen Minuten nutzbar machen kann, ersetze ich es durch ein anderes.“

Texteditor / IDE

  • Helix

    • „Der richtige Gleichgewichtspunkt zwischen Anpassbarkeit und einer hervorragenden Standarderfahrung“
    • Bei gemeinsamer Nutzung mit jujutsu müssen geöffnete Dateien nach einem Commit-Wechsel manuell neu geladen werden — als Workaround wird ein :reload-all-Keybinding verwendet
    • Ein PR für Dateibeobachtung (#14544) wird aktuell vom Maintainer vorangetrieben
    • Viele kehren aber auch zu vim zurück, weil sie sich nicht an das selection-first-Modell gewöhnen
    • Fork mit teilweiser Unterstützung von vim-Keybindings: evil-helix

  • Emacs

    • Viele Nutzer antworteten schlicht nur mit „Emacs“
    • Magit wurde so positiv bewertet, dass es separat hervorgehoben wurde
    • Frühere Migrationsmuster nach Bereich: Git → Magit, E-Mail → mu4e, RSS → elfeed, Notizen/TODO/Kalender → org-mode, Finder → dired

  • Neovim

    • „Ich habe meine über 10 Jahre alte .vimrc in den Ruhestand geschickt und bin komplett zu Neovim gewechselt“
    • Trends bei Plugin-Distributionen:
      • LazyVim: am ausgereiftesten, empfohlen wird aber, die flash.nvim-Keybindings zu deaktivieren
      • AstroNvim: schlankere Alternative
      • Kickstart.nvim: einfacher Ausgangspunkt zum Anpassen
      • MiniMax: Startkonfiguration vom mini.nvim-Team

  • JetBrains IDE

    • Der Debugger von PyCharm wird stark empfohlen — funktioniert sogar innerhalb des Django-REPL, unterstützt Template-HTML/CSS/JS und erlaubt Cherry-Picking einzelner Hunks
    • Wer mehr als zwei JetBrains-Produkte nutzt, fährt mit der All Products-Lizenz günstiger

  • Sublime Text / Zed

    • „Sublime Text ist unterschätzt“, mit Antworten von Leuten, die es seit über 20 Jahren täglich verwenden
    • Selbst wenn anderswo programmiert wird, bleiben hohe Geschwindigkeit und persistente ungespeicherte Buffer Gründe für die tägliche Nutzung
    • Da VSCode immer aufgeblähter wird, taucht auch der Trend auf, zu Zed zu wechseln

  • Kate / Notepad++

    • Auch Kate auf Linux und Notepad++ auf Windows wurden in knappen Antworten genannt

Versionsverwaltung

  • jujutsu (jj) — das dieses Jahr am häufigsten genannte Tool

    • „Ich hätte nie gedacht, dass ich die git-CLI aufgeben würde, aber genau das ist passiert“
    • „Es ist selten, dass ein Tool gleichzeitig einfacher und mächtiger ist, aber jujutsu schafft beides“
    • Rebase und Commit-Amend würden damit sogar Spaß machen
    • Nachteil: Die Defaults sind noch nicht ausgereift, daher müssen Farben und Templates angepasst werden — standardmäßig wirke es wie „Regenbogen-Einhorn-Erbrochenes mit hohem Kontrast“

  • Git-Hilfstools

    • tig: „verbessertes git log“, auch für interaktives Staging genutzt
    • Magit: zentrales Werkzeug für Emacs-Nutzer
    • Sublime Merge: „eine GUI-Schicht für git, aber sehr gut gemacht“, lässt sich auch mit jj über merge-editor = "smerge" integrieren
    • lazygit: motiviert dazu, komplexere Aufgaben wie Rebase, Revert, Stash oder mehrere Remotes aktiv anzugehen
    • delta: als git-Pager konfiguriert liefert es syntaxhervorgehobene Diffs; zusammen mit lazygit ist ein Umschalten zwischen Side-by-Side und Inline möglich
    • difftastic: syntaxbasierte Diffs statt zeilenbasierter Diffs
    • git revise: „sollte standardmäßig zu git gehören“
    • Beyond Compare: seit 20 Jahren genutztes Tool für Diff, Merge und Ordnersynchronisierung

Shell / Terminal

  • Fish

    • „Erledigt alles, was bash und zsh tun, und bietet ohne große Konfiguration eine hervorragende Erfahrung“
    • Falls nötig, lassen sich bash-Skripte weiterhin unverändert ausführen
    • Gilt als Tool, bei dem man ständig neue Shortcuts entdeckt, etwa alt+<left|right> für den Verzeichnisverlauf

  • Terminal-Emulatoren

    • WezTerm: Kopieren/Einfügen nur per Tastatur (ctrl+shift+space), Tab-Klon auf demselben System mit ctrl+shift+t, integrierter SSH-Client und Multiplexer
    • Ghostty: native macOS-Integration — Wörterbuch-Popover mit Cmd+Ctrl+D, Drag-and-Drop, native Tabs, hohe Qualität beim Font-Rendering
    • kitty: „Musterbeispiel für ein Tool, dessen Defaults einfach funktionieren und das zugleich viel Raum für Konfiguration lässt“

  • tmux

    • Der erste Befehl nach dem Öffnen einer Terminal-Session
    • Hilft gegen verlorene SSH-Sitzungen oder versehentlich geschlossene Terminals — mit demselben Muster über Mac- und NixOS-Umgebungen hinweg

  • Starship

    • Lässt sich in jede Shell einbinden; Nachteil ist langsames git status und git branch in großen Repositories

Umgebungs- / Abhängigkeitsverwaltung

  • Nix / NixOS

    • „Vielleicht Stockholm-Syndrom, aber danach kann man andere Linux-Distributionen und Build-Systeme nicht mehr benutzen“
    • Mit projektbezogenen nix shells lassen sich Systempakete minimieren und exakte Versionen ohne globale PATH-Verschmutzung fixieren
    • „Hohe Sicherheit, dass es in einem Jahr oder in fünf Jahren noch identisch funktioniert“
    • „Hat man die Lernkurve erst hinter sich, wirkt es wie Magie. Betriebssystemkonfiguration hätte schon immer so sein sollen.“

  • mise

    • Tool-Versionsmanager als Ersatz für direnv, auch in leichtgewichtiges CI integrierbar
    • „Eine strikt bessere Alternative zu asdf“
    • Wer mise activate entdeckt, kann direnv komplett entfernen
    • Mit mise watch und dem Task-System lassen sich projektbezogene Aktionen und dateibasierte Trigger ausführen

  • Dev Containers

    • Vorteilhaft ist, dass sich Container-Deployment-Umgebung und Entwicklungsumgebung teilen lassen
    • Nachteil: Das Tooling ist noch unreif, im Referenz-CLI fehlt etwa sogar ein Stop-Befehl

  • chezmoi

    • Hält eine konsistente Entwicklungsumgebung über Arbeits- und Privatmaschinen hinweg aufrecht und verwaltet dabei git-Aliasse, Neovim-Konfiguration, Access-Tokens und weitere Tool-Installationen mit

Debugging / Profiling

  • rr — Record/Replay-Debugger

    • „Das Hauptwerkzeug für C/C++-Debugging: einmal aufzeichnen, dann deterministisch unendlich oft abspielen“
    • Nach dem Beobachten einer Speicheradresse kann man bis zum letzten Schreibzugriff zurückspulen
    • „Temporal Debugging Bisection“ — mit Watchpoints den Entstehungszeitpunkt von Speicherbeschädigungen vor- und zurückverfolgen

  • Pernosco

    • Debugger mit Time-Travel und Datenflussanalyse
    • Half entscheidend bei Fokus-Handling in Firefox mit mehreren Content-Prozessen sowie bei Kompatibilitätsarbeit rund um about:blank in Chrome

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: Allzwecktool fürs Grafik-Debugging, bei Grundfunktionen besser als der Metal-Debugger von XCode
    • Tracy: „Wenn man einen Profiler mit unbegrenzten Ressourcen bauen würde, käme am Ende Tracy heraus“
    • RemedyBG: Debugger mit sehr guter Ergonomie im Arbeitsalltag

  • XCode Instruments

    • Bietet beim Profiling von 3D/GPU-Shadern Anmerkungen zu Laufzeitkosten pro Zeile
    • Analyse von Stall-Ursachen — etwa Warten auf Speicherzugriffe, Synchronisation oder divergierenden Kontrollfluss
    • „Der Vorteil eines Ökosystems, das Hardware, Treiber, Metal-Shading-Sprache und Tooling vollständig kontrolliert“

  • Sonstiges

    • strace, extrace, perf — unverzichtbare Kombination fürs Debugging
    • gdb — wurde ebenfalls vielfach in knapper Form genannt

Suche / Textverarbeitung

  • fzf: in die rückwärtsgerichtete Shell-Suche integriert, „genau der richtige Grad an Fuzziness“
    • Mit dem Muster rg '' | fzf lässt sich der gesamte Repository-Text durchsuchen; bei Auswahl eines Treffers landet sofort etwas wie vim foo.rs +123 in der Shell-Eingabeaufforderung
  • ripgrep: „funktioniert out of the box richtig, ich habe nie einmal versucht, es zu konfigurieren“
  • septum: interaktive Codesuche — etwa Bedingungen wie „enthält triangle, vertex und mesh innerhalb von sieben Zeilen, aber nicht physics“
  • fastmod / spacemod: für große Ersetzungsaktionen
  • autojump: springt mit j whatevs per Fuzzy-Match im Verlauf früherer Arbeitsverzeichnisse
  • zoxide: ähnlich wie autojump, aber mit flüssigerer Navigation
  • awk: weiterhin stark für „ein bisschen extrahieren und ein bisschen nachbearbeiten“
  • entr: „Beobachte diese Dateien und führe das hier aus“ — gut geeignet zum automatischen Ausführen von Tests im Codebestand

JSON- / Daten- / Konvertierungstools

  • jq: de-facto-Standard für JSON-Verarbeitung, es wird empfohlen, das Manual komplett zu lesen, ebenso der jq track von Exercism
    • gojq: deutlich bessere Fehlermeldungen als natives jq, außerdem YAML-Eingabeunterstützung, sodass vorhandene Muscle Memory erhalten bleibt
  • fx: Drilldown für große JSON-Ausgaben
  • hexdump: besonders hexdump -C ist nützlich für Embedded-Debugging — Muster wie picocom --baud 115200 /dev/ttyUSB | hexdump -C
  • hexyl: farbiger Hex-Viewer
  • bat: syntaxhervorgehobene Alternative zu cat
  • choose, fd: Alternativen zu cut bzw. find

Shell-Historie / Zwischenablage / Notizen

  • Atuin: synchronisiert die Shell-Historie und erlaubt Verlaufssuche nach Verzeichnis- oder git-Repository-Kontext
  • CopyQ: Clipboard-Manager mit rund 2000 Einträgen, hilfreich zum Wiederherstellen früherer Arbeit, wenn man etwas vergessen hat
  • histprune: eigene Ctrl+R-Anpassung für fzf — mit alt+D lassen sich Verlaufseinträge sofort löschen
  • Obsidian: Wechsel von Logseq; die Aufbewahrung in reinem Markdown gilt als vorteilhaft für die Zusammenarbeit mit LLMs und Agenten
  • Joplin: AGPLv3, unterstützt Desktop-, Mobile- und Web-Apps, mit WebDAV-, OneDrive- und S3-Backend und Speicherung direkt als .md-Dateien

Build / Task-Automatisierung

  • just: Ersatz für make — fokussiert auf Tasks statt auf Builds, mit sprachunabhängiger, konsistenter Oberfläche wie just lint
    • „Man kann bei make zwischen zeilenweisem Modus und vollständigen Shell-/Python-/Node-Skripten pro Target umschalten“
    • Nachteil: Eingebettete Skripte werden nach $TMPDIR geschrieben und von dort ausgeführt; zudem gibt es eine eigene Templating-Sprache, die etwas im Uncanny Valley liegt
  • Task (go-task): YAML-basierte Alternative mit Batteries-included-Tendenz
  • universal-test-runner: erkennt automatisch, wie Tests im Repository ausgeführt werden, und reicht zusätzliche Argumente durch
  • chezmoi: verwaltet Dotfiles und Tool-Installationen konsistent über mehrere Maschinen hinweg

HTTP / Netzwerk / Secrets

  • Hurl: „Vergesst GUI-HTTP-Apps, die Informationen sammeln wollen“ — curl-Anfragen in einfachem Textformat, gut geeignet für Integrationstests
  • curl: ebenfalls vielfach als Kurzantwort genannt
  • SOPS: verschlüsselt Secrets mit age-/SSH-Keys, etwa im Muster sops exec-env secrets.yaml -- some command
  • Mutagen: bidirektionale Echtzeit-Dateisynchronisierung über SSH — nützlich für Arbeit auf Remote-Maschinen
  • forge: Alternative zur GitHub-CLI mit Codeberg-Unterstützung, schneller und aufgeräumter

Sonstiges / Workflow

  • Quarto: für schnelle Präsentationen in Markdown
  • Nushell: von PowerShell beeinflusste Shell, mit der sich große Transformationsskripte wie GeoPackage → PostGIS oder PostGIS-View → PMTiles zuverlässig schreiben lassen; Nachteil: vor Version 1.0 brechen Updates regelmäßig etwas
  • Typst: als LaTeX-Alternative erwähnt, bevorzugt wegen der call-by-value-basierten Syntax
  • Topiary: Formatter für viele Sprachen
  • Hunk: review-first Terminal-Diff-Viewer für agentische Coder, oft im --watch-Modus neben einem Coding-Agenten geöffnet
  • Raycast / Alfred: macOS-Launcher mit Snippets, Clipboard und parametrisierten Websuchen
  • Ergodox EZ: seit 10 Jahren genutzte Tastatur, überzeugend bei Anpassbarkeit und Stromverbrauch
  • Joplin / Fossil: selbstgehostete Notizen und Wikis
  • AeroSpace / Sway: Tiling-Window-Manager

Wiederkehrende Meta-Botschaften

  • „Wählt Tools mit guten Defaults und vermeidet endloses Konfigurieren“ — Helix, Fish, ripgrep und mise werden als typische Beispiele dieser Philosophie genannt
  • Gegenperspektive: Manche haben sich durch jahrelanges Tweaken ihr ganz eigenes Tool-System gebaut — „heute fasse ich es nur noch ein paar Mal im Jahr an“
  • Nebenwirkung des Zeitalters von AI-Agenten: Tools für jq, Markdown und strukturierten Text gelten zunehmend als vorteilhaft für die Zusammenarbeit mit LLMs — etwa reines Markdown in Obsidian, der Watch-Modus von Hunk oder die Empfehlung, das jq-Manual gründlich zu lernen
  • Vorsprung von macOS beim Grafik-Debugging: Das GPU-Profiling in XCode Instruments wird gegenüber Linux und Windows als klar überlegen bewertet
  • CLI-Renaissance vs. Typografie: Einerseits werden Terminal-Tools immer besser, andererseits lassen sich lange Ausgaben von LLMs oder Agenten letztlich in Browsern oder spezialisierten Apps typografisch angenehmer lesen

Verwandte Beiträge

8 Kommentare

 
kirinonakar 24 분 전

Ich habe einige ausprobiert, aber keines hat mir wirklich perfekt gefallen, deshalb baue ich gerade selbst eins. Ich orientiere mich an notepad++, VS Code, Zed und Obsidian und übernehme nur die Funktionen, die ich brauche.
 
xguru 10 시간 전

Ich nutze in letzter Zeit vor allem diese drei zusammen gebündelt: cmux, tmux und mux.
Wenn ich mich per SSH auf einen mit Tailscale verbundenen Server einlogge, zeigt mir fzf gebündelt die bestehenden tmux-Logins an, und dort wähle ich dann aus und gehe hinein.

cmux - Ghostty-basierendes Terminal für macOS für AI-Coding-Agenten
Show GN: mux – tmux-Session-Manager, der AI-Coding-Sessions in Live-Previews verwandelt
 
edunga1 2 시간 전

Auf dem Mac muss man doch im Terminal zweimal Enter drücken, um Koreanisch einzugeben, oder? (nach dem Abschließen der Hangul-Zeichenzusammensetzung noch zweimal zum Bestätigen)
Nur bei wezterm gibt es dieses Problem nicht, deshalb bin ich dorthin gewechselt.
 
onixboox 3 시간 전

Ich mag Zed.
 
snisty 5 시간 전

Ich kann inzwischen nicht mehr ohne Claude Code leben. + tmux..
Wenn ich noch etwas hinzufügen soll: VS Code als Texteditor..
Ansonsten noch unverzichtbare IDEs wie Visual Studio zum Bauen..
 
hwhang0917 8 시간 전

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

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

  • Ich nutze Helix als Texteditor. Für mich trifft es genau die richtige Balance zwischen Anpassbarkeit und einer großartigen Out-of-the-box-Erfahrung
    Aus demselben Grund nutze ich Fish als Terminal-Shell. Die Standardkonfiguration ist hervorragend, und ich muss kaum etwas anpassen, damit es so funktioniert, wie ich es will
    Je älter ich werde, desto mehr gefällt mir der Ansatz, meinen Geschmack bewusst an Tools mit guten Defaults anzupassen, statt endlos an Konfigurationen herumzuschrauben
    Atuin ist großartig für die Synchronisierung der Shell-Historie zwischen Remote-Maschinen und für kontextbezogene Verlaufssuchen auf Basis des aktuellen Verzeichnisses oder des Git-Repositorys. Es kann noch mehr, aber ich nutze nur diese Funktionen
    Mise gefällt mir ebenfalls in vielerlei Hinsicht, aber am liebsten nutze ich es als Tool-Version-Manager. Es hat mein früheres direnv ersetzt, und ich beginne auch, es in privaten Projekten nach und nach in leichte CI-Workflows zu integrieren

    • Der Weg mit guten Defaults ist meist auch der am gründlichsten getestete Weg, daher stößt man auf weniger Bugs. Im Allgemeinen eine kluge Entscheidung
    • Es gibt nicht nur „den eigenen Geschmack an Defaults anpassen“ und „endlos an der Konfiguration schrauben“. In meiner n=1-Erfahrung habe ich immer weiter, weiter, weiter konfiguriert und am Ende genau den Punkt erreicht, den ich wollte, und jetzt fasse ich es kaum noch an
      Vielleicht ein paar Mal im Jahr. Mein Emacs ist inzwischen wie mein ganz persönlicher Studley-Werkzeugkasten
    • Ich würde Helix gern mögen. Es ist wirklich ein elegantes Projekt und die Defaults sind attraktiv, aber mein Vim-Muskelgedächtnis ist einfach zu stark ausgeprägt
      Stattdessen habe ich vor ein paar Monaten Neovim komplett angenommen und meine über mehr als 10 Jahre organisch gewachsene .vimrc in Rente geschickt. Ein bisschen schade, aber dadurch beneide ich Helix weniger
      Mise ist auch gut und braucht praktisch kaum Konfiguration. Fish nutze ich ebenfalls erst seit ein paar Monaten und lasse es bis auf ein paar Benutzerfunktionen fast komplett auf den Standardeinstellungen
      Ripgrep erledigt im Standardzustand einfach „das Richtige“, sodass ich nicht einmal weiß, ob ich jemals versucht habe, es zu konfigurieren
    • Wie lernt man Helix eigentlich richtig? Ich versuche gerade, von Neovim wegzukommen, weil mich die Struktur, bei der Plugins mehr als 50 Repositories hereinziehen, wegen Supply-Chain-Angriffen zu sehr beunruhigt
    • Das spricht mir wirklich aus der Seele. Mit zunehmendem Alter verstehe ich immer weniger, wie Leute so viel an Tools und Software herumspielen können. Es macht keinen Spaß und lohnt sich nicht

  • Emacs

  • Vielleicht ist es Stockholm-Syndrom, aber bei mir ist es Nix. Es ist nicht perfekt, aber seit ich mit Nix ausdrucksstärker und effizienter arbeiten kann, hat es mir andere Linux-Distributionen und Meta-Build-Systeme praktisch verdorben
    Außerdem ist pwntools auch außerhalb von CTFs ein Werkzeug, mit dem es Spaß macht zu arbeiten. Zum Beispiel, wenn man in einer Python-REPL auf Bit-Ebene mit Sockets hantiert

    • Ich mag sowohl Nix als auch pwntools. Als jemand, der ebenfalls CTFs spielt, würde mich interessieren, wie du eine Nix-basierte CTF-pwn-Umgebung aufgesetzt hast, falls du so etwas hast
      Ich habe bisher immer einfach eine frische Ubuntu-VM mit libvirt hochgezogen und dort meine Tools installiert. Gibt es einen Nix-basierten Ansatz, den du empfehlen würdest?

  • Natürlich Emacs, insbesondere Magit

  • Nix. Es gibt eine Lernkurve. Ich war ein paar Jahre von Nix-Nutzern oder Evangelisten umgeben, bevor ich es ernsthaft ausprobiert habe, aber letztlich ist es ziemlich gut
    Mit mehreren Projekten war ich es leid, dass es für System-Level-Abhängigkeiten jeweils andere Tools gab. Eins für Node-Versionen, eins für Python-Versionen und so weiter
    Ich hatte auch genug von schwer zu debuggenden Build-Fehlern durch Inkompatibilitäten zwischen Projekten. In Projekt A ist $foo kaputt, also aktualisiert man es per Homebrew, und dann ist plötzlich in Projekt B $foo kaputt
    Ebenso nervig sind Builds, die von allerlei im System installierten, oft versteckten Abhängigkeiten ausgehen und dann „aus irgendeinem Grund“ fehlschlagen
    Ich habe so viel wie möglich in projektbezogene nix shells verlagert. Die Pakete auf Systemebene halte ich so schlank wie möglich, und in den Projekten pinne ich die exakt benötigten Tools, also Abhängigkeiten, Laufzeiten und Compiler, auf konkrete Versionen fest
    Dadurch verschmutze ich weder meinen globalen PATH noch andere Projekte. Wenn es bei mir jetzt funktioniert, bin ich ziemlich zuversichtlich, dass es auch in einem oder fünf Jahren noch funktioniert
    Wenn ich Tools upgraden will, kann ich das tun, ohne mir Sorgen um Auswirkungen auf andere Projekte zu machen, und falls es Regressionen gibt, kann ich leicht zurückrollen oder sogar nur eine einzelne Abhängigkeit auf eine ältere Version pinnen
    Noch besser ist es in Projekten, in denen auch Kolleginnen und Kollegen Nix nutzen. Der zusätzliche Aufwand für das Einrichten und Pflegen der nix shell wird geteilt, und die Gewissheit, dass alle dieselbe Entwicklungsumgebung haben, ist ebenfalls deutlich größer

    • Aus ähnlichen Gründen bin ich in letzter Zeit ziemlich auf Dev Containers hängen geblieben. Ich halte die Idee für ziemlich gut, aber leider ist die Tooling-Qualität nicht auf dem Niveau
      Zum Beispiel hat selbst die Referenz-CLI noch immer keinen stop-Befehl implementiert. Wenn man für Deployments ohnehin Docker/Container nutzt, hat man aber den Vorteil, dass sich viel Konfiguration zwischen Entwicklungs- und Deployment-Umgebung teilen lässt
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/) ist Software, die so magisch gut ist, dass ich nicht mehr ohne sie leben möchte

    • Früher wäre das ein Tool gewesen, das ich täglich gebraucht hätte. Toller Fund. Ich packe es in mein Second Brain, damit ich es wiederfinde, falls ich es später noch einmal brauche
    • Mich würde interessieren: Wo liegt für dich der größte praktische Nutzen von rr? Den allgemeinen Ansatz aus der Einführung auf der Projektseite verstehe ich
      Das Konzept, einen Fehler einmal aufzuzeichnen und diese Aufzeichnung dann deterministisch immer wieder zu debuggen, wirkt eindeutig nützlich
      Ich frage aber nach konkreter Erfahrung, weil mir noch dieses Gefühl fehlt von „Wow, dieser konkrete Bug/dieser Workflow wäre ohne rr praktisch unmöglich gewesen“

  • Ich komme aus der Systemadministration und stehe daher viel eher auf der Seite „gute Defaults mit minimaler Konfiguration nutzen“. Trotzdem haben in letzter Zeit zwei Dinge diese Gewohnheit bei mir aufgebrochen
    Über jujutsu(jj) wurde auch hier auf der Seite viel gesprochen, aber ehrlich gesagt fühlt es sich einfach richtig gut an. Ich hätte nie gedacht, dass ich die Git-CLI einmal hinter mir lassen würde, aber jetzt ist es so
    Jahrelang habe ich vermieden, mich mit nvim und dessen Konfiguration zu beschäftigen, aber nvchad hat mir den Einstieg ermöglicht. Der Name ist furchtbar, aber für mich ist es eine großartige Startkonfiguration, genau subjektiv genug über dem Minimalismus
    Natürlich bin ich inzwischen bei meiner eigenen Minimal-Konfiguration von Grund auf angekommen
    Ansonsten arbeite ich ziemlich viel mit Python, daher muss ich sagen, dass die Tools von astral durchweg angenehm zu benutzen sind. Hoffentlich kümmert Anthropic sich gut darum

    • Bei jujutsu gilt das sogar doppelt. Erst fühlt sich schon der Wechsel an sich gut an, und dann will man noch einmal nachbessern, weil die jj-Defaults noch nicht besonders ausgefeilt sind
      Wenn man keinen Text in typischer altmodischer Regenbogen-Einhornkotze mit hohem Kontrast auf dunklem Hintergrund haben will, muss man bei Farben und Templates ziemlich viel anpassen

  • Eigentlich ist es Emacs. Ich verlagere nach und nach mehr meiner Computerarbeit nach Emacs und fange an, die Defaults zu akzeptieren
    Emacs lässt sich wirklich leicht anpassen, und viele Keybindings tun in allen Modi das jeweils Sinnvolle
    Auf meiner Liste der langsam umgestellten Dinge stehen Git → Magit, E-Mail → mu4e, RSS → elfeed, Notizen/TODO/Kalender → org mode, Finder → dired
    Quarto ist ebenfalls ziemlich gut, wenn man schnell Präsentationen in Markdown erstellen möchte. Nix und nix-darwin nutze ich für alle meine Dotfiles

    • Für dired lohnt sich vielleicht ein Blick auf Dirvish

  • Emacs. Ich nutze es nicht oft, aber mit ragel Parser zu schreiben macht Spaß

  • Sublime Text wird von erstaunlich vielen Leuten definitiv unterschätzt

    • Ich wollte Sublime Text mögen, aber der vi-Modus passte nicht gut genug zu dem Muskelgedächtnis, das ich in Vim aufgebaut hatte, daher bin ich nie richtig dabeigeblieben
      Ich glaube, er hieß irgendetwas wie „vintage“. Heutzutage nutze ich in Situationen, in denen ich Sublime Text gern gemocht hätte, stattdessen Zed