Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
zephyr
Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Here's another example of the coolness of Zig's comptime code execution:
https://github.com/ziglang/zig/commit/0808d98e10c5fea27cebf9...
That's a generic container class (similar to vector in C++ or List in C#). But! With a twist!
It stores structs in "column major" order in memory (e.g., if a struct had two fields A and B, then in-memory layout would be A...AB...B), and you can idiomatically and efficiently get a a slice of the values of each column.
I.e., it's a datastructure that automatically applies the struct-of-arrays optimization:
https://en.m.wikipedia.org/wiki/AoS_and_SoA#Structure_of_Arr...
And the code to do it is straightforward, normal Zig.
Pretty awesome stuff!
TinyGo is a Go toolchain for microcontrollers that uses LLVM, and it produces binaries that are extremely small. A few kB is not uncommon, from what I've heard, although I don't have much personal experience with it.
The standard Go toolchain cannot compile for microcontrollers, so the size of binaries that it produces is irrelevant.
Just like there are many compilers for C, there are multiple compilers for Go with different priorities.
https://tinygo.org
The embedded HAL crates do this with extensive use of macros, for example: https://github.com/nrf-rs/nrf-hal/blob/aae17943efc24baffe30b...
This solution makes sense given the constraints of Rust, but there's quite a cost in terms of compiler time and cognitive overhead to understand what is going on.
(Aside: I didn't use the HAL in my Rust firmware, that's a higher layer of abstraction; I only used the PAC crates.)
Some context on the issues you pointed (all true, to be clear):
> * no (official) package manager yet, though this is aparently being worked on
It's the next item on the roadmap as soon as the self-hosted compiler is good enough.
> * documentation is often incomplete and lacking
The language reference is good, but for the stblib it's best to just read the source code. For other miscellaneous learning materials:
https://ziglearn.org/
https://github.com/ratfactor/ziglings
https://www.youtube.com/c/ZigSHOWTIME
* error handling with inferred error sets and `try` is very nice! But for now errors can't hold any data, they are just identifiers, which is often insufficient for good error reporting or handling.
It's still under debate and I'm personally in the camp that errors should not have a payload, so I would avoid assuming that it's definitely the preferable choice. We already have a couple of existing patterns for when diagnostics are needed. That said proposals about adding support for error payloads are still open, so who knows.
https://github.com/ziglang/zig/issues/2647
https://github.com/ziglang/zig/issues/7812
Existing pattern: https://github.com/ziglang/zig/issues/2647#issuecomment-5898...
> * No closures! (big gotcha)
It's possible to create closures already (by declaring a struct type with a method (the closure) and instantiating it immediately after), but it's a clunky solution. We also have an open proposal in this space:
https://github.com/ziglang/zig/issues/6965
Not quite as seamless as Zig, but dstep is an external program that leverages libclang to do the same thing (and generates a D module for you), as well as e.g., smartly convert #define macros to inlineable templates functions :)
https://github.com/jacob-carlborg/dstep
I'm going to sound old and very uncool but ...
Use C! I'm in the process of doing my first "serious" project in 'straight' C (I'm a C++ guy from long ago) and it's taken me a while to get into it properly, but I'm starting to get its philosophy and it's becoming easy.
But also, in the embedded space, it clearly has all the support you could ever want. I'm also gradually falling for Zephyr (https://www.zephyrproject.org) that has all the support for (eg) callbacks, all sorts of low level stuff.
And one more ... the way you'd solve this in Zephyr is to use the scary simple API (https://docs.zephyrproject.org/latest/reference/peripherals/...).
https://github.com/zephyrproject-rtos/zephyr/blob/master/sam...