oils VS elvish

Hm I'm not familiar with that library (or really any others in the landscape). Why pick that one?

I'd be interested in a review / survey, and the strategy for testing. Basically the tests should "argue" that the code is correct, and documentation / blog posts also count!

(I'm honestly not sure how hard it is to make a correct big num library. But I think the original article in this series said there were probably bugs, so I'm guessing it's not trivial)

To give a flavor, we publish test results and and coverage numbers like this [1], and any new library should be consistent with this:

https://www.oilshell.org/release/0.22.0/quality.html

Our GC runtime has less than 5000 lines of hand-written C++ now, so any solution should be in proportion to that. That is, we probably wouldn't take on 3000 lines of code just for big nums.

So we favor correctness over performance. Hopefully there would be little perf loss in the small int case, but it's OK if the big int case is slow. It's the rarer case for sure.

---

As far as the grant, we pay in 2500 euro or 5000 euro increments, and I don't try to parse it any more than that. I care about the result, not if it's easy for a particular person :)

For example earlier this year we had a contributor Justin who worked on the pretty printer, with Wadler's algorithm (which I was unfamiliar with).

https://www.oilshell.org/blog/2024/06/release-0.22.0.html

And he had co-authored a paper on pretty printing, so it was probably not too difficult overall. But that's a good thing as far as I'm concerned!

So if you or anyone else thinks it's easy, please feel free to contact me / play around with the code, etc.

https://github.com/oilshell/oil/wiki/Where-Contributors-Have...

[1] our unit test coverage is reported at 83% or so, but we favor "exterior" tests, so it's really close to 95% or 99%. Also of course line coverage is a misleading metric.

All these programs will output ANSI color if `isatty(stdout)` is true (roughly speaking).

Most people didn't quite get that -- they thought we should use "nREPL" or something -- but my opinion is that you really need a specific protocol to communicate with a shell, because a shell spawns other programs you still want to work.

---

Here is a pure Python 3 implementation of the recv() side of FANOS in only ~100 lines

https://github.com/oilshell/oil/blob/master/client/py_fanos....

It uses the recvmsg() binding . I'm pretty sure node.js has that too? i.e. it has Unix domain socket support

---

Anyway, thanks for taking a look - we're interested in feedback!

This is similar to how https://www.oilshell.org/ is written

There are two complete implementations

