3 ms·

Couldn't agree more and at this point, virtually every new mainstay tool I adopt is written in Zig or Rust and I can't see myself migrating to a shell written i

Couldn't agree more and at this point, virtually every new mainstay tool I adopt is written in Zig or Rust and I can't see myself migrating to a shell written in C/C++. Especially when something like nushell so elegantly avoids the situation you're describing. (I use nushell as my daily driver shell, and bang out scripts in it on an hourly basis. It's a blessing to use, though still missing an essential "shell" feature or two)

chubot 3y ago
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: https://www.oilshell.org/blog/2023/06/ysh-design.html#survey-of-alternative-shells 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".
LispSporks22 3y ago
Is it still missing job control?
- predictabl3 3y ago
  That's basically the biggest thing I'm missing. I think there's still a few FD redirection tricks that I use occasionally in zsh that are also missing (and are hard to hack in due to lack of job control).
  - chubot 3y ago
    BTW Oils has job control (thanks to contributor Melvin Walls), and it also has almost almost all bash redirects ... any zsh redirects can likely be added trivially!

chubot 3y ago

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: https://www.oilshell.org/blog/2023/06/ysh-design.html#survey-of-alternative-shells 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".

LispSporks22 3y ago

Is it still missing job control?

predictabl3 3y ago
That's basically the biggest thing I'm missing. I think there's still a few FD redirection tricks that I use occasionally in zsh that are also missing (and are hard to hack in due to lack of job control).
- chubot 3y ago
  BTW Oils has job control (thanks to contributor Melvin Walls), and it also has almost almost all bash redirects ... any zsh redirects can likely be added trivially!