Thanks you very much for the support, I can totally understand that position.

We have been making great progress in terms of features since then to "flesh out" the languages and libraries including threading support, an event loop, and some basic networking (socket) support built in to the runtime. Generally though, the PL design space is already incredibly fatigued an most new languages claiming something have already been made a few times over, just doing doing one thing slightly better, so it is true we cannot truly compete in that space.

Janet is a hobby lisp(?) taken too far and I have been adding lots of features that I find useful for day-to-day programming and experiments while still being something "embed-able" into another project. Janet is not a corporate project in anyway and donations are accepted mostly as a token of gratitude and expenses used to maintain the website and CI bills. My goal is really just to make it a good, clean, useful language for my own use and not as some kind of advertisement or product for anything, it is a project I started in my college dorm and have continued working on as a passion project since.

Thank you for creating Janet. It is a fun language and it's exciting to watch it evolve. With the addition of the event loop and networking I'm curious to know if an http client and http server based on these will be added in the future?

I am aware that there are already libraries that cover these to an extent like circlet and halo for http. Joy also features an http client. Maybe it's outside the scope of the project, but I think an http server and client as part of the core would really add to the utility of Janet. It would also answer some of the licensing questions for distribution if these were included directly in Janet core. For example, circlet is MIT, but it is based on mongoose is GPLv2.

Also, seeing Janet on HN a year or so ago was what got me to watch The Good Place, so thanks for that as well.

Probably unlikely to be added in the core (esp. HTTP/2), but an HTTP/1 implementation could be done in pure janet - there is a binding of just a parser here: https://github.com/andrewchambers/janet-pico-http-parser

But yes, at some point a canonical replacement for circlet that was MIT licensed and event-loop friendly would be nice.

How Lua is viable in embedded? You mean microcontroller/low-level programming right?

I once worked on a project at a FAANG where we had to run an app on a 600Mhz CPU with no FPU. Javascript (v8, spidermonkey) wouldn't cut it (for some reasons function calls where very slow amongst other things). While Lua was incredibly fast on that hardware and the VM footprint was also a blessing. Even better, we could send a binary blob of the Lua VM/app state over the wire, and so we could precompute the whole app start on a server and send that to the device (the app would start in under 5 secondes instead of minutes as it would just load the blob). Best hacking time of my career, thanks to Lua.

Embedded is a fuzzy category, specs range from <1kb Ram to the low megabytes. Some people even extend it till low end smartphones and things like raspberry pies which are like gaming PCs by mid 2000s standards.

Lua is extremely lightweight and portable. The interpreter doesn't exceed 500 kb in the fattest build, and the used dialect is a strict subset of ANSI C that is equally comfortable running on mainframes as on Nintendo consoles.

In short : If it has a C compiler and can spare 300 kb ram, it can run Lua. So people sometimes use it there.

>Embedded is a fuzzy category, specs range from <1kb Ram to the low megabytes.

After a career in embedded software, I'd have to say that I've only worked on a couple of products that had less oomph than a high-end PC of the same era.

Indeed (see also "embedded Linux" being a thing), people insisting if something doesn't run on a tiny PIC it can't be useful for "embedded" is a pet peeve of mine.

Depending on the context, "embedded systems" go even larger, although usually people stop calling it "embedded programming" at some point. Obviously many problems in large embedded systems are different from small ones, but others remain similar.

I imagine they are annoyed because it used to be more clear, easier to google, etc. The discussion and search space was polluted for them as the meaning of the term changed, and no new term filled the void.

"microcontroller" seems like a term that would differentiate from things like embedded Linux and SoCs.

When was that? The range wasn't as large because the top end was way more limited, but the same thing applied at least since the 90s.

My impression in the 90s is that most people talking about embedded were talking about microcontrollers or very limited microprocessors.

My counterpoints would be e.g. QNX and vxWorks, famous embedded OSes, both being active in the 90s (roots go to the 80s, but in both cases afaik they really came into being and found a market in the 90s). Plenty 90s embedded hardware with x86 CPUs in it.

What's probably different today is that you have more options also on MCUs (not just assembly and maybe C), because MCUs have grown.

In this case, I believe "embedded" means "in another program, as a scripting language".