1. one that runs under a stock Python interpreter (which doesn't use static types)

2. one that's pure C++, translated from statically typed Python code, and from data structures generated in Python

In the second case, everything before main() is "burned off" at build time -- e.g. there is metaprogramming on lexers, flag parsers, dicts, etc. that gets run and then into static C data -- i.e. pure data that incurs zero startup cost

Comparison to Pre-Scheme: https://lobste.rs/s/tjiwrd/revival_pre_scheme_systems_progra... (types, compiler output, and GC)

Brief Descriptions of a Python to C++ Translator - https://www.oilshell.org/blog/2022/05/mycpp.html

...

And related to your other point, I remember looking at Racket's implementation around the time it started the Chez Scheme conversion. I was surprised that it was over 100K lines of hand-written C in the runtime -- it looked similar to CPython in many ways (which is at at least 250K lines of C in the core).

Is it an array of strings because it's a "simple command"? Or does it behave like an assignment? You get two different answers depending on how you look at it.

The bottom line is that assignment builtins are special and they don't follow the normal rules of simple commands. Shells have differed, but POSIX decided on this awhile ago.

---

This is all of course mind numbing trivia that has no real reason for existing ... YSH fixes it, and it's now pure native C++, no more Python.

YSH Doesn't Require Quoting Everywhere - https://www.oilshell.org/blog/2021/04/simple-word-eval.html (Oil was renamed to YSH since this blog post was written)

Simple Word Evaluation in Unix Shell - https://www.oilshell.org/release/latest/doc/simple-word-eval...

In YSH you can tell just by looking it's a single string or an array.

    ls $a  # identical to ls "$a"

Oils is a different approach to this - the base “OSH” language is pretty much identical to bash, and then you can incrementally opt in to more checks and QOL improvements.

The key selling point is that you never have to totally rewrite your existing bash scripts - there’s an incremental upgrade path.

https://www.oilshell.org/

While I don't agree with most of your analysis - in particular for the second example, I'd invite you to read its explainer that goes into much more depth (https://elv.sh/learn/scripting-case-studies.html#update-serv...) - I think you might be more interested in the Oil Shell project, which is trying to chart a smooth upgrade path from bash: https://www.oilshell.org

I think we simply can't say for sure which path is better for the future of shells, and I'm quite excited by the fact that different projects are exploring different directions. I will just stick to the path I find best and won't try to convert you :)

Some related references (on a somewhat messy wiki page) - https://github.com/oilshell/oil/wiki/Compact-AST-Representat...

Feel free to add others

will prevent almost all of the "silent footguns".

YSH has strict:all and then a bunch of NEW features.

There's been good feedback recently, which has led to many concrete changes. So your experience can definitely influence the language! https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback

Regarding writing tools/tests/benchmarks in bash+Python, vs. writing tools in your main language:

I think we might eventually concede that something Debian-like is the “standard development environment” (at least for server side stuff, i.e. not iOS apps)

In this case, bash+Python is a non-issue. It works extremely reliably. That’s actually why I use it! Everything else seems to break, or it’s really slow (node.js is a very common alternative).

- Microsoft conceded this back in ~2017, by building Linux into their kernel with WSL, and providing Ubuntu on top

Yes bash + Python is a disaster on Windows (I have scars from it), but Microsoft agrees that the right place to solve that is in Windows :-)

- Every CI system runs Debian/Ubuntu

- Every hosting provider runs Debian/Ubuntu

- Every online dev env like gitpod.io provides Debian/Ubuntu

This is somewhat related to remote dev envs: https://lobste.rs/s/ucirlx/lapdev_self_hosted_remote_dev

One vision for https://www.oilshell.org/ is that the CI environment is the dev environment is the hosting environment.

Everything is just an equal node in a distributed system. BUT it’s more git like, in that you explicitly sync and work “locally”, wherever that is. You don’t have the network chatter and flakiness of “the cloud”.

Oils has a very large set of monotonically increasing properties too - https://www.oilshell.org/release/0.21.0/quality.html

All that is bash+Python that is run on every commit, and it’s extremely good at catching bugs and perf regressions.

I’m skeptical that any project has that level of quality automation written in pure Rust or Zig. More likely it’s a bunch of cloud services with YAML.

Also a bunch of “hard-coded” toolchains that you can’t script with bespoke code. Like some shell commands in your package.json, which is just a worse way of writing a shell script.

Our quality process is all self-hosted, in the repo, and runs on both Github Actions and sourcehut - https://www.oilshell.org/release/0.21.0/pub/metrics.wwz/line...

bash and Python runs perfectly on Github Actions and sourcehut, with zero change. Containers also do.

(Although we need to unify the CI and release, because the release runs on 2 different real hardware machines, while CI is cloud only.)

Also, a main point Oils is that bash now has another highly compatible, spec-driven implementation – OSH. Having 2 independent implementations is something newer languages don’t have.

(copy of lobste.rs comment)

in your bashrc to enable it. I've used it for probably ~18 years now.

It also works with https://www.oilshell.org/ since we use GNU readline. Just 'set -o vi' in ~/.config/oils/oshrc

I gave a talk about the design: https://www.youtube.com/watch?v=wrl9foNXdgM

As the sibling comment mentioned, you can find documentation on Elvish itself on the website https://elv.sh. There are tutorials and (not 100% but fairly complete) reference documents.

I take your comment as implying that https://elv.sh is nice, clean and elegant, and thank you for the compliment :)

I can't speak for other people, but I made it on my own and don't have any formal training in design.

With the risk of stating the obvious, you first have to realize that as a developer you can make a reasonably clean-looking website on your own. There are just a few basic ingredients: choose fonts, tweak spacing, position elements, draw some background shades, round some corners. You can do any of these from CSS.

After that it's browsing other websites for what looks nice, and a lot of trial and error with CSS. You can do a lot of experiments from the browser's dev tool before committing them into the stylesheet too. But at the end of the time, you have to put in some time. The layout of the current homepage was redone just a few months back and it took me (IIRC) 3 days to tweak everything to my satisfaction.

Shameless plug: Elvish is a shell with a filesystem navigator built in - you can see it in demo 5 on the homepage https://elv.sh

- https://github.com/elves/elvish

If you are looking for a more sane *shell* scripting language, Elvish looks promising: https://elv.sh/