There is a lot of community interest in Rust with regards to running on embedded devices, so I wouldn't be so quick to point to IOT devices as a reason for not using Rust. That said, I don't know what the current state of support for these less popular architectures is. The official page for platform support is https://forge.rust-lang.org/platform-support.html.

LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: http://lists.llvm.org/pipermail/llvm-dev/2016-November/10717...

That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

Yeah it should. AIUI Rust uses a fork of LLVM, but they should be regularly pulling in upstream changes (but I don't know how often this happens) as well as submitting their own changes back upstream.

We do, in both directions.

Is there a technical or political issue preventing Rust from using upstream LLVM? Either way, is there a possible resolution on the horizon?

Nope. You can use a stock LLVM if you want. Some tests might fail, since patches might not be in upstream yet.

It's not really something to resolve; it's just the usual situation with a big dependency.

I expect that most of these older devices don't receive much in the way of software updates anyway, so the point is moot. For things that do receive updates, I would much rather see a secure NTP implementation that the majority of the world can use, even if a few parts of the long tail get excluded... and they still have the old versions of the C-based NTPsec they can use; I would also expect there to be a niche market arising for releasing security updates to it after the transition.

(Specifically addressing IoT devices, IoT security is so abysmal in general that there are much easier ways to compromise one than targeting its NTP daemon, if it's even running one, and if it's even "bothering" to run a secure one like NTPsec.)

Dropping support for things is certainly not a decision you make lightly, but sometimes the greater good demands it.

If it's a business requirement, they should hire engineers and contribute. Expecting free support seems unreasonable. There's a high cost for supporting and maintaining features, so somebody ends up having to pay for it.

To be fair, I imagine most of those arch manufacturers simply think "embedded developers use C, we support C, job done."

LLVM support would benefit the developers more, but they have their own budgets and constraints, which are probably not conducive to submitting and maintaining a LLVM plugin.

We are getting some piece of it with companies that still sell safe system programming languages (e.g. MikroElektronika, Astrobe), expose mostly via Java or its variants (e.g. Oracle, Aicas, Aonix, IBM, IS2T, Google), .NET (Microsoft).