3 ms·

BTW I refactored/edited this wiki page as part of this update of the FAQ, which compares Oil to other shells: http://www.oilshell.org/blog/2021/01/why-a-new-sh

by chubot 6y ago

BTW I refactored/edited this wiki page as part of this update of the FAQ, which compares Oil to other shells: http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#comparisons http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#co...

wodenokoto 6y ago
On that page you write that “you _can_ use oil in production but ...” which sounds like you recommend against it. Later you write that oil is best for automation and fish is better for interactive usage. This got me confused. Do you recommend that I run fish in my terminal, rewrite my one liners to oil when they outgrow their one line, but use bash in production? With that being said I really appreciate how honestly you write about the limitations of oil and benefits of competing shells. Few project seems to be as open minded about their competitors and aware of their own short comings as oil, which in my opinion is what you want out of something you put your trust in.
- chubot 6y ago
  Yeah I would like Oil to be the best of both worlds, but realistically it won't be in 2021. That dichotomy is sort of explained at the top of the FAQ: shell as a language vs. shell as a UI. (I plan to use bash interactively and Oil for scripting for awhile, which is natural because Oil runs bash scripts. Others may want to use fish; fish is too incompatible for me.) However in 2021 I hope to remove the qualifier about slowness. That's the only reason I don't use it in production now! (There are several Oil-only features that I want to use in production, like better tracing.) --- I've written several times on the blog about how the scope of the project is too big, especially in the last year :) So the goal is really to have Oil be the best for ONE use case, and I think that's "cloud automation". I will run Oil's own extensive continuous build to Oil as part of this. And once people are using it for that, it should attract contributors, which will address the "scope" problem. Oil is very compatible with bash -- the most compatible by a mile. It's very modular, and I mentioned in this thread how you could do things with it you can't do with bash. So basically everything about the project is working, but it takes a long time. The thesis from the beginning has panned out -- otherwise I would have stopped working on it already :) It turns out it really is the best thing for what I want to do, and I'm confident that will generalize. Shell is becoming more important, not less important! (I have some upcoming posts about this, i.e. regarding distributed systems and "the YAML problem".) We need a better shell -- that's a smooth upgrade from POSIX shell and bash.

by chubot 6y ago

wodenokoto 6y ago

On that page you write that “you _can_ use oil in production but ...” which sounds like you recommend against it. Later you write that oil is best for automation and fish is better for interactive usage. This got me confused. Do you recommend that I run fish in my terminal, rewrite my one liners to oil when they outgrow their one line, but use bash in production? With that being said I really appreciate how honestly you write about the limitations of oil and benefits of competing shells. Few project seems to be as open minded about their competitors and aware of their own short comings as oil, which in my opinion is what you want out of something you put your trust in.

chubot 6y ago
Yeah I would like Oil to be the best of both worlds, but realistically it won't be in 2021. That dichotomy is sort of explained at the top of the FAQ: shell as a language vs. shell as a UI. (I plan to use bash interactively and Oil for scripting for awhile, which is natural because Oil runs bash scripts. Others may want to use fish; fish is too incompatible for me.) However in 2021 I hope to remove the qualifier about slowness. That's the only reason I don't use it in production now! (There are several Oil-only features that I want to use in production, like better tracing.) --- I've written several times on the blog about how the scope of the project is too big, especially in the last year :) So the goal is really to have Oil be the best for ONE use case, and I think that's "cloud automation". I will run Oil's own extensive continuous build to Oil as part of this. And once people are using it for that, it should attract contributors, which will address the "scope" problem. Oil is very compatible with bash -- the most compatible by a mile. It's very modular, and I mentioned in this thread how you could do things with it you can't do with bash. So basically everything about the project is working, but it takes a long time. The thesis from the beginning has panned out -- otherwise I would have stopped working on it already :) It turns out it really is the best thing for what I want to do, and I'm confident that will generalize. Shell is becoming more important, not less important! (I have some upcoming posts about this, i.e. regarding distributed systems and "the YAML problem".) We need a better shell -- that's a smooth upgrade from POSIX shell and bash.