mo VS esp-wifi

A simple alternative is the combination of:

- https://github.com/samber/lo

- https://github.com/samber/mo

The split is also nice as you can choose to just use the generic convenience functions from lo without the more FP related things from mo.

Is it a popular approach to use abstractions in general for handling nil values with libraries like null or mo? Should I just stick with pointers? What are your experiences on this topic?

I really like it. Have been using it for a while, just don't overuse it. Also, I recommend github.com/samber/mo

Go generics allow all kinds of things https://github.com/samber/mo

Have you taken a look at mo? https://github.com/samber/mo

If you are curious, try looking at github.com/samber/lo and github.com/samber/mo packages if you get a chance.

I have seen https://github.com/samber/mo but it's a niche. Monads aren't popular in Golang community.

I've also looked at the mo library, in particular to use Option[User] but that's really just a slightly safer way to represent User* here. (Safer because you're forced to check if there's a value and so don't have the same accidental panic risk.)

Good question! As far as I can tell from the docs, it looks like I2C is still synchronous [1], but this will be my first async embedded Rust project, so I'm still unfamiliar with the general shape and functionality of things.

For comparison, things like WiFi are definitely async [2]

[1] https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.htm...

[2] https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s...

Among these several abstractions, we can program a microcontroller device at any level we like. Additionally, we can develop code with a mix of low-level and high-level abstractions. Obviously, to make code more portable it's better to stick to higher-level abstractions. Also in addition to the above, there exists other crates supporting other functions in no-std development. These include wifi services in the esp-wifi repository, heap allocators in the esp-alloc repository, logging features in the esp-println repository, exception handlers in the esp-backtrace repository, and finally embedded storage traits in the esp-storage repository.

I haven't done much with it yet, but I'm excited about the bare-metal (no_std) rust support for the esp32c3 (as opposed to some other variants that require a custom toolchain as I understand it).

Lots of details at <https://mabez.dev/blog/posts/>, and some examples of wifi on bare-metal at <https://github.com/esp-rs/esp-wifi>.

I hope to eventually get it working with MQTT (there may be examples already, I haven't yet looked in-depth), at which point I think this will be my go-to for the majority of my IOT projects going forward!

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed.

[0]: https://github.com/esp-rs/esp-wifi#current-support

I previously used the esp32-c3 both with bare-metal and with the idf in rust, but I did not like the experience. With the idf you get poor ide support and poor documentation and with bare metal you used to get no wifi at all, but the experience is a lot better. I have seen the new rust wifi driver https://github.com/esp-rs/esp-wifi and i am very interested, but this is still a sync driver afaik.

Also got an ESP32C3 to connect to my wifi network, which was really exciting: https://github.com/esp-rs/esp-wifi

Check the project https://github.com/esp-rs/esp-wifi, it implement bindings to the official SDK.