nilaway VS usbarmory

I would have more respect if they at least admitted to the flawed type system but instead say it is not a problem. It is disappointing to see past mistakes repeated in a new programming language. Even the Java language creator was humble enough to admit fault for the null pointer problem. The Go devs do not have such humility.

https://github.com/uber-go/nilaway

We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues

We definitely have gotten some useful reports there already since the blog post!

We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).

Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contacts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.

Niklaus Wirth, rest his soul, would disagree.

Like would the the selling USB Armory, with Go written firmware.

https://www.withsecure.com/en/solutions/innovative-security-...

Back in my day, writing compilers and OS services were also systems programming.

Not only you can fit Go into a kernel, there is at least two products that do so.

TamaGo, used to write the firmware used in USB armory.

https://www.withsecure.com/en/solutions/innovative-security-...

TinyGo, which even has official Arduino and ARM support, and is sponsored by Google

https://tinygo.org/

Ah but that isn't proper Go! Well neither is the C code that is allowed to be used in typical kernel code, almost nothing from ISO C standard library is available, and usually plenty of compiler specific language extensions are used instead.

> Since 80s everybody designs systems on top of C.

More like since the 1990's, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft.

There is firmware in production written in Go,

https://www.withsecure.com/en/solutions/innovative-security-...

Not exactly but close. No gocoin, but custom (minimal) client based on btcsuite libs. And it is run on USB Armory SoC.

Relocking with your own key is only for experts, it's similar to the USB Armory device for embedded electronics. If you get it wrong you can brick the device, the purpose of doing it is to protect against certain types of boot attacks (like if somebody can get temporary physical access to your phone or even just plant a malicious USB cable which could potentially push malware. If you don't know what you're doing, stay on stock OS.

Plenty of software that is written in C and C++, can be easily done in Go as well, in fact in any AOT compiled managed language.

C++ was born to write distributed systems, nowadays it hardly matters on cloud native infrastructure beyond the OS and hypervisors layer.

This is how Go can be a competitor to C and C++, just like Inferno was basically Plan 9 with Limbo for userspace and very little C beyond the kernel.

And then there are those crazy folks that believe they should ship bare metal AOT compiled languages regardless of others think.

https://www.withsecure.com/en/solutions/innovative-security-...

Of course it can, there are companies shipping products written in bare metal Go.

https://www.withsecure.com/en/solutions/innovative-security-...

https://github.com/usbarmory/tamago