Comment by noobiemcfoob
6 years ago
It's better to assume all code could throw an error. No statement is safe. This becomes particularly important in distributed computing as resources may be offline at any given moment. It's from this perspective that type systems afford a false sense of security and appear to be scratching the itches of overactive Type As.
I'm not particularly an advocate for typed languages (my daily driver for personal projects is Common Lisp, which is mostly untyped), but I'm having trouble even understanding the point of view that "No statement is safe". If I had a system where the actual type of the expression "1+2" were "3 | Error" I would find a new system.
Code that doesn't read from unsafe memory locations, allocate memory, or perform I/O cannot throw an error. Code that does can throw an error. Some systems treat out-of-memory as fatal, removing one of those 3.
In some domains you don't want to know if the computation is happening locally or remotely, but IMO most of the time you do because pure computation cannot signal an error locally, but remotely it can. As you mention, distributed computing often runs in this mode, but distributed computing is an overkill for most problems; my phone is powerful enough to locally compute most daily tasks (even when it's done server-side for various reasons); my workstation is powerful enough to perform most daily tasks for 100s of people simultaneously.
It's hyperbole. A lot like systems that require hard type declarations for each and every function. The advantage of type systems is performance. Any correctness guarantees that come along with it are nice sugar but hardly the point and often misleading.
Nonsense. A distributed scenario is precisely where an advanced type system becomes really valuable, because you can draw a distinction between local and remote calls while still treating both in a uniform way. Treating every single call as though it were remote is impractical and wasteful.