3 ms·

> 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,

> 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.

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.