[julio83]

And IoT companies will have to put trust in another language. We deployed hundreds of ARM5 gateways accross Africa with a golang stack. This kind of decision is not compliant with serious IoT HW providers. Software is easy to upgrade, hardware not. Now we have to bet on another language... welcome rust?

[geodel]

Of course you should try Rust. However I do not think Rust would have anything better on this issue. Here is Rust supported platforms[1]. ARM5 seems 3rd tier platform. It might work if one does the builder work. What people are asking is official support from Go team which Rust does not provide either.

1. https://forge.rust-lang.org/platform-support.html

[steveklabnik]

To be clear about how the tiers work, we would like to provide better support for any platform, but that requires expertise and build machines. If anyone has an interest in getting a platform to have better support in Rust, please give us a shout, we'd love to talk.

[geodel]

Exactly right. I was just pointing out that piling on Go on this issue does not seem right when discussion on this issue mentions lack of reliable builder machines is big problem to maintain official ARM5 support.

[omginternets]

Why can't you stick with Go 1.7?

[julio83]

Stick with Go 1.7 means no security update. This give an open highway for hackers to perform large ddos attack etc. Go is amazing. In few lines you have an SSL/HTTP server ready for production. But this is only possible if you are able to deploy security updates.

[dx034]

In the past they backported imported security fixes (e.g. a fix in 1.7.4 was also in 1.6.4).

I'd first wait and see if there are security fixes that are not available for 1.7 and affect packages you use. It could very well be that this is not going to be the case for a long while.

[omginternets]

>Stick with Go 1.7 means no security update.

As noted in the above comment, this isn't necessarily the case.

You might consider writing on the golang mailing list, explicitly asking them to backport security fixes to 1.7 in the future. I think this is a reasonable request, and one that is likely to be implemented if it garners even slight interest.

[zzzcpan]

They already dropped support for older freebsd systems and at some point discussed to drop freebsd as a first-class target. Already hard to judge the risks for non amd64-linux systems.

[bradfitz]

The issue was about clarifying what "first-class" meant more than about changing how we treat FreeBSD.

[moosingin3space]

Which language dropped support for older FreeBSD systems? Go supports FreeBSD 8-STABLE and above, Rust has FreeBSD as a second-tier platform.

[voidlogic]

gccgo?

[bostand]

To be fair, you should expect that from any Google project. Remember their popular RSS reader service?

If you think this change is crazy, wait until they reveal the changes they have planned for android later this year.

[wahern]

If you want to maximize your chance for long-term support of niche architectures, GCC is your best bet. One of the reasons GCC has endured is because it has such a huge, dedicated community surrounding it. And it has such a huge, dedicated community because so many hardware vendors directly or indirectly employ engineers to maintain GCC's extensive hardware support.[1] LLVM just doesn't have that community, and arguably it doesn't even have that kind of dedication, as it requires a significant expenditure in time and effort to maintain, and both clang and LLVM are very much fast moving targets.

Have you looked at gccgo?

Your second best bet would be sticking with a language, like C, with a large and mature field of compilers. Or at least a language that compiles to C (OCaml?) or otherwise built atop of C (Lua, which is implemented in 100% ISO standard C, and with a coroutine implementation that goroutines were intentionally or coincidentally patterned after).

[1] Which isn't to say that GCC doesn't deprecate architectures. But even NetBSD and OpenBSD, which have or are importing LLVM, are keeping GCC around for the architectures unsupported by LLVM. And GCC is happy to revive deprecated architectures when maintainers show-up.

[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.