[contingencies]

There seems to be a common misconception here amongst traditional desktop and server software people that embedded programming requires vast software complexity. In fact, most real world electronics are very simple software wise. There's just a lot of them, they're a pain to get to, and they have alternative and nuanced challenges and context (cost, speed, debugging, stability, environmental considerations, etc.).

Now regarding language, let me illustrate an area in which C/C++ sucks balls for embedded. Using a cheap MCU is generally considered good practice if you have many target systems to produce and they are possible to execute on that cheap MCU, because using a pricier one will quickly add up and retargeting a team costs a lot. The problem is that on a cheap MCU sometimes you run out of basic resources, such as physical interfaces (pins). In the embedded world there are multiple solutions to most problems, just as there are in the conventional software one (ie. classic perl quote TMTOWTDI) and one of these is connecting IO expansion chips via alternate (particularly shareable) interfaces such as I2C/SPI. Such chips provide various types of interfaces by proxy, for example additional GPIO pins. The issue with these is that many libraries, such as those written to control motors, those written to control MOSFETs/relays, those written to control serial devices will not work by default on these proxied interfaces. Therefore, you need to either hack or rewrite the respective libraries in order to use them.

Coming from a software background myself, this is a basic interface abstraction, and the current solution is ridiculous. Reflectance would go a long way to solving the issue. Lua frankly appeals more than Rust in this regard when dealing with third party, existing libraries which were not constructed explicitly with the requisite abstraction. Alternatively, I believe some software people here on HN recently announced they are attempting a generative approach for embedded circuits and software, sort of a 'ruby on rails' shake-n-bake approach to the whole problem space. The issue with such approaches tends to be that you wind up with a whole lot of deployable product but nobody who understands the intricacies, a vast cognitive overhead for your higher level generation specification languages, there are frequently incompatibilities in devices which are based upon timing, clock frequency or other hard to model aspects of a proposed system, and iterations in hardware cost a lot more in time and money than those in software. Both approaches are used in embedded development, but it is a vast space whose tooling usually differs by target hardware, as if you needed a new IDE, compiler, command line, development workflow and physical interface type for every language you wanted to write on a desktop, and interpreted languages didn't exist. Some of the tooling is prohibitively expensive.

I hope you can now see the problem space is not that similar to desktop software, although the conventional software world does have a lot it could further contribute to electronics. As usual for those outside of an area, the perceived simplicity of established solutions belies the complexity, nuance and outright effectiveness of their current, if ugly, state.

[mjw1007]

The embedded-rust people have a straightforward approach to the interface abstraction situation you describe, and it seems to be going fairly well.

The embedded_hal crate defines traits for controlling things like I2C, SPI, and individual GPIO pins. Then drivers for particular devices are written against those traits.

Given the basic worldview of "we're going to rewrite everything in Rust because that's what Rust people do", I think there's a good chance of ending up in a situation where the embedded Rust ecosystem just doesn't have that problem.

[akiselev]

> I hope you can now see the problem space is not that similar to desktop software, although the conventional software world does have a lot it could further contribute to electronics. As usual for those outside of an area, the perceived simplicity of established solutions belies the complexity, nuance and outright effectiveness of their current, if ugly, state.

Outright effectiveness? The industry is an outright disaster and it's a wonder engineers can get anything done outside of well-funded businesses. A small but representative slice of some of the bullshit I've had to deal with since I started designing electronics (high speed digital and RF):

Meta build systems with pre-pre-processors with feature gates for bug fixes tied to CRMs so that clients don't receive fixes unless they first encounter the bug (and waste weeks trying to fix it while their account manager responds). NDAs on all of the interesting parts with 2+ weeks turn around time on paperwork and 2+ months on samples (but if you're in Shenzhen you can just grab it at the corner store...). Mismatched peripheral IP jammed together with half-assed drivers that wouldn't pass at a client tech demo (can you run both DMA channels at the same time on STM32Fx or does that still crash?). Buggy reference implementations of basic interconnects that silently drop data and don't support run of the mill "advanced" features used in every ARM mcu (thank you, Xilinx). Version control brought to you by WinRar, 7Zip, and IMAP. Data exchange brought to you by The Interns™ because who has time for that shit. Different versions of firmware written by two completely different Qualcomm teams firewalled away from each other for the same chip, in the same market deployed to clients depending on whether they had an existing relationship with Broadcom or not.

The worst part is that none of these problems have much to do with the actual hardware! If it weren't for the culture surrounding the industry, electrical engineering itself would be an absolute pleasure. It has never been easier to slap a schematic and PCB layout together in Altium if you already know what you need, especially with sites like SnapEDA and Octopart simplifying the boring parts (notably, both cofounded by teams with a lot more mainstream software ecosystem experience). It's just getting to that point and writing the firmware afterwards is absolutely awful. I had a similar situation to your MCU example not too long ago and I ended up going with Atmega because downloading a bunch of Arduino projects and looking at firmware in practices makes characterizing a platform and making the right early decisions a lot easier.

To be clear: I couldn't care less about the compile times or higher level abstractions or any of the tech fads that roll through HN (although I am very much hyped up for Rust and now work with React at my day job). I just want a basic culture of information sharing and cooperative common sense that we take for granted. Coming from a software engineering background, the only thing I think this industry has done right is reference designs and PCB layout notes.

I get that the industry isn't a homogeneous blob and most of these problems are a result of the vendors' mismatching economic incentives but that just means that the industry is a natural disaster. All of these problems suck everyone into a feedback loop preventing any real progress, especially when all the details of hardware and software are locked away.