3 ms·

For the forseeable future, Oil won't overlap with fish very much. That is, unless someone gets in touch and makes a big effort! I talked about that here: http

by chubot 5y ago

For the forseeable future, Oil won't overlap with fish very much. That is, unless someone gets in touch and makes a big effort! I talked about that here: https://news.ycombinator.com/item?id=28547185 https://news.ycombinator.com/item?id=28547185 (also linked at the end of this blog post) Oil has the architecture and possibility to be something like fish (a great interactive shell). It has a nascent headless shell mode, e.g. for being driven by GUIs, which no other shell I know of has. As far as I recall, the Warp terminal that appeared here has to parse the stdout of a shell session in a weird way to deliver some nice UI features. The headless shell provides a clean API for that (or at least it should; people need to test it). And Oil uses a principled and accurate parser is for autocompletion. No other POSIX shell does this. But personally I'm putting that as a low priority in favor of the "batch" use case. I think the "killer use case" will probably be to have a better language for continuous builds and "cloud automation", which on current platforms like Github, Gitlab, and sourcehut use a lot of YAML and shell. I use a lot of this automation myself, and I expect it to dramatically increase in the software world in the next decade. And I expect new platforms to appear. There a lots of people complaining about playing whack-a-mole and with YAML and shell errors, waiting for a "git push" every time, etc. Also, these systems are profoundly inefficient. A better language could be the foundation for much better systems. Over the last year, the blog has hinted at this kind of thing pretty frequently. Get in touch if you're interested :)

EdwardDiego 5y ago
That's a great niche to focus on actually - there's a looot of Bash in a lot of systems.
jwdunne 5y ago
> I think the "killer use case" will probably be to have a better language for continuous builds and "cloud automation", which on current platforms like Github, Gitlab, and sourcehut use a lot of YAML and shell. I feel the pain of this. In fact, it often goes like this: 1. Start in Yaml since things are simple enough 2. Use a multi-line Yaml string when things get worse 3. Extract to a shell script when things get even worse than that Except things are still painful after step 3: I’m now writing bash. Shellcheck helps but still hit gotchas. Other team members avoid it completely. The problem with “just use Python” is that it’s not as straight forward as doing that. We have to set up venvs and make sure deps in requirements.txt are installed. And we’re not using it on the project we’re building (the languages we are using simply are not as good for scripts). What is needed is a better shell, where we don’t feel as apprehensive about using shell scripts for project automation and those shell scripts are maintainable by everyone on the team. I could internalise enough bash warts to write and maintain them, but I can’t expect to burden my team mates with crap that’s far more painful than it should be to maintain. So yeah, I’m now at a point where: 1. I’ll try a new shell and try for pastures greener 2. I’m sick to death of debugging half-baked Lisp-as-Yaml for automation and if the guys who solve 1 also solve this, I’d owe a debt I could never repay.
- JonChesterfield 5y ago
  You might like lua as a compromise between shell and python for this stuff. Embed any extra libraries you want in the lua executable and put that one file on $PATH.
  - chubot 5y ago
    I'd be interested in a report from someone who tries, but I doubt it will be pleasant. By default, typos in variable names are worse than in Python and worse than shell with set -u: they result in nil rather than an immediate exception. The 1-based indexing is something people complain about when coming from almost any other language (Python, JS, C, C++, Go, Rust, etc.). The key issue with shell is that most people write it without studying the language. I'm also unsure of Lua's stability guarantees. It's an embedded language that can change on every version. I know it has broken compatibility at least 4 times, because they're on Lua 5.x. You're expected to change your programs when you upgrade version of Lua, because it's an embedded language by design. It's very different than a shell. I have heard of people using Lua for "private" shell-like tasks, but I've never seen it in a real codebase, even though Lua is very popular and well documented.
    - 41b696ef1113 5y ago
      >I'm also unsure of Lua's stability guarantees. LuaJIT/Lua 5.1 are not going anywhere. Development is done. NeoVIM has made LuaJIT it's default scripting language and has a pretty great FAQ[0] on the topic. [0]https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-inst...
