I went down this route based on HN recommendations, with some people calling it stable well documented.
There's TODOs all over the documentation! There's no background task tools for scripting, and in interactive use background tasks are barely supported - an issue about background tasks has people going roughly "nobody needs to do tasks in parallel, that was only important when people were working on mainframes". The shell hooks have (undocumented) weird restrictions. Lazy iteration of lists is only supported by using functions with callbacks. Stable = development appears stopped.
This is half baked and dead. For my new computer I really really wanted a lightweight new shell with orthogonal syntax thought out from the ground up and not glued together over 4 decades, and this seemed like the closest option! But this isn't it.
While removing weird stuff from daily bash annoyances is interesting, I'm not necessarily looking to replace that with brand new but also pretty random weird stuff. Adding new rules isn't the same as adding structure. The documentation is also frequently strange in a way that makes it hard to digest. From https://elv.sh/learn/first-commands.html#external-commands
> While Elvish provides a lot of useful functionalities as builtin commands, it can’t do everything. This is where external commands come in, which are separate programs installed on your machine. Many useful programs come in the form of external commands, and there is no limit on what they can do. Here are just a few examples: Git provides the git command to manage code repositories
At first I thought, wait, is this a shell or not, do I have to write code or something to get access to normal external commands? But no, this is more like going to a car dealership and having the salesman say "Hey thanks for coming by, a car is a mechanical device consisting of metal parts and rubber parts for the purpose of taking you where you need to go! Now that we're on the same page about that, money is a thing made of paper for the purposes of .."
Docs are hard, once or twice is fine, but lots of parts are like this and I gave up reading. Not sure if it's AI generated, but if the project is doing that then it should stop, and if it's not doing that it should consider starting to
I mean, you are literally reading the first chapter of the tutorial for beginners (“Beginner's Guide to Elvish is for you if you haven’t used shells a lot or want to brush up on the basics”).
I did browse around, that's the page I got the first part of my comment from. Modules are one example of something that sounds probably good (https://elv.sh/ref/language.html#modules ). Good stuff is really weakened though by the many random changes that seem to go from arbitrary to.. also arbitrary, while destroying any chance of readability, backwards compatibility, or interoperability. Why?
> Line continuation in Elvish uses ^ instead of \
> Bash: echo .[ch] vs Elvish: echo .?[set:ch]
One more example, guess what this does: `echo &sep=',' foo bar`. Is it bash, elvish? Some combination of the two with markdown? Legal in all three? Elvish certainly cleans up conditionals and stuff, but you probably shouldn't introduce new things with exactly the same name unless you've created a genuine superset/dialect where the older version still works without rewrite. Namespace it as elvish.echo or use your module system. Shadows aren't friendly, this is equivalent to the guy that monkey-patches sys.stderr=sys.stdout to work around their one-off problem
Looks nice. Obviously way better than Bash, but there are a few options that are way better than Bash, so I feel like it should spend some time convincing me why I should use this over e.g. Nushell.
The Nushell and Elvish scripting languages are similar in many ways. I personally find the "shell" experience better in Nushell than Elvish.
Nushell
- Bigger community and more contributors
- Bigger feature set than Elvish
- Built in Rust (Yay :-)! )
Elvish
- Mostly developed by one person
- Built in golang
- Amazing documentation and general attention to detail
- Less features than Nushell
- Feels more stable, polished, complete than Nushell. Your script written today more likely to work unaltered in Elvish a year down the line. However this is an impression. Nushell must have settled down since I last looked at it.
For "one off" scripts I prefer Elvish.
I would recommend both projects. They are excellent. Elvish feels less ambitious which is precisely why I like it to write scripts. It does fewer things and I think does them better.
Nushell feels like what a future scripting language and shell might be. It feels more futuristic than Elvish. But as mentioned earlier both languages have a lot of similarities.
I don't think it matters whether it's Rust or Go especially, for an end user tool. But it definitely matters if it's Rust/Go compared to something else like C or Python.
The language choice has certain implications and I would say Rust & Go have fairly similar implications: it's going to be pretty fast and robust, and it'll have a static binary that makes it easy to install. Implications for other languages:
C: probably going to have to compile this from source using some janky autotools bullshit. It'll be fast but segfault if you look at it funny.
Python: probably very slow and fragile, a nightmare to install (less bad since UV exists I guess), and there's a good chance it's My First Project and consequently not well designed.
I don't use Elvish daily (I use fish) but writing scripts in Elvish is a great experience. The elvish executable can serve as an LSP server and that makes writing Elvish scripts a bit easier.
I don't care much for the Elvish shell experience, rather I like the Elvish scripting language. The documentation is top notch and the language evolves slowly and feels stable.
The shell prompt is also a small interface. How your shell responds to tab autocomplete, provides suggestions etc. can be quite helpful. Here I just like the way fish suggests filenames, provides an underline for filenames that exist and so on.
The language is what you write in an $EDITOR. Here Elvish scripts can be nice, succinct and powerful. I like how I don't have to worry about strange "bashisms" like argument quoting etc. Everything feels consistent.
I went down this route based on HN recommendations, with some people calling it stable well documented.
There's TODOs all over the documentation! There's no background task tools for scripting, and in interactive use background tasks are barely supported - an issue about background tasks has people going roughly "nobody needs to do tasks in parallel, that was only important when people were working on mainframes". The shell hooks have (undocumented) weird restrictions. Lazy iteration of lists is only supported by using functions with callbacks. Stable = development appears stopped.
This is half baked and dead. For my new computer I really really wanted a lightweight new shell with orthogonal syntax thought out from the ground up and not glued together over 4 decades, and this seemed like the closest option! But this isn't it.
While removing weird stuff from daily bash annoyances is interesting, I'm not necessarily looking to replace that with brand new but also pretty random weird stuff. Adding new rules isn't the same as adding structure. The documentation is also frequently strange in a way that makes it hard to digest. From https://elv.sh/learn/first-commands.html#external-commands
> While Elvish provides a lot of useful functionalities as builtin commands, it can’t do everything. This is where external commands come in, which are separate programs installed on your machine. Many useful programs come in the form of external commands, and there is no limit on what they can do. Here are just a few examples: Git provides the git command to manage code repositories
At first I thought, wait, is this a shell or not, do I have to write code or something to get access to normal external commands? But no, this is more like going to a car dealership and having the salesman say "Hey thanks for coming by, a car is a mechanical device consisting of metal parts and rubber parts for the purpose of taking you where you need to go! Now that we're on the same page about that, money is a thing made of paper for the purposes of .."
Docs are hard, once or twice is fine, but lots of parts are like this and I gave up reading. Not sure if it's AI generated, but if the project is doing that then it should stop, and if it's not doing that it should consider starting to
I mean, you are literally reading the first chapter of the tutorial for beginners (“Beginner's Guide to Elvish is for you if you haven’t used shells a lot or want to brush up on the basics”).
They have a separate set of docs for people who do have some experience with other shells (https://elv.sh/learn/); you may find the quick tour more suitable for your speed: https://elv.sh/learn/tour.html
I did browse around, that's the page I got the first part of my comment from. Modules are one example of something that sounds probably good (https://elv.sh/ref/language.html#modules ). Good stuff is really weakened though by the many random changes that seem to go from arbitrary to.. also arbitrary, while destroying any chance of readability, backwards compatibility, or interoperability. Why?
> Line continuation in Elvish uses ^ instead of \
> Bash: echo .[ch] vs Elvish: echo .?[set:ch]
One more example, guess what this does: `echo &sep=',' foo bar`. Is it bash, elvish? Some combination of the two with markdown? Legal in all three? Elvish certainly cleans up conditionals and stuff, but you probably shouldn't introduce new things with exactly the same name unless you've created a genuine superset/dialect where the older version still works without rewrite. Namespace it as elvish.echo or use your module system. Shadows aren't friendly, this is equivalent to the guy that monkey-patches sys.stderr=sys.stdout to work around their one-off problem
Looks nice. Obviously way better than Bash, but there are a few options that are way better than Bash, so I feel like it should spend some time convincing me why I should use this over e.g. Nushell.
Anyone have any experience of both?
nushell vs Elvish
The Nushell and Elvish scripting languages are similar in many ways. I personally find the "shell" experience better in Nushell than Elvish.
Nushell
- Bigger community and more contributors
- Bigger feature set than Elvish
- Built in Rust (Yay :-)! )
Elvish
- Mostly developed by one person
- Built in golang
- Amazing documentation and general attention to detail
- Less features than Nushell
- Feels more stable, polished, complete than Nushell. Your script written today more likely to work unaltered in Elvish a year down the line. However this is an impression. Nushell must have settled down since I last looked at it.
For "one off" scripts I prefer Elvish.
I would recommend both projects. They are excellent. Elvish feels less ambitious which is precisely why I like it to write scripts. It does fewer things and I think does them better.
Nushell feels like what a future scripting language and shell might be. It feels more futuristic than Elvish. But as mentioned earlier both languages have a lot of similarities.
> Built in Rust
> Built in golang
Does that matter?
If you intend to be a contributor, of course the chosen language matters, but only a very small proportion of users will be contributors.
I don't think it matters whether it's Rust or Go especially, for an end user tool. But it definitely matters if it's Rust/Go compared to something else like C or Python.
The language choice has certain implications and I would say Rust & Go have fairly similar implications: it's going to be pretty fast and robust, and it'll have a static binary that makes it easy to install. Implications for other languages:
C: probably going to have to compile this from source using some janky autotools bullshit. It'll be fast but segfault if you look at it funny.
Python: probably very slow and fragile, a nightmare to install (less bad since UV exists I guess), and there's a good chance it's My First Project and consequently not well designed.
There are quirks specific to languages.
Rust tends to be marginally faster and compile to smaller binaries.
Go projects tend to hit maturity faster and develop quicker.
Its a relevant factor to quickly stereotype certain characteristics of development, but its not anywhere close to important.
What about fish? I've enjoyed using it for years.
There's a few obvious features missing in fish like backgrounding an alias or an equivalent to set -e, other than that I have no complaints.
The first thing I do on any machine is install fish.
fish is amazing. I use it as my primary shell.
But for writing scripts I would reach for Elvish/Nushell. More powerful.
Looks interesting! Does it have OOP features kinda like how powershell has that?
Anyone here using elvish on the regular? Anecdotes please!
I don't use Elvish daily (I use fish) but writing scripts in Elvish is a great experience. The elvish executable can serve as an LSP server and that makes writing Elvish scripts a bit easier.
I don't care much for the Elvish shell experience, rather I like the Elvish scripting language. The documentation is top notch and the language evolves slowly and feels stable.
> I don't care much for the Elvish shell experience, rather I like the Elvish scripting language.
It's a shell, aren't those two things supposed to be the same basically? Or - do you mean the interaction with the terminal/command-line?
The shell prompt is also a small interface. How your shell responds to tab autocomplete, provides suggestions etc. can be quite helpful. Here I just like the way fish suggests filenames, provides an underline for filenames that exist and so on.
The language is what you write in an $EDITOR. Here Elvish scripts can be nice, succinct and powerful. I like how I don't have to worry about strange "bashisms" like argument quoting etc. Everything feels consistent.