>Incorrect. Have a look at the Swift OpenCombine library. Multiple Publishers of a particular type that emits a single boolean value

First off types can't emmit values. Types don't exist at run time. They're simply meta info for the compiler to run checks. Thus they can't emmit anything. Second if you're talking about something that emmits a value then it involves logic that doesn't have to do with UI. A UI is not about logic, it is simply a presentation given to the user, all logic is handled by things that AREN'T UI based.

UI would be like html and css. Can you type check html and css make sure the hackernews UI is correct? There is no definition of correctness in UI thus it can't be type checked. The example you're talking about is actually type checking the logic UNDERNEATH the UI.

>Effectively, it is not possible to even compile a program that incorrectly ignores multi-threading or incorrectly accesses memory in a race condition with other threads thus possibly corrupting that memory. Moreover, it is also not possible for a thread not to properly release a lock once the MutexGuard type goes out of scope.

This is different. It's not type checking memory corruption. It's preventing certain race conditions by restricting your code such that you can't create a race condition. There's a subtle difference here. You can violate Rusts constraints in C++ yet still have correct code. Type checking memory corruption would involve code that actually HAS a memory corruption, and some checker proving it has a memory violation. My statement still stands Memory corruption cannot be type checked.

Think about it. A memory corruption is an error because we interpret to be an error. Logically it's not an error. The code is doing what you told it to do. You can't check for an error that's interpreted.

At best you can only restrict your code such that ownership lives in a single thread and a single function which prevents certain race conditions. which is what rust does. This has a cost such that implementing doubly linked lists are a hugely over complicated in rust: https://news.ycombinator.com/item?id=16442743. Safety at the cost of highly restricting the expressiveness of the language is very different from type checking. Type checking literally finds type errors in your code, borrow checking does NOT find memory corruption... it prevents certain corruption from happening that's about it.

>Unlikely. Without feeding strong type information that describes your problem domain into a checker, the checker cannot reason about your code and figure out possible errors. A strong type system is a "language" for a programmer to communicate with his or her checker.

No no, you're literally ignorant about this. There's a whole industry out there of automated proof checking of code via type theory and type systems and there's technology that enables this. It's just not mainstream. It's more obscure then haskell but it's very real.

It's only unlikely to you because you're completely ignorant about type theory. You're unaware of how "complex" that "language" can get. Dependent types is one example of how that "type language" can actually "type check" your entire program to be not just type correct but logically correct. Lean, Idris, Coq, Agda, literally are technologies that enable proof checking at the type level. It's not unlikely at all. it's reality.

>Please do not hold it against me if I do not continue commenting here - you must be from a different, parallel Universe. (How is Elvis doin' on your end? ;) J/K)

Wow. This is just fucking rude. I'm sorry but you're ignorant and you're about to have a rude awakening about just how ignorant you are. Take a look at this: https://www.ben-sherman.net/posts/2014-09-20-quicksort-in-id...

It's quick sort implemented in a language called idris. The implementation is long because not only is it just quick sort, the programmer is utilizing the type system to PROVE that quick sort actually does what it's suppose to do (sort ordinal values).

I'd appreciate an apology if you had any gall. But you likely won't "continue commenting here". Wow just wow. I am holding it against you 100%. I didn't realize how stupid and rude people can actually be.