This mirrors my experience. C is a drug man. It's bad but you can't stop. You know how to get shit done in C and it's easy to think in. C is, IMO, something of a local optima for programming. Problem is, it's actually a relatively awful language, and I don't subscribe to the worse-is-better philosophy (though C may well be the best example of it).

Thankfully Rust gets my ML instincts going. I'm trying to use it more. It'll be nice not to be anxiously running my test suite under ASAN after every build.

I am surprised you never found managing those risks as stimulating. I do. 'C' is pretty good at providing the furniture needed to enforce formal constraints.

Yeah but after sixty years of C, why should we trust an origanization like Mozilla? They've been thoroughly unwilling to come up with any sort of ANSI standard or anything, despite Rust being a reasonably mature language.

Google sought ECMA standardization when they took on Dart. Go language has an official specification, so someone could hypothetically re-implement it if they wanted to, and remain compatible Go projects.

Mozilla only wants Mozilla to be involved with Rust. They want everybody to use it in their systems, and have no input on where the language should go.

This comment is beyond uninformed. Rust is currently working towards standardization, starting with the memory model. See http://smallcultfollowing.com/babysteps/blog/2016/05/23/unsa... . This work is being undertaken by Niko Matsakis (a Mozilla employee, so yes, Mozilla cares about standardization) and Nicole Mazzuca (an independent volunteer, so yes, Rust takes broad input from the community).

As for "they want everybody to use it in their systems, and have no input on where the language should go", you appear to be utterly clueless about how Rust is developed. Enormous swaths of the language have been designed by contributors who just showed up out of the blue and started putting in elbow grease. Iterators. Every data structure in the stdlib. Crucial, fundamental details of how the borrow checker operates. There's an entire repository for allowing anyone to propose changes to the language (a process which Mozilla employees are also forced to follow), which is a model that several other open source projects have since adopted (e.g. Swift).

Huh? Anyone can submit an RFC: https://github.com/rust-lang/rfcs

While Mozilla may not be the best organization, the Rust team seems much more willing to listen to their users than the Firefox team.

Really? The Rust community has been one of the most open and encouraging ones I've seen. They've also taken great pains to make sure that community feedback is solicited and incorporated.

From the little research I have done into Rust it seems unsurprising that there isn't a formal definition as any Rust standard would be similar in value to Haskell 2010. Useful but not sufficient due to the language still evolving.

All of the things which the C-like replacements for C are competely missing the point. All their goals can be achieved by using a decent high level language (not "C like"), together with using C for just those parts that have to run fast, or interact with the hardware.

"Let's make an improved C, and then write millions of codes in nothing but that" is a myopic non-starter.

How does this apply towards library creation, where the code is meant to be consumed by other programs languages?

While the total lines of code in libraries is less than that in applications, I would say the relative importance is more. That zlib has a fast and correct implementation matters to a lot of people.

That's right; one fast and correct zlib matters more than giving everyone an improved C so that they can all try to roll their own zlib that is fast and correct.

My comment was mean to point out that even if we magically achieved your dream tomorrow, and almost all applications were written in some HLL (which is probably a good thing), the amount of machine code being run in those applications that was generated from C is still substantial due to library use. If we accept that C is "bad", or at least that some major gains in usability, reasoning and security can be made by changing or replacing it, then there's still a major benefit to doing so.

When a bug comes out in zlib (or more likely, OpenSSL again), and we can attribute it to poor engineering in C, it doesn't really matter that all the applications are written in a HLL if they still loaded the library and used it because the performance was needed.