> Embedded is still at its early development stages, just like WASM and just like asynchronous network programming. Still, all those are on the front page.

That is more an indictment of WASM and asynchronous network programming than a vote of confidence for embedded...

And I avoided commenting about things other than embedded explicitly because I don't have any background to judge those.

> It's that it's uninformed, generalizing and unfair.

You claim this statement is the problem:

"the idea of putting "Embedded" on the front page and trying to advertise Rust as a useful embedded language isn't just laughable--it's dangerous. Rust is so far from useful in embedded that people who try to use it will NEVER come back"

and then follow it with:
"But in just a few weeks, you'll be able to use Embedded on stable"
"It's not production ready yet, but I'd estimate it will be within 2 years."

Ummmmmm ... I think you just made my case for me.

I pull a bunch of the embedded Rust stuff about every 4-6 months and build a "blinky". I have an intern try this about every 9 months--I have yet to have an intern make any meaningful progress without me holding their hand every step of the way. Those same interns pull down Keil and fire off a blinky in about 4-6 hours without my help. Boards with their own environments like Silicon Labs or NXP are generally faster--about 2-3 hours to blinky--but are more annoying when you have to do something outside the "flow".

I'd argue that experience makes me quite specific and informed and my comments quite fair. Thanks.

If you point an embedded engineer at the Rust embedded ecosystem to evaluate, he will hand you your head on a platter. Embedded is NOT ready and putting it on the front page is going to get you a reputation for half-assed-ness.

The problem is that Rust is moving "slow and steady" in an era where everyone wants "growth hacking". Or, if I'm feeling particularly nasty and snarky, Rust "thought leaders" outside Mozilla are annoyed that Rust isn't providing the revenue opportunities for speaking and consulting that languages like Go and Swift do (like Rails used to).

Rust honestly doesn't have a marketing problem. Most of the people I know who might benefit from Rust are tracking it--even up to VP of Engineering levels (oddly, Rust appears to be better regarded than you would expect)--however these people are doing hard-headed cost analyses and don't find Rust to be coming out on the winning side most of the time. The issue is simply that most of the current languages are entrenched for various reasons and moving them aside requires that you be demonstrably better--and that implies i's dotted and t's crossed.

See Theo de Raadt about Rust in OpenBSD:
https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

What Rust really has is a completeness problem. The lack of completeness in Rust reminds me of Lisp quite a lot--lots of libraries at 70%, very little at 99%+. Every time I try to use Rust for a project, some library isn't up to scratch or requires some odd combination that demands nightly, has some weird showstopper bug that will be fixed "Real Soon Now(tm)" that has been extant for 24 months, etc. Fortunately, Mozilla needs Rust to be up to scratch for Firefox, so at least certain core things get driven to completeness.

I can contrast Rust at 8 years old (and I'm being generous) to Python at 8 years old (sigh, I'm now a greybeard ... "Back in my day, sonny..." <shakes cane>) Rust isn't convincing me to throw any of my languages away in spite of the fact that I really hate C. Python at 8 years old was good enough for me to throw Perl 5 away at roughly the zenith of Perl 5's popularity--now that's completeness.

I like Rust, but people need to get comfortable with the fact that Rust has a long, slow, unsexy road ahead of it.