State management in flutter can be done in so many ways so I get why it could feel complex, we’ve used Hooks a lot and it simplified a ton of stuff. Can also go the whole BLOC route too. Having issues with setState means you’re doing something that’s an anti-pattern

Yeah I think the point is that you have to become a state management expert in Flutter... even if the end result is not very complex there are so many options and so many pitfalls you still have to do a ton of thinking and learning to get there.

With egui you pretty much don't have to think about it at all.

AtomVM is super fun to prototype MCU projects with. It’s what I tend to reach for over micropython etc.

For beefier machines that have SoCs it’s Nerves usually.

And recently a project called Popcorn uses the AtomVM to run BEAM VM code in the browser! Super neat seeing more places to deploy Elixir and Erlang :)

I have a version (probably not exactly the same software for the head unit) of this on an SGI O2 sitting around including all the environment scripts and the HTML manuals. I have a tar.gz of it that I should upload to an archive location.

Please do! The software has been undumped and is highly desired by retro enthusiasts (including myself)

I always saw it like this:

- If you're building an engine without a game in mind, you're just going to end up with tools you don't use.

- If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project.

All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)

As a newer user of Flutter I found Riverpod to be extremely heavy and have a lot more mental overhead than using stateless widgets with Hooks.

Any particular reason you personally prefer Riverpod?

Hi, author of the article here.

Any state management approach requires you to adapt your way of thinking, whether that be BLoC, Riverpod, Redux or anything you want to use.

Rivepod gained popularity because it's really simple to pick up: create a Notifier, create a Provider for it, and observe, while some other approaches require additional boilerplate, setup, and understanding.

Your approach would work if you are only observing that state from a single widget, which might not always be the case. Additionally, assuming useState is using setState under the hood means it will rebuild the whole widget on change, while with Riverpod, you have the flexibility to wrap any part of a complex widget into a Consumer or listen to only part of the exposed state on the Notifier with .select().

To put it simply: - Notifiers are used for app state - Hooks are used for ephemeral state (local widget state)

Hope this clears it bit for you.

Great summary, it does indeed! Thanks for taking the time to reply

This was my experience as well. I have however been very happy with get_it <https://pub.dev/packages/get_it> and watch_it <https://pub.dev/packages/watch_it> though, which just totally clicked for me in terms of how it works with the state store (database).

That's the beauty of diversity. You can use whatever resonates with you best and still make it work on the app side.

Riverpod does a lot more than just state management - it also handles dependency injection and reactive caching.

Here’s a great guide on using Riverpod: https://codewithandrea.com/articles/flutter-state-management...

Yes it does, and I specifically outlined that in my other article: https://dinkomarinac.dev/riverpod-simplified-lessons-learned...

His question was directed towards the state management, hence the answer only covered that.

Check MobX, that's what I ended up using.

Reading this line made me so mad. I've been a huge fan of lower power ARM CPUs... this literally just halt/hampers progress in this country. I can't believe we have to put up with 4 full years of this crap.

I would have purchased this board in a heartbeat otherwise. Ugh.

....atleast 4 years

I'm really perplexed by this choice... at my current employer we only deploy developer SSH keys to devices with DEV or QA firmware. Prod images are signed and have SSH entirely disabled.

We have a separate piece of software to remotely access devices in prod to help diagnose engineering issues, where we can pull up a REPL, but that's under access control and gated by devops etc.

This is deeply ironic to me because this company is run by the same guy who has his underlings tearing through our government data, secretly building repositories with titles like NxGenBdoorExtract[0]. I don't trust this guy at all.

[0]https://www.npr.org/2025/04/15/nx-s1-5355896/doge-nlrb-elon-...

At a minimum you'd want to encrypt your rootfs using secrets that are hard to extract from secure elements. To go a step further you can employ something like ARM's TrustZone to hide away the sensitive operations (bootloader, decryptions, image signing, etc.)

The fact that they could just dump the filesystem tells me there's no protection employed at SpaceX aside from the boot loader mentioned in the article.

the inability to make the horrible integrated shopping experience go away forced me to Kagi about a year ago. So much cleaner.

I’ve always just done

  alias hst=“history | fzf”

Not nearly as feature full but the simplicity of it makes me happy :)