Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.

If you can do it with .NET Micro Framework, Java (Atego, MicroEJ, J9, ...) and Oberon (Astrobe), surely Go is also welcomed.

It's not that you can't use Go. It's that Go's probably not the best tool for the job.

Sure you can do embedded development with the .NET micro framework because there are embedded systems that don't have hard real time requirements.

If you're building a hobby robot with netduino, you might not care if you have guarantees about input response time--as long as the delays are usually small enough. But if you move beyond that, you're most likely going to need a real time system.

Do you consider missile guidance systems hard real time requirements?

http://www.atego.com/products/atego-perc-pico/

As a language I am not a fan of Go, but on the context of using strong type languages in embedded scenarios. I think the less C the better.

Just like JavaScript JITs, it is always a matter how much companies are willing to invest to improve the quality of the existing eco-systems.

That's a virtual machine specifically designed for this kind of thing.

So sure, if you want to use go syntax and build a completely new runtime designed for use in real time systems then go ahead.

As for strong typing in embedded scenarios Ada's been doing that for decades.

This particular link has some info about that situation. GC pauses are deterministic starting Go1.5. Application code will run for at least 40ms out of every 50ms. The upper limit for the GC pause is 10ms and its typically lower.

It's not "deterministic". It has limits on time consumption of GC defined. But you still can't tell when, and if, at any given moment you'll have a pause.

As soon as you put limits like that you have to compensate by risking that you run out of memory -- if you can't meet the deadline, you can't fully scan the heap[1], free, and so on. Or is that wrong?

That seems like another variable to consider if you're in an environment where you have to somewhat control how much memory you use. But I don't know really know anything about the details of garbage collection, I just figured that that would be one of the trade-offs. So correct me if I'm wrong.

[1] Or whatever technique is used

If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.

No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea.

Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question.

Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?

Can you elaborate on the different meanings of 'systems programming'? I just thought it meant OS development.

Apparently the creators meant infrastructure like web servers, and database servers.

There is some argument that using systems programming the way it is used today is a relatively modern convention. Here is a hacker news thread where this is discussed a bit

https://news.ycombinator.com/item?id=7009563

The "systems" in "systems programming" can also be interpreted to refer to Google's systems. After all, Go was designed to solve Google problems in a Google environment. That's how I always understood it.

In CS speak that is actually known as "distributed systems", not "systems programming".

In modern CS speak yes, but the creators of Go were apparently referring to infrastructure types of programs; web servers, database servers etc...

Here's a quote from the announcement talk

"And it's a systems language in the sense that we intend it to be used to write things like web servers"

If it has servers in the name it is distributed computing.

How modern is modern CS?

I took my CS degree around 20 years ago with focus on computer architecture, compiler design and distributed systems.

Distributed systems literature used in the degree went back to the early UNIX days.

>How modern is modern CS?

The creators of Go were on the team that built UNIX, and they clearly have a different meaning for the word systems.

They were using it to refer to infrastructure, without making a distinction whether it was distributed or local. Something like a compiler would be "systems" program under this definition.

I agree that distributed systems, and systems programming are generally accepted terms of the art in CS now, and even 20 years ago.

Ah, than makes sense.