One area where fish is excellent is IMO interactive shell scripting. No more case..esac and friends. Fish adopts a python-like syntax that makes it ridiculously easy to write loops fast in the terminal.
So I read this and thought "wow, indentation would be so stupid to manage in a terminal... even typing python into python's repl is brutal" but then I looked up the syntax for a for loop in fish and it is exactly the same as the syntax in bash except it uses the word "end" instead of "done" and doesn't have "do"... what am I missing?
It's an absolute godsend. Scripting in it feels really intuitive compared to POSIX shells. I find it such a shame that we probably won't get rid of POSIX shells for at least a couple more decades... if that.
You can use the swipe functionality of the gboard even with the open source android keyboard provided you are rooted. It's just a library file that you have to install.
I wish we had the option to use web apps instead for native apps for everything. As much as I hate modern web, I can't deny that not only are web apps cross platform, they also offer better privacy.
I've thrown away half a day trying to figure out how to get the scroll wheel to behave. No cigar. It still scrolls one line at a time in a terminal, and two pages at a time in firefox.
I agree with you. I mostly just read the title and then the comments, especially if I know a thing or two about the subject.
Partially off topic but I personally use the FOSS android app "Materialistic" to access HN. It offers a much better comment navigation experience than ynewscombinator.
It depends on the workload and app for sure, but in my experience, most of my services make a bunch of outgoing calls, usually HTTP, to different services, often in a single operation. Being able to do these in parallel, on the side, or via fork/join was pretty handy. For a simple Flask app that fronts a single db, sure, stick with wsgi, but I don't run into many apps like that anymore.
What PEP 484 was standardize the use of annotations as type annotations and provide ancillary out-of-the-box support for type hinting via annotations, particularly the typing module.
Mypy was actually using python 3.x annotation for type annotations before PEP 484 standardized them brought the stdlib typing module, but with PEP 484 there was a common, language-defined standard baseline for mypy and other efforts.
Maybe your IDE experience is different than mine, but a typed function will gladly accepted an untyped var without complaining, and during runtime could care less.
Why should type annotation be enforced at run time? In statically typed languages there is no type checking at run time, your type system already proved the type of variable.
> That’s why, for example, they can’t be used to increase the performance of the interpreter.
They can (as in - there's API for that, the rest is up to a community effort) improve performance of a final program, if type-annotated code is passed through Cython with ``annotation_typing=True`` flag:
The annotations are a language syntax feature than the runtime doesn't enforce. There are a number of separate static typecheckers, such as mypy, that do allow AOT static verification (which is, after all, all languages like Haskell have; runtime enforcement of types that have been statically verified in advance isn't super common or necessary.)
