That is some really good perspective. The incorrect C program is a bit of an externality that's felt by QA/testing/customers/etc.
I liken programming w/Rust to programming with C or C++ with warnings and a static analyzer barring object files from being created. If I were new to C/C++, I would probably find it baffling how anyone ever gets it to work.
Actually, it's the very process of “fighting the compiler” (as you call it, though I prefer to view it as collaboration between a human who knows what he wants and a program whose logic codifies what is possible) that makes it easier to write correct programs in Rust/Haskell/ML/$FAVORITE_TYPEFUL_LANGUAGE.
I think there's a time before you learn how to make that collaboration productive, for a given tool, which is more aptly termed "fighting" and which you should certainly be able to get past. After that, you can have disagreements but they are far more productive.
This seems an unwarranted dig against a poorly specified group of people.
The notion that a type system is "just" logic and so should be trivially followed by anyone "smart enough" or "careful enough" is laughable - there are many different type systems (sometimes with different details depending on the options or pragmas you feed to your tooling), and it can take time to get a sense of where the boundaries are.
The notion that you're not likely to find a type system helpful if you have trouble with it initially is harmful.
I would've never said "just". Formal logic is big f...reaking deal.
> so should be trivially followed by anyone "smart enough" or "careful enough" is laughable
I never said anything about being "smart" or "careful". I only said that hacker types, for whom the ability to subvert anything anytime is a fundamental tenet, tend to have a hard time sticking to the rules of a formal game, whether it is a type system or not. Just look at the reasons Lispers give for liking Lisp.
> I would've never said "just". Formal logic is big f...reaking deal.
"Just" was in no way meant to diminish significance; it was meant to draw attention to your improper limiting of scope. Someone "fighting the compiler" is not fighting "executable embodiments of formal logic", but "executable embodiments of formal logic and a pile of engineering decisions". Often, enough of those decisions are made well that the tool can be phenomenally useful; some are made less well, and some simply involve tradeoffs. It doesn't have the... inevitability that your wording carried. Programmers coming from a context where enough of those decisions have been made differently are likely to get tripped up for a while in the transition, without harboring any objections to logic.
> I never said anything about being "smart" or "careful". I only said that hacker types, for whom the ability to subvert anything anytime is a fundamental tenet, tend to have a hard time sticking to the rules of a formal game, whether it is a type system or not.
True, but you left it up to us to figure out what attributes of "hacker types" were relevant. As there are many different uses of the word "hacker", it was quite unclear that you meant to refer specifically to inability to stick to rules.
While people of that description may well persist in "fighting the compiler" for longer, that is not most of what I've observed when I've observed people struggling with a type system, and I reiterate my assertion that those new to a particular tool and used to doing things another way also frequently struggle for a period.
While I agree with your sentiment, I think this is not true in general. The Rust compiler sometimes rejects correct programs, in which case it can be harder to write it in Rust than in C.
In the absolute worst case, you can pretty much transcribe your C program into unsafe Rust, though you will be fighting the syntax, which was deliberately made cumbersome to discourage programmers from writing unsafe code.
In practice, I have never seen any programs where this is the best approach. Coming up with designs that don't need unsafe code is very useful, because the safe subset of Rust is vastly easier to analyze and understand, both for humans and computers.
Sometimes C compilers can't even agree on what counts as "correct"! With Rust, you can at least be reasonably sure that if your program compiles with your version of the compiler, it will continue to do so with all later versions, because they're coming from the same codebase and made by people who care about backward compatibility.
> Sometimes C compilers can't even agree on what counts as "correct"!
This comes primarily from the fact the C standard itself is hard to interpret right. Standard ML has less issues in this department: since the Definition is clearer and less ambiguous, implementations disagree less on what counts as correct code and what its meaning is. So having only one major language implementation isn't the only way to prevent compatibility issues.
C is a much simpler language thats all. I understand its easier to write safe program in Rust. But to just pick up a language and go, C is easier in my mind.
It's probably easier to write CS101 prime-number or fibonacci programs in C.
Any nontrivial bit of software? You're going to have to learn about undefined behavior and deal with it. Rust forces you to learn this before getting started.
Plus Rust has a lot of higher-level (still zero cost) abstractions like Python which make a lot of patterns really easy to program. (And Python is _the_ teaching language these days)
If you mean it's easier to write correct programs in C than correct programs in Rust, I'm afraid you're badly mistaken.