usbarmory VS zig

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

There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284

https://github.com/ziglang/zig/issues/224

e.g.:

> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g.

When writing code in a scripting language, sometimes you need that extra bit of performance (or maybe an async feature from Zig).

NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.

ntdll.dll!RtlUserThreadStart()

There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.

https://github.com/ziglang/zig/issues/11894

Zig also has an IRC channel on libera (#zig) that is moderated by Andrew Kelley.[1]

[1] https://github.com/ziglang/zig/wiki/Community