HN user

TickleSteve

2,009 karma
Posts2
Comments868
View on HN

scale vertically before horizontally...

- scaling vertically is cheaper to develop

- scaling horizontally gets you further.

What is correct for your situation depends on your human, financial and time resources.

Never. Do. This...

I was involved in a product with a large codebase structured like this and it was a maintainability nightmare with no upsides. Multiple attempts were made to move away from this to no avail.

Consider that the code has terrible readability due to no syntax-sugar, the compiler cannot see through the pointers to optimise anything, tooling has no clue what to do with it. On top of that, the syntax is odd and requires any newbies to effectively understand how a c++ compiler works under-the-hood to get anything out of it.

On top of those points, the dubious benefits of OOP make doing this a quick way to kill long-term maintainability of your project.

For the devs who come after you, dont try to turn C into a poor-mans C++. If you really want to, please just use C++.

K1 (racing) kayaks are unstable and very narrow, most other types are fairly stable tho.

The correct phrase is "mechanical sympathy" but it means effectively the same. Its relatively well known in software optimisation and means tailoring the design of the software to match the characteristics of the hardware.

There are similar devices (i.e. SiLabs) that allow multi-protocol use with the radio (I would expect Nordic to have a similar feature set), tho yes, you're right the resource issue would be a major limitation.

static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".

packets are sequenced, integrity checked and encrypted to prevent replay attacks so unlikely to be a simple "send packet again" issue. More likely a key debounce issue or driver issue.

"OS" in this context means "scheduler", i.e the code that coordinates your application tasks. That description can also apply to VMs such as JS, hence the comparison.

You could consider this type of library OS even more tightly bound to the application than your typical JS app as its actually linked to the user code.

I have to admit, Bazel as a build system would mean it wouldnt even be considered by me, it has to fit in with everything else which typically means Makefiles, like it or not.

TBH, Java + Bazel + Discord makes it seem like its out of step with the embedded world.