3 ms·

Mostly agree. My go to language is python. Used c# in last job and it improved much over past few years. When I need blinding speed I can use nuitka to compile

Mostly agree. My go to language is python. Used c# in last job and it improved much over past few years. When I need blinding speed I can use nuitka to compile python scripts. On the rare occasions needing speed and cross platform coupled with my lessons to avoid wasted effort I turn to Lazarus/fpc because code is simple and Lazarus takes care of the target platform stuff so I don't have to. For IOT bare-metal stuff you can't go past C. It just works and after learning it's quirks you will see how other IOT tools are largely hacks or compromises to avoid learning C.

caseymarquis 7y ago
<rant> I think you're right that there's no viable alternative to C for IOT right now. However, I also think we need to collectively move past C in this space. The compile, run, debug cycle in embedded electronics is just too slow. I don't really mind the language, just the painfully slow development (and lack of package management). uPython and similar are a move in the right direction, but I think we need a minimalist crossplatform bytecode runtime to become standard on every popular embedded platform. This runtime needs frictionless c FFI (with the ability to seemlessly drop into c at any point, though it may require a recompile), and to be designed with embedded in mind. Actors and RPC should be first class citizens, as should remote inspection of systems over the wire, hotswapping running code, and the security needed to do those things safely (easy to get started with automatic self signed encryption). I think that every attempt at doing this so far is focusing on creating hobbyist boards for people who don't want to learn c instead of creating this ideal runtime with seemless c ffi (allowing easy adoption on new platforms), or is not lightweight enough to run on $4 chips like the ESP32. I think that most likely this platform will need to be written in c, and provide simple hooks for tying the networking libraries for individual boards together. I was looking into building this for something my company needs, but then a Taiwanese company approached me about a low cost industrial modular linux device with hotswappable i/o they're developing. At this point I just shrugged and figured that seemed a lot easier than building a better wheel. The thing is, I can use a $400 modular linux device because my market can bear it, but I was looking at developing the other set of features for inexpensive micros. Virtually every market can bear the cost of a $4 chip. </rant> I apologize for the rant, it just physically pains me that this doesn't exist, and that embedded development is so primitive.
- bluesnowmonkey 7y ago
  Actors, RPC, remote inspection, hot swapping, you're talking about Nerves right? https://nerves-project.org/ https://nerves-project.org/
  - caseymarquis 7y ago
    Nerves is too resource intensive, but that's the right idea. AtomVM is closer to what I'm thinking, except ideally I want static typing that's interoperable with C, and the readme for the project would be something like: Here is a bunch of C code with some functions you need to fill in. Compile these two files for your device, and fill in all of the second file's function bodies. We maintain versions of the second file for common boards. If you add a c function to the second file, our tooling allows you to call it from the runtime. C FFI is really critical, as that allows you to use all the existing libraries on a given platform. So, a runtime language with elixir/erlang features, but with the C FFI of Nim. But Nim is compiled, and we need bytecode for rapid iteration. The challenge is that what is nearly universal right now is a c compiler, but the board is always different. S7 scheme has the right idea with a single c file, but is too resource intensive and wasn't built for embedded electronics. There is definitely an unfilled niche for rapid embedded application development. We're either going to get a $4 RPi in a chip someday, or the platform I'm describing needs to be created. Those are the routes I see to embedded RAD.

caseymarquis 7y ago

<rant> I think you're right that there's no viable alternative to C for IOT right now. However, I also think we need to collectively move past C in this space. The compile, run, debug cycle in embedded electronics is just too slow. I don't really mind the language, just the painfully slow development (and lack of package management). uPython and similar are a move in the right direction, but I think we need a minimalist crossplatform bytecode runtime to become standard on every popular embedded platform. This runtime needs frictionless c FFI (with the ability to seemlessly drop into c at any point, though it may require a recompile), and to be designed with embedded in mind. Actors and RPC should be first class citizens, as should remote inspection of systems over the wire, hotswapping running code, and the security needed to do those things safely (easy to get started with automatic self signed encryption). I think that every attempt at doing this so far is focusing on creating hobbyist boards for people who don't want to learn c instead of creating this ideal runtime with seemless c ffi (allowing easy adoption on new platforms), or is not lightweight enough to run on $4 chips like the ESP32. I think that most likely this platform will need to be written in c, and provide simple hooks for tying the networking libraries for individual boards together. I was looking into building this for something my company needs, but then a Taiwanese company approached me about a low cost industrial modular linux device with hotswappable i/o they're developing. At this point I just shrugged and figured that seemed a lot easier than building a better wheel. The thing is, I can use a $400 modular linux device because my market can bear it, but I was looking at developing the other set of features for inexpensive micros. Virtually every market can bear the cost of a $4 chip. </rant> I apologize for the rant, it just physically pains me that this doesn't exist, and that embedded development is so primitive.

bluesnowmonkey 7y ago
Actors, RPC, remote inspection, hot swapping, you're talking about Nerves right? https://nerves-project.org/ https://nerves-project.org/
- caseymarquis 7y ago
  Nerves is too resource intensive, but that's the right idea. AtomVM is closer to what I'm thinking, except ideally I want static typing that's interoperable with C, and the readme for the project would be something like: Here is a bunch of C code with some functions you need to fill in. Compile these two files for your device, and fill in all of the second file's function bodies. We maintain versions of the second file for common boards. If you add a c function to the second file, our tooling allows you to call it from the runtime. C FFI is really critical, as that allows you to use all the existing libraries on a given platform. So, a runtime language with elixir/erlang features, but with the C FFI of Nim. But Nim is compiled, and we need bytecode for rapid iteration. The challenge is that what is nearly universal right now is a c compiler, but the board is always different. S7 scheme has the right idea with a single c file, but is too resource intensive and wasn't built for embedded electronics. There is definitely an unfilled niche for rapid embedded application development. We're either going to get a $4 RPi in a chip someday, or the platform I'm describing needs to be created. Those are the routes I see to embedded RAD.