But I've also just spent the past year programming an automated mobile restaurant. We use a traditional PLC for everything safety or time-sensitive, but everything else is JavaScript.
We're planning to use even more JS on the next-gen system. Details are in my profile if you want to help, or if you want to convince me otherwise.
https://todbot.com/blog/2006/09/25/arduino-the-basic-stamp-k...
> Getting to the “Hello World” of microcontroller projects, the blinking LED, on Arduino costs $32 compared to the $119 for a Basic Stamp. This is perhaps a little unfair because the Basic Stamp board contains a full bread-boarding space. A similar setup for Arduino would cost about $60, still a 2x savings (and can made cheaper if you want).
[snip]
> The standard Atmel AVR ATmega8 chip used on the Arduino board can be obtained for less than $4. The Basic Stamp must be obtained from Parallax and costs $50.
It just seems insane to me to use a language with such bizarre semantics.
If industrial equipment malfunctions, people can be killed or horribly maimed. Industrial equipment needs to do exactly what it was designed to do 24/7 for years or decades in horrible (EMI, temperature, etc) environments.
In what way does C vs. python or javascript have any impact on this? If anything, C has way more ability to shoot yourself in the foot than python or javascript. Hell, what about a non memory-managed language like rust?
Like somebody else says, this feels more like a cultural issue than an actual technical issue.
To the larger point of coding for these kinds of applications, keep in mind that there are entire classes of bugs that are common in traditional microcontroller languages like C which literally do not exist in Python or Javascript.
As far as I've seen as an outsider to the embedded world the main barriers to adoption of higher level languages have not been based upon concerns of reliability, but instead memory usage and timing constraints, the former of which is less and less of a real problem outside of extremely cost constrained applications.
I recently had a chance to wander around one of the bigger EMS factories in the Bay Area, rubbernecking at everybody else's products in various stages of assembly. It's safe to say not many naysaying HN'ers have done that recently, or they would be saying something very different.
One of the RasPi-based devices I saw being assembled was actually some kind of medical device that will presumably have to be FDA-certified. It was going into a very nice enclosure, with top-grade plastics and other materials, and they were building a (literal) ton of them. In principle I'm sure that can be done successfully, but I have to wonder if it'll really save the company that much time or money.
Heck, the ESP32 runs circles around the Amstrad that I used to play Defender of the Crown on.
To address the sibling comment, we don't use much TypeScript yet, but I'm open to it. I'm also looking at ReasonML because I'm cautious about half-measures when it comes to type safety.
Much of our complexity stems from race conditions between PLC and the JS server, so the next system is likely to use node.js on linux boards instead of a PLC. We currently have a supervisory safety system with all safety-rated hardware and controls, and will almost certainly continue using this approach as we replace the PLC.