On typing, there's only a few main ones you need to worry about—strings, functions, tables and numbers. I don't think it does weird things like JS where it converts between them without asking. Luau adds some type hinting if it's a big point of concern but I haven't really looked into it much.
I know it’s probably and overreaction, but this was a compete non-starter for me.
https://typescripttolua.github.io/
I’m personally a fan of YueScript which is basically an evolution of MoonScript (but it’s not typed).
LuaJIT has ridiculously easy C interop.
The dev experience for lua is f-ing awful.
The language is small, but not “simple”; it’s stuck in 1985.
The tooling is nearly non-existent and the stuff that does exist is a joke.
The few libraries that exist are awful and barely maintained; the maintained libraries are maintained by neckbeards with a god-complex.
The community is “reimplementing everything by hand is the right way to do it AND ALSO you’re an idiot doing it wrong” toxic. There are a million good reasons why it’s only has a foothold in nginx and Roblox territory.
It’s not a joke to say that it’s f-ing terrible all the way around.
There are a LOT of tools with embedded Lua scripting capabilities.
The ease of embedding Lua, even with a C++ wrapper, is incredible. With little effort, I now have something I consider “ready”.
Not to mention, it’s a very lightweight VM.
All of these products are still alive today, actively supported and making my customers good money.
Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.
For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.
The experience I had there might be your best bet for something productive. That board came with a 'limited C-like compiler' (took a mostly complete subset of C syntax and transcribed it to ASM).
You'll probably be doing a lot of things like executing in place from ROM, and strictly managing stack and scratch pad use.
The 64MB of RAM and 8MB (I assume that's 64Mbit) of ROM allow for highly liberating things like compressed executable code copied to faster RAM, modify in place code, and enough spare RAM otherwise to use scripting languages and large buffers for work as desired.
I find it difficult to take any writing seriously when it uses phrases like this.
MicroPython can be equally readable, but in practice, many projects end up with blurred layers between system code and scripting. That creates a maintenance burden as projects grow.
Yeah, right. Even if this is the case (I find it hard to belive the author has really seen 'many' sort of professional MicroPython projects), where's the proof the language used was the deciding factor in that. And not the project management for instance. Or simply the dev's architecturing abilities.
You use micrpython when you have lots of horsepower and need something fairly robust on the network.
You use C/C++ if you need precise control over power, memory or CPU. Even though if you're doing network stuff its much harder to do quickly and securely. (THere might be better embedded TLS support now)
Lua is frankly just sparkling C. Sure if someone has create a bunch of libraries for you, then great, if not, you've now go to support lua toolchain, and your own microcontrollers toolchain, and port what ever control lib the manufacturer provides yourself.
Or, as this is a marketing page, pay https://realtimelogic.com/products/xedge/ to do it for you.
It runs on a 2350.
jacknews•3h ago
Python does have the 'there should be one, preferably only one, way to do it' mantra, but to me it utterly fails at that, and is in fact a bit of a 'kitchen sink' or 'armchair' language.
That is it's strength in some ways, it's easy and approachable, and has more libraries than perhaps any other language, so you can usually get something working fairly quickly.
But it's not so suited to sparse environments. You can't easily turn a plump armchair with automatic footrests and telescoping side-tables into a plywood Eames.
qznc•3h ago
The problem of "easy" is that it implies hidden complexity for its magic. The problem of "simple" is that it requires more work from its users.
3036e4•33m ago