The main issue with the android app for me is how slow it is. Everything seems to take anywhere between 500ms to 2 seconds. The worst is the play button, which is arguably the most important feature in the entire app. I've tried using the iOS app on my gf's iPhone and it's blazingly fast. The android app feels like it's an order of magnitude slower.
I use `less` with help output because if the help output is long, it starts me at the top of the help output rather than the bottom, and the top usually has a nice summary of the command usage that I usually want to read.
More importantly, I can easily find things by searching with less's `/` hotkey. Relying on the terminal emulator's built-in search isn't great because (a) I'm not used to it - I am more used to vim's keybindings, and the search hotkey `/` is the same in vim, and (b) that's also going to search all the output from before I ran --help (not as big of a gripe, but still somewhat annoying).
I guess the broader point they're driving at is that attempting to port familiar programming constructs to YAML DSLs will result in this kind of ugliness. If that's true though, it's a bit too subtle for my tastes.
I agree that -o pipefail is not great since it's totally fine for pipes to break in some cases (e.g. I've occasionally seen it cause problems with pipelines like `grep | head`).
Hard disagree about -e though. I get it's not perfect but it has probably saved me dozens of hours of frustration and heartbreak. If you forget to handle errors for a particular line, then the script will just keep going and that's how you accidentally delete your entire home directory. Sure you can rely on shellcheck but for me personally I don't have shellcheck available 100% of the time as I often find myself writing scripts as raw strings (e.g. ssh -c).
Huh? It's called observable because it can be observed (that's what "-able" means). If it were actually meant to observe something (as you say), it would have been named "observer." But it's not - it's the callback that's the observer.
Also observables are more like streams than arrays.
As a side note, using a future as a map key struck be as a bit weird, though perfectly valid. It'd be more natural IMO to use a list for the futures, and have the fetch_url function return a (url, result) tuple. Or use the url as the map key and just iterate over the map items instead of using as_completed on the keys
I agree with you. We can complain about Bash all we want, but Bash is everywhere and isn't going anywhere anytime soon (as much as I'd like something better). So if you want to be a good engineer in today's world, you have to learn it. And if the error message isn't immediately obvious to you yet, don't worry, it just means you haven't yet formed the right mental models. But you will, if you continue to educate yourself by reading articles like these!