News for hackers. Stuff that matters.

A comment on The State of Go. Parent comment

Re:The State of Go by mcgirr on Wednesday May 27, 2015 @02:11AM (#9609593)
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.
[ Parent | on HN ]
Re:The State of Go by pjmlp on Wednesday May 27, 2015 @03:35AM (#9609895)
If you can do it with .NET Micro Framework, Java (Atego, MicroEJ, J9, ...) and Oberon (Astrobe), surely Go is also welcomed.
[ Parent | on HN ]
Re:The State of Go by learc83 on Wednesday May 27, 2015 @01:15PM (#9612839)
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.

[ Parent | on HN ]
Re:The State of Go by pjmlp on Wednesday May 27, 2015 @03:03PM (#9613586)
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.

[ Parent | on HN ]
Re:The State of Go by learc83 on Wednesday May 27, 2015 @03:58PM (#9613917)
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.

[ Parent | on HN ]
Re:The State of Go by nindalf on Wednesday May 27, 2015 @05:50AM (#9610290)
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.
[ Parent | on HN ]
Re:The State of Go by mkpankov on Wednesday May 27, 2015 @07:38AM (#9610635)
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.
[ Parent | on HN ]
Re:The State of Go by Dewie3 on Wednesday May 27, 2015 @08:57AM (#9610990)
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

[ Parent | on HN ]
Re:The State of Go by tracker1 on Wednesday May 27, 2015 @02:56AM (#9609748)
If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.
[ Parent | on HN ]
Re:The State of Go by learc83 on Wednesday May 27, 2015 @01:22PM (#9612889)
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?

[ Parent | on HN ]