[SV_BubbleTime]

My benchmark for how serious a C replacement is, is when it successfully moves to not embedded and people actually use it.

So far Rust has the smallest of inroads to embedded.

I hope Zig makes it, but I’ve been down this road before.

[girvo]

I’m excited for Zig’s possible future in embedded, too.

I currently use Nim for our firmware at work, because at the end of the day —compileOnly means it’s just C. It’s been excellent for ESP-IDF/FreeRTOS, but I’d love to see Zig tackle it as well.

One lovely side effect of using Nim is our “business logic” code is remarkably simple in the firmware, as I got PPPoS working nicely with our Cat-M1/LTE NB-IoT modem, so making network requests is literally a single line of standard-library Nim. Quite lovely!

The less we have to write C/C++ the better, and I’d love to see Zig and Rust do a great job in embedded-land!

[birdfood]

I've been diving into Nim in my free time after experimenting with Zig and Rust. I really appreciate how clearly I can layout business logic in code without needing to qualify what the compiler should do (my biggest issue with rust is all the stuff you need to do to satisfy the borrow checker I feel obfuscates your intention).

Getting to use Nim for your day job sounds like a dream! I'm particularly keen on Nim's UFCS

[girvo]

> I'm particularly keen on Nim's UFCS

One of my favourite parts about UFCS is how it can turn C libraries that I've had to bind into nice clean looking interfaces!

    esp_err_t sw_enableRx(SwSerial *self, bool State)

Becomes

    proc sw_enableRx*(self: ptr SwSerial, State: bool): esp_err_t {.importc: "$1", header: "<SwSerial.h>".}

Which when called is super lovely!

    var port = sw_open(params, etc)
    port.enableRx(true)

[birdfood]

The end result doesn't look anything like C! Really nice.

Nim almost feels like I'm writing a dynamic scripting language, except that I've worked with a typed python code base and it sucked because typing always felt taped on. With generics in Nim I feel like I'm duck typing, but my ducks are compile time checked!

I'm keen on experimenting with protocol oriented programming and as far as I understand, UFCS provides this really neatly to the language. I really like the idea of being able to define my own types and have them seamlessly work with functionality of other libs (and vice-versa) without needing to resort to a language feature like traits.

[girvo]

Absolutely! It's fantastic :)

One piece of advice I can give, is functional programming (which I am a huge proponent of), as defined by a tonne of chained/composed operations on sequences

   .map.filter.etc.etc()

Is not a good fit for Nim. `proc` is a really good reminder: its a procedural language, more than anything else!

You can still use a lot of FP ideas though, but one thing I always remind myself is at the end of the day Nim _is_ C, C is the output, so working within that idea helps a lot in terms of keeping things optimised with little effort on my behalf!

[slimsag]

Check out[0] and the Zig Embedded Group[1] - it's not well publicized right now, but there's actually quite a lot of work going on here & Zig seems quite suitable for embedded compared to some other languages.

> The standard library can be used unmodified on freestanding targets thanks to explicit allocation, comptime is extremely useful for things like precalculated lookup tables, and the unfinished C backend (part of the stage 2 compiler) means we’ll be able to target exotic architectures that LLVM can’t.

[0] https://allyourcodebase.com/embedded/

[1] https://github.com/ZigEmbeddedGroup

[dleslie]

Still no m68k, sh2, etc?

[Toaster-King]

Both these arch's are contingent on LLVM support, as there is no self-hosted backend (yet). m68k support was merged in LLVM 13, but I haven't seen anyone use it with Zig.

[anonymoushn]

A bunch of people on the discord care about and use the freestanding target, but I don't know much about this.