usbarmory VS dafny

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

Code correctness is a lost art. I requirement to think in abstractions is what scares a lot of devs to avoid it. The higher abstraction language (formal specs) focus on a dedicated language to describe code, whereas lower abstractions (code contracts) basically replace validation logic with a better model.

C# once had Code Contracts[1]; a simple yet powerful way to make formal specifications. The contracts was checked at compile time using the Z3 SMT solver[2]. It was unfortunately deprecated after a few years[3] and once removed from the .NET Runtime it was declared dead.

The closest thing C# now have is probably Dafny[4] while the C# dev guys still try to figure out how to implement it directly in the language[5].

[1] https://www.microsoft.com/en-us/research/project/code-contra...

[2] https://github.com/Z3Prover/z3

[3] https://github.com/microsoft/CodeContracts

[4] https://github.com/dafny-lang/dafny

[5] https://github.com/dotnet/csharplang/issues/105

I don't think something that specific exists. There are a very large number of formal methods tools, each with different specialties / domains.

For verification with proof assistants, [Software Foundations](https://softwarefoundations.cis.upenn.edu/) and [Concrete Semantics](http://concrete-semantics.org/) are both solid.

For verification via model checking, you can check out [Learn TLA+](https://learntla.com/), and the more theoretical [Specifying Systems](https://lamport.azurewebsites.net/tla/book-02-08-08.pdf).

For more theory, check out [Formal Reasoning About Programs](http://adam.chlipala.net/frap/).

And for general projects look at [F*](https://www.fstar-lang.org/) and [Dafny](https://dafny.org/).

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

> I think we can assume it won't be as efficient has hand written code

Actually, surprisingly, not necessarily the case!

If you'll refer to the discussion in https://github.com/dafny-lang/dafny/issues/601 and in https://github.com/dafny-lang/dafny/issues/547, Dafny can statically prove that certain compiler branches are not possible and will never be taken (such as out-of-bounds on index access, logical assumptions about whether a value is greater than or less than some other value, etc). This lets you code in the assumptions (__assume in C++ or unreachable_unchecked() under rust) that will allow the compiler to optimize the codegen using this information.

Most of the proof assistants out there: Lean, Coq, Dafny, Isabelle, F*, Idris 2, and Agda. And the main concepts are dependent types, Homotopy Type Theory AKA HoTT, and Category Theory. Warning: HoTT and Category Theory are really dense, you're going to really need to research them.