There's only 7K lines of C++ in Oils, mentioned in this post, and we intentionally keep it down. (It's for the garbage collector and OS bindings -- basically the unsafe parts.)
The rest is typed Python (with algebraic data types), which more common and simpler than Zig or Rust.
It's not as fast as Zig or Rust, but
1. The shell is the same speed when it's running external processes (and we do measure)
2. I believe it can be as fast as bash's hand-written C, even for code that doesn't do I/O (which isn't common but exists). We're perhaps ~50% the speed now, being "hilariously unoptimized".
This release mentions a big optimization, but the bigger point is that we have leverage via metaprogramming. We can do transformations on the entire interpreter (e.g. "boxless" transformation)
3. It means we only have 40K lines of Python, compared to 142K lines of C in bash. If you add YSH, we will only have around 50K lines, compared to probably 200K lines if you wrote it by hand
So the whole program is closer to an executable spec -- there is less room for bugs to hide.
It's easier to optimize 50K lines that is known to be correct (with thousands of tests), than 200K lines of code
---
Our binary is about 1.5 MB of executable code with no dependencies other than libc and (optional) GNU readline.
On the other hand, shells in Rust seem to have a big tree of dependencies and end up at 20 - 50 MB. It's not the size I'm concerned about, so much as the stability
As mentioned before, our approach is unusual, but I think the "usual" approaches haven't worked well. That said, if someone wrote a compatible shell from scratch in Zig or Rust (with limited dependencies), I think that would be also be valuable contribution
---
Oils is also aimed at the system level, and is an "exterior" shell that uses processes and file descriptors. Comparison with PowerShell, Elvish, nushell here:
The rest is typed Python (with algebraic data types), which more common and simpler than Zig or Rust.
It's not as fast as Zig or Rust, but
1. The shell is the same speed when it's running external processes (and we do measure)
2. I believe it can be as fast as bash's hand-written C, even for code that doesn't do I/O (which isn't common but exists). We're perhaps ~50% the speed now, being "hilariously unoptimized".
This release mentions a big optimization, but the bigger point is that we have leverage via metaprogramming. We can do transformations on the entire interpreter (e.g. "boxless" transformation)
3. It means we only have 40K lines of Python, compared to 142K lines of C in bash. If you add YSH, we will only have around 50K lines, compared to probably 200K lines if you wrote it by hand
So the whole program is closer to an executable spec -- there is less room for bugs to hide.
It's easier to optimize 50K lines that is known to be correct (with thousands of tests), than 200K lines of code
---
Our binary is about 1.5 MB of executable code with no dependencies other than libc and (optional) GNU readline.
On the other hand, shells in Rust seem to have a big tree of dependencies and end up at 20 - 50 MB. It's not the size I'm concerned about, so much as the stability
As mentioned before, our approach is unusual, but I think the "usual" approaches haven't worked well. That said, if someone wrote a compatible shell from scratch in Zig or Rust (with limited dependencies), I think that would be also be valuable contribution
---
Oils is also aimed at the system level, and is an "exterior" shell that uses processes and file descriptors. Comparison with PowerShell, Elvish, nushell here:
https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...
i.e. "shell" is a bit overloaded, and in some sense those tools are "one level higher".