KAkartikarti·Apr 30, 2025Submission
Elvish – Scripting language and interactive shell
80 points · Open discussionelves
elvish
Go2015–2025
elves / elvish
elvish
Powerful scripting language & versatile interactive shell
11Distinct people
27Mentions
0Explicit recommenders
6.4KGitHub stars
What to know before exploring
What it is
Powerful scripting language & versatile interactive shell
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- lmorg/murex · linked in 2 of the same discussions
- ngs-lang/ngs · linked in 2 of the same discussions
- xonsh/xonsh · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2015-02-05 12:16:03 UTC to 2025-04-30 11:51:42 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
27 sourcesI don't have a version with captions, sorry. You can find the slidedeck at https://github.com/elves/elvish/blob/master/website/slides/2...
The remaining 8% mostly falls into the following categories:
- Code that use OS functionalities that are cumbersome to mock in tests
- Code paths that are triggered relatively rarely and I was simply too lazy to add tests for them
Nothing is impossible to cover, but for whatever reason it was too much work for me when I wrote the code.
However, it's worth mentioning that I only settled on the transcript test pattern fairly recently, and if I were to rewrite or refactor some of the untested code today I would add tests for them, because the cost of adding tests has been lowered considerably. So Elvish's test coverage is still increasing slowly as the cost of testing decreases.
In Language and shell in Go with 92% test coverage and instant CI/CD [video]There's indeed a feature request for it: https://github.com/elves/elvish/issues/322
I can't promise anything, but I'm undertaking a major refactoring of Elvish's TUI and that should make it much easier to implement this feature in the near future.
In Elvish, expressive programming language and a versatile interactive shellneat.
that's pretty much what i had in mind, but only for a single rename.
i just did a search and embarrassingly discovered imv which is part of the renameutils package which also contains qmv, a tool to batch rename lots of files by loading the list into an editor. embarrassed because qmv is my favourite tool for batch renaming, and so i have it already installed.
imv is exactly what i am looking for, for the single file rename case: "The imv ("interactive move") program, is trivial but useful when you are too lazy to type (or even complete) the name of the file to rename twice. It allows a file name to be edited in the terminal using the GNU Readline library."
so we can consider this problem solved.
back to alternative shells: i am just spoiled by fish (no the fish isn't spoiled): autosuggestion and non-incremental search like fish are
Read the rest
a requirement for me to consider any other shell now.
btw: autosuggestion for elvish is being discussed here: https://github.com/elves/elvish/issues/322 and apparently it has some of that search feature too (from a comment): "type the beginning of a command and press Up and cycle through all the commands that start with the string I typed."
i am going to have to try that.
> This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user.
No, it's both. The XDG state dir is for things that are also machine-specific so that, e.g., it doesn't make sense to sync them as part of your dotfiles.
> why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the rules, these files should be within the .config/ directory as well.
They should! Some shells have kindly moved to follow this convention following requests from users who like it for other apps and would prefer more uniformity w/r/t config file location conventions, e.g.: https://github.com/elves/elvish/issues/383
In Use the XDG Base Directory SpecificationFuzzing is awesome. I just discovered an accidental O(2^n) code path in my project with fuzzing and fixed it: https://github.com/elves/elvish/commit/9cda3f643efafce2df567...
Edit: shortly after I wrote this comment, fuzzing discovered another pathological input - and that was fixed in https://github.com/elves/elvish/commit/04173ee8ab3c7fc4a9e79...
(In case people are curious, the project is a Unix shell, Elvish: https://elv.sh)
In Go FuzzingPowershell is available on Linux. Albeit it doesn't always play too nicely with existing CLI tools.
There are also other typed shells that appeal to yourself which aren't Powershell but do have behaviours similar to Powershell and which do play a lot more nicely with the wider Linux / UNIX ecosystem:
- murex https://github.com/lmorg/murex
- Elvish https://github.com/elves/elvish
- NGS https://github.com/ngs-lang/ngs
I'm the maintainer of murex so happy to answer any questions on that shell here. I do know the the maintainers of Elvish and NGS pop on HN too.
In Unix Shell Programming: The Next 50 YearsThat paper misses a lot. Including:
- murex https://github.com/lmorg/murex
- Elvish https://github.com/elves/elvish
- NGS https://github.com/ngs-lang/ngs
- Powershell
- And any language REPLs turned into shells, such as Python, LISP, Lua and others.
The author did say there is more to follow though so maybe the scope of this article was a little more closed by intention.
In Unix Shell Programming: The Next 50 Years> I don't get why structured data over pipelines is useful. You can already exchange any kind of data over pipeline as string of bytes.
The Elvish docs have a pretty good answer to this here[0], but I'll give my own answer, too.
There are a few things. Structured pipelines spare you from having to do escaping and transformations in order to preserve structure.[1] It's also a natural complement to a type system. Some other next-gen shells call their structured pipelines ‘typed pipelines’ instead.[2] Structured pipelines also provide a nice mechanism for separating the visual/textual representation of data from its structure, so you can ‘convert’ values between different display formats without doing any parsing, in a convenient, extensible way. PowerShell has this with Format-List[3] and Format-Table[4], for example. This kind of pretty-pr
Read the rest
inting isn't implemented in Elvish yet, but Kurtis Rader helped me outline one possibility in an open GitHub issue.[5]
On some level, structured pipelines just mean that commands ‘native’ to the shell language (builtins and functions written in the shell language) all understand the same types or data structures. This means you can ingest data from some external format (JSON, CSV, TOML, a SQL result, whatever) and then use common tools. Nushell's first example for working with pipelines[6] hints at one of these benefits: you can use a single command, like `inc` to increment the value associated with a certain key in a map, with data that comes from any format, and `inc` doesn't have to know anything about data formats or parsing.
Another way to think about it is that it lets pipelines have the same kind of type checking as functions called with arguments. In a typed language, you get type checking for your arguments when you call a function like
(some_command arg0 (another_command arg1 arg 2))
but in a way, pipelines are an alternative to subshells.[7] If you want passing values through the pipes to be as robust as passing them as arguments, you need structured pipelines.
You're right that if you are using a lot of external commands in a ‘raw’ way, you don't get to take much advantage of the structured pipeline. Imo PowerShell proves that in practice, if you have a big enough library ecosystem, you can leverage wrappers and ‘pure’ tools written in your shell language to get a pretty nice programming experience.
—
0: https://elv.sh/learn/unique-semantics.html#motivation
1: https://elv.sh/learn/effective-elvish.html#returning-values-...
2: https://murex.rocks/docs/user-guide/pipeline.html
3: https://docs.microsoft.com/en-us/powershell/module/microsoft...
4: https://docs.microsoft.com/en-us/powershell/module/microsoft...
5: https://github.com/elves/elvish/issues/1149#issuecomment-705...
6: https://www.nushell.sh/book/pipeline.html#basics
7: https://elv.sh/learn/effective-elvish.html#prefer-pipes-over...
Bash is ugly and rife with pitfalls, but it can be incredibly productive for certain classes of problems if you know what you’re doing. Trying to use Python or Go to whack some external commands together feels very cumbersome to me.
For pure programming, “real” languages are absolulely preferable in almost every way, but all of them fail when it comes to running external programs and redirecting their output in a way that doesn’t make me pull my hair out. As a heavy user of both “real” programming languages and shell scripting languages, I’m left craving something that brings the best of both worlds.
There are a number of newer shell projects in this vein that are very exciting, like Oil [0], Elvish [1], and Xonsh [2]. I was also hopeful that Neugram [3] would go somewhere, but the project seems to have died out. While many people cite Ba
Read the rest
sh’s lack of portability as a reason not to use it, I find Bash to be very portable for my use cases and avoid using these newer shells for their lack of portability. Maybe one day we can have nice things.
[0]: https://github.com/oilshell/oil
[1]: https://github.com/elves/elvish
[2]: https://github.com/xonsh/xonsh
[3]: https://github.com/neugram/ng
FYI for Windows users, no Unicode
https://github.com/elves/elvish/issues/1124
In Elvish is a friendly interactive shell and an expressive programming languageThat sounds useful. I used to write tons of ZSH scripts when I used to obsessively make my Linux desktop experience nice and automated. Writing custom completions always felt awkward for me and unintuitive (like most ZSH programming).
Does your shell_completion library work with ZSH? I'm not familiar with how sh/bash differs here from ZSH but I'd image it'd be easy to make compatible.
I'm waiting patiently for Evlish to mature so I can use their Go-like (and Go-powered) scripting language and burn my old ZSH scripts in a fire. https://github.com/elves/elvish
In Shell Completions in RustFWIW, POSIX emulation is on my TODO list: https://github.com/elves/elvish/issues/205
Not sure whether I will actually get to it though. Parsing sounds like a lot of headache. Your work is very impressive, but I’m not sure I will want to go through that... :)
In Why Create a New Unix Shell?I checked out Oil previously which looks nice but more of an incremental improvement over Fish/ZSH rather than a significant evolution (it may have changed since then, this was last year).
Im most excited about Elvish shell and the language that's being developed around it. The shell is built with Go and feels super fast compared to my plugin-heavy ZSH. The language design is quite nice too but still very alpha. Looking forward to see what it evolves into...
https://github.com/elves/elvish
In Why Create a New Unix Shell?Nice, I've been waiting for a good modern shell to replace ZSH. Fish just wasn't enough of an improvement for me to abandon ZSH. This is an area where most open-source developers have avoided, as it's a "solved" problem, but it really isn't.
I'm currently waiting on Elvish [1] to mature. It's written in Go [2], but they're developing a new language on top of it for shell scripting, which I tried for a week. It's a nice modernization and is incredibly fast but still very alpha.
You don't realize how slow ZSH/Bash is (even without plugins) until you try a modern shell, and there are very few good modern shells around.
Besides performance my primary complaint is just how awful coding in ZSH is. I've been doing it for years and I still feel like I'm running into walls constantly and struggling to write 'clean' code that isn't full of hacks an
Read the rest
d workarounds.
High performance + modern scripting language = my ideal future shell
[1] https://elvish.io/
[2] https://github.com/elves/elvish
Showing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.