Way to Go (or not to) on embedded systems

Posted in Technicalon Aug 2, 2012

Over the last few years, Google has been working on their own pet programming language, called Go.  It is a high level language that is compiled to native binary code.  I took a quick look at Go to determine whether or not it would be good on an embedded system.

Advantages

It is very easy to build a cgo compiler that will cross compile to ARM.  If you are using ARM or x86 for your embedded system, you can have a program compiled and running on your system in just a few minutes.  If you are using another architecture, you may be out of readily available support, but not out of luck–the gccgo compiler may provide just what you need.

Go links everything statically.  This means that you never have to worry about getting all the run-time dynamically linked libraries at just the right version on your embedded system.

Go is a nice high-level language that doesn’t require an interpreter.  Interpreters can be big and slow, which isn’t ideal for an embedded system.

Disadvantages

Go binaries are big.  This is because everything is always statically linked.  Go binaries also contain a certain amount of run-time overhead like garbage collection.

Go was developed first for x86.  Support for other architectures have come after support for x86, so running Go on an ARM isn’t as well tested as running Go on an x86.

Go is new.  You don’t get years and years of experience with Go as you would with other languages like C++.  Additionally, you are less likely to find highly-experience Go programmers as you would with other more common langauges.

Conclusion

Because Go binaries are big, it makes it impractical to use Go on an embedded system except for in a few cases.  If you have lots and lots of storage on your embedded system, Go becomes more practical. If you are using Go to write a single monolithic program for your embedded system, the binary size overhead may be less of an issue.  If you want to write lots of small applications (which use dynamically linked libraries) than Go is not for you.

Because Go is new, it may not have seen as much testing as might be needed for critical embedded systems.  But if you need to quickly get a prototype working, Go might speed up development.  I would imagine that a large company might want to stay away from Go for now, but small startups who like to take risks might justify using Go to capture the big development rewards.

Comment Form

Categories