mlb-led-scoreboard VS zig

So this is the instructions for the scoreboard: https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard/wiki

First and foremost, thank you to Tommy Farley’s MLB LED Scoreboard Project for the inspiration + most of the code base. My brother and I have been wanting a CFB equivalent of this forever, so we decided to build our own using a Raspberry Pi Zero and a 32 * 64 LED Matrix. Here is a link to the video demo. If you just so happen to have the same equipment, great! Here is our GitHub repository with the code + instructions on making your own. We’re also looking to sell these in the future (once the semiconductor shortage has hopefully settled down)— if you’re interested please let us know! As always, feedback from you all is great appreciated on how we can make this better.

About $200 in parts, runs out of a Pi.

I help maintain the MLB LED scoreboard project and we don't recommend anything less than 5A for a single matrix, and you're running 6 of them. In fact, the tutorial you linked suggests that you are way underpowering your matrices: https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/powering

quick paste of an old how to file i made however heres the github link gh

I bought the RGB matrix and Raspberry Pi and assembled it. Just followed the process here to get the software running - https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard

You can look at the code/follow steps to build one yourself here: https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard. It's pretty straight forward if you have a technical background but if not it might take you a bit to get up to speed with the raspberry pi.

It supports a bunch of different matrix sizes, requires no assembly, and is free, so developers of software like the MLB LED scoreboard don't have to set up and maintain physical hardware to maintain the project. Consumers of those types of projects get the same benefits so you can run the emulated version without needing to pick up a soldering iron.

There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284

https://github.com/ziglang/zig/issues/224

e.g.:

> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g.

When writing code in a scripting language, sometimes you need that extra bit of performance (or maybe an async feature from Zig).

NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.

ntdll.dll!RtlUserThreadStart()

There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.

https://github.com/ziglang/zig/issues/11894

Zig also has an IRC channel on libera (#zig) that is moderated by Andrew Kelley.[1]

[1] https://github.com/ziglang/zig/wiki/Community