I agree with parts of that post, and most of the feature requests are things we want, but as woboats said, there were items on the roadmap that address these issues. Web servers were never the only or the primary goal of the roadmap. They were the only application domain with a vision statement, which I believe is because that's the only domain we knew already had strong user interest and that we thought we could feasibly become competitive in within a year (imo that seems overly ambitious now, but it does seem like we could have async/await in 2018 and then become a very attractive choice).
Feature parity with C is not something we could feasibly do in a year. I do believe we should add all the useful features of C into Rust in some form or another, but I also think a huge part of Rust's appeal is that it's not simply copy-pasting features from other languages, but trying very hard to get the useful functionality with minimal compromises to all of its other design goals. Properly discussing every C feature that Rust is currently missing, deciding whether we want it at all, and whether we can learn anything from C and do it even better, is simply going to take a very long time.
But a lot of those conversations did happen this year! And a lot of features not necessarily on the roadmap but relevant to the list in that rant also made design or implementation progress. Proposals to stabilise SIMD intrinsics were thoroughly discussed and seem near consensus. Const generics has had a viable RFC posted, which would unblock a lot of those "number crunching" applications. CTFE (compile time function evaluation) is getting close as Miri is on the verge of being merged into the compiler. More platforms are supported now than they were at the beginning of the year. Parts of macros 2.0 are already in the nightly compiler.
I assume that user has the perception they do because almost nothing from that last paragraph has made it into a stable compiler yet. I strongly believe we have gotten closer to shipping each of those things, and some might ship by the end of the year, but they haven't yet. There are a lot of reasons for this, but imo they boil down to 1) designing programming languages is really hard, especially one with as many diverse and superficially contradictory goals as Rust. 2) Rust is still a very young language. It's actually mind-blowing how useful it is already, considering how many decades most of the competing languages have had to develop since their 1.0s. 3) I think there's currently a bit of a log jam design-wise where many, many things are blocked on "core megafeatures" like specialisation, const generics, CTFE, macros 2.0, etc, though we are getting a lot closer to shipping useful subsets of these megafeatures than we were at the start of 2017.
The part of the post I agree with is that one of our future roadmap goals should be to make embedded development feasible on stable. Not because I think Rust's primary audience should be C veterans (that should be one of many audiences), but because embedded is a domain where we could potentially be far better than the competition, yet some of the critical feature gaps (like inline asm) seem stuck in unstable limbo and probably require a concentrated lang team push to get them moving forward again.
I also think "breaking the log jam" and shipping some of the megafeatures should be a 2018 goal, unless a bunch of them do ship in December.