Dockerd relies on kernel features like cgroups and namespaces so I doubt the docker daemon can run inside WSL. There is a docker daemon for windows that I believes uses hyperv as container runtime. You could probably run docker cli inside wsl if you could expose the socket on the host to it (guessing)
Docker on windows seems to be a little bit complex.
There's Docker for windows which allows for linux docker containers to be run on windows, using Hyper-V.
Then there's Windows Container Services which allows for Windows Docker containers. Those can either be run on the host kernel or they can be isolated in a Hyper-V layer.
The other trade-off that comes from mutable versus immutable data comes from clustering. With Go, you have the ability to make remote procedure calls very seamlessly if you want to implement them, but because of pointers and shared memory, if you call a method on another box with an argument that references to something on your machine, it can’t be expected to function the same way.
I would be happy to know how we can make RPC seamless in GO accross multiple machines (clustering). I've missed a nice lib?
I might need to rework that sentence. I was trying to say that clustering can only be seamless with immutable data and that, while Go has great RPC support built in that it won't ever be able to cluster naturally.
We are replacing all our python backend by golang and indeed static typing is a good way to well structure your data.
Regarding reliability, I would prefer elixir for 3 raisons:
#1 Functional programming. In go it's really easy to make error by sharing object reference in channel. And what is funny is that it's not so easy to make a deep copy of an object.
#2 Goroutine leak and supervision is really difficult to follow. How do you manage it in production ? Thanks to erlang, elixir provides all you need to monitor your green threads. You can even hot fix issues.
#3 Beam preemption is clearly a strong winning point.
Bonus point, go scalability is limited to your server. In elixir you can remove server boundaries.
For a new product, I will definitly bet on elixir.
The thing is, it's in Toulouse (a major French city). That might be the only good place[1] in a 100 miles radius.
I find it incredibly risky to play all hopes on a single company with zero backup plan. (I've worked in France, I've seen how bad it gets when you loose your job).
[1] I have higher standards than the average Frenchie, just like anyone who's worked at top web and financial companies.
Well, getting lost in translation is something normal, isn't it? I have been 1 year in Germany and I tried to learn German. If you don't want to learn a new culture/language it's going to be difficult for sure. Why a whole country should adapt to you?
Some english speaking guys don't want to make effort to adapt and I really think that they miss the most important & fun part of travelling/living abroad.
You can raise money in english in France. No issue on that.
We have nice startup here and nice developpers. But you can also find nice thinghs in other EU countries. Business is everywhere...
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?
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 :)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