- chubot 5y ago
  I could internalise enough bash warts to write and maintain them, but I can’t expect to burden my team mates with crap that’s far more painful than it should be to maintain. Yup, this reminds me of how the Oil project started. I was getting a lot of work done in shell -- invoking tools I wrote in other languages. And sometimes my coworkers were interested in that, although sometimes they avoided it. But either way, I couldn't really recommend shell to them "with a straight face". It's just too weird and unfamiliar. These are largely Python, C++, and occasionally R users. I saw people write "shell scripts" in C++ simply because that's the language they knew. So basically Oil is evolving shell into a language that will be more familiar to Python and JavaScript users (and yes even C++ or Rust users), which is the tagline on the home page.

by chubot 5y ago

EdwardDiego 5y ago

That's a great niche to focus on actually - there's a looot of Bash in a lot of systems.

jwdunne 5y ago

> I think the "killer use case" will probably be to have a better language for continuous builds and "cloud automation", which on current platforms like Github, Gitlab, and sourcehut use a lot of YAML and shell. I feel the pain of this. In fact, it often goes like this: 1. Start in Yaml since things are simple enough 2. Use a multi-line Yaml string when things get worse 3. Extract to a shell script when things get even worse than that Except things are still painful after step 3: I’m now writing bash. Shellcheck helps but still hit gotchas. Other team members avoid it completely. The problem with “just use Python” is that it’s not as straight forward as doing that. We have to set up venvs and make sure deps in requirements.txt are installed. And we’re not using it on the project we’re building (the languages we are using simply are not as good for scripts). What is needed is a better shell, where we don’t feel as apprehensive about using shell scripts for project automation and those shell scripts are maintainable by everyone on the team. I could internalise enough bash warts to write and maintain them, but I can’t expect to burden my team mates with crap that’s far more painful than it should be to maintain. So yeah, I’m now at a point where: 1. I’ll try a new shell and try for pastures greener 2. I’m sick to death of debugging half-baked Lisp-as-Yaml for automation and if the guys who solve 1 also solve this, I’d owe a debt I could never repay.

JonChesterfield 5y ago
You might like lua as a compromise between shell and python for this stuff. Embed any extra libraries you want in the lua executable and put that one file on $PATH.
- chubot 5y ago
  I'd be interested in a report from someone who tries, but I doubt it will be pleasant. By default, typos in variable names are worse than in Python and worse than shell with set -u: they result in nil rather than an immediate exception. The 1-based indexing is something people complain about when coming from almost any other language (Python, JS, C, C++, Go, Rust, etc.). The key issue with shell is that most people write it without studying the language. I'm also unsure of Lua's stability guarantees. It's an embedded language that can change on every version. I know it has broken compatibility at least 4 times, because they're on Lua 5.x. You're expected to change your programs when you upgrade version of Lua, because it's an embedded language by design. It's very different than a shell. I have heard of people using Lua for "private" shell-like tasks, but I've never seen it in a real codebase, even though Lua is very popular and well documented.
  - 41b696ef1113 5y ago
    >I'm also unsure of Lua's stability guarantees. LuaJIT/Lua 5.1 are not going anywhere. Development is done. NeoVIM has made LuaJIT it's default scripting language and has a pretty great FAQ[0] on the topic. [0]https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-inst...
chubot 5y ago
I could internalise enough bash warts to write and maintain them, but I can’t expect to burden my team mates with crap that’s far more painful than it should be to maintain. Yup, this reminds me of how the Oil project started. I was getting a lot of work done in shell -- invoking tools I wrote in other languages. And sometimes my coworkers were interested in that, although sometimes they avoided it. But either way, I couldn't really recommend shell to them "with a straight face". It's just too weird and unfamiliar. These are largely Python, C++, and occasionally R users. I saw people write "shell scripts" in C++ simply because that's the language they knew. So basically Oil is evolving shell into a language that will be more familiar to Python and JavaScript users (and yes even C++ or Rust users), which is the tagline on the home page.