Elvish, expressive programming language and a versatile interactive shell

Project overview & goals

  • Elvish is presented as an expressive shell with a structured, non-string-centric language, aiming to combine:
    • PowerShell-style structured data,
    • “Unix-y” sensibilities of traditional shells,
    • interactive UX focus similar to fish.
  • Intended to be both an interactive shell and a serious scripting language with fewer pitfalls than POSIX shells.

Syntax, semantics & safety

  • Examples highlight:
    • safer glob handling (no “*.jpg” when no matches),
    • less quoting boilerplate, more explicit string operations (str:trim-suffix vs ${x%y}),
    • first-class lists, maps, lambdas, arbitrary-precision integers and rationals.
  • Some find the syntax changes “cosmetic” or trivial compared with bash; others argue these avoid common bugs and footguns and improve daily ergonomics.
  • Lambda syntax {|arg| ... } is discussed; it evolved from earlier forms and resembles Ruby/Smalltalk.

Comparison with other shells & languages

  • Compared to:
    • bash/ksh: more consistent, fewer edge-case traps, but lacks ubiquity.
    • fish: Elvish scripting seen as nicer; fish autocomplete considered superior by some.
    • Nushell, Murex: similar focus on structured data; job control support varies.
    • PowerShell: similar data orientation but Elvish avoids heavy OO and slow startup.
    • Tcl and others (Julia, Python, Guile) mentioned as alternative scripting options.

Adoption, compatibility & “real-world” value

  • Some argue new shells don’t address the “trillion hacky things” done in bash and will remain niche toys.
  • Others emphasize:
    • incremental adoption (use Elvish for either interactive use or new scripts only),
    • that shells are largely about “cosmetic convenience” and that ergonomics matter.
  • Standardization and ubiquity are cited as reasons to stick with bash despite its flaws.

Author clarifications & roadmap

  • Encourages viewing Elvish as an additional tool, not a hard switch.
  • Future ideas:
    • easier construction of lightweight TUIs (“TUIlets”) from scripts,
    • better homelab/build-farm management tooling,
    • stronger LSP/editor integration,
    • possible improvements to autocomplete (fish-like suggestions) and job control (e.g., ^Z).
  • Documentation quality and built-in LSP are repeatedly praised.