[julio83]

  Go 1.8 will be the last release to support Linux on ARMv5E and ARMv6 processors: Go 1.9 will likely require the ARMv6K (as found in the Raspberry Pi 1) or later. 

Does this mean that we will not be able to produce ARMv5 binaries or this is only a prerequisite for the compiler?

[grey-area]

There's more detail over on the issue concerned:

https://github.com/golang/go/issues/17082

[rcarmo]

Hmmm. If that's true, then I won't be able to build binaries for my old Synology anymore.

[bostand]

More importantly, the cross platform router worm that was ddos-ing everyone a few months back was written in go and will not be able to upgrade to 1.8 :)

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