[scottlamb]

Long-term support is just one aspect of the language decision, though. Security should be another big one for IoT vendors. I'm pleasantly surprised to hear an IoT vendor is using a more secure language than C. I'd be sad if lack of Go or LLVM support caused them to revert to C and likely (re)introduce buffer overflows.

[wahern]

Considering the recent bug discovered in Go's runtime, we can say definitively (not merely "likely") that moving away from Go 1.7 would resolve at least one invalid memory write bug.

The most complex protocol typically often seen on IoT devices is HTTP. It's trivial to implement HTTP in C without any buffer overflows--use a parser generator. It's even easier with IoT because you don't need to support serializing and deserializing arbitrary headers, but rather only a narrow a set. (You can discard unknown headers rather than reify'ing them as objects just so they can be ignored.) And this is how I'd implement HTTP in Rust, too--using a parser generator--just because it's an all-around cleaner approach in such a context.

Go and Rust are really cool languages and I hope they continue to see increased usage. But neither will ever be a serious contender to replace C as core infrastructure software unless and until there are multiple implementations with guaranteed interoperability. Diversity of implementations and diversity of tooling matter. They're some of the reasons Java has done so well--not because of the JVM, of which there are more versions than you can shake a stick at.

Or perhaps, conversely, that kind of diversity signals real uptake. In any event, without that diversity I wouldn't adopt any language across the board, but only for very specific applications like for particular daemons. For now only C and, to some extent, C++, have that kind of diversity. Java has come the closest, but everything else is beyond comparison.

[scottlamb]

> Considering the recent bug discovered in Go's runtime, we can say definitively (not merely "likely") that moving away from Go 1.7 would resolve at least one invalid memory write bug.

If you're making the point that using Go or Rust doesn't make you completely immune to security problems, I agree. But on balance, I think it makes you significantly better off.

As for this specific bug, I expect the fix to be backported to Go 1.7 if it hasn't been already, and ideally these devices would receive updates occasionally...although I know that isn't actually happening for many deployed devices...

(btw, I'd say "likely" rather than "definitively". That looks like a bad bug, but I can imagine a reasonable system that it doesn't apply to. They might not have a goroutine whose stack ever grows ever select simultaneously on the same channel as another goroutine, for example.)

> The most complex protocol typically often seen on IoT devices is HTTP. It's trivial to implement HTTP in C without any buffer overflows

You might be able to write a buffer overflow-free HTTP implementation, but "trivial" is a funny word. Would you still call it trivial if I pointed you at a list of buffer overflow bugs in C HTTP implementations? Does your calling it trivial fix all the buggy devices? If not, what relevance does your calling it trivial have to the security properties of widely deployed implementations?

These devices implement a variety of other protocols. I own some security cameras that implement at least: DNS, DHCP, UPnP, SNTP, RSTP, RTP, SNMP, SOAP, ONVIF, SMTP, SMB, SSH, a few custom protocols based on HTTP or directly on TCP. Some other likely protocols for IOT devices include SIP, IPP, and OAuth. And those are just off the top of my head. Maybe you consider each simpler than HTTP (and I'm uninterested in debating the ranking of protocol complexity), but collectively they represent a large increase in attack surface, and I'd be shocked if any of the protocols on that list didn't have widespread implementations with buffer overflows bugs.

I hear your point about the lack of implementation diversity being a significant risk to using these languages, but I think you're underestimating the scope of the security problem.