Hacker News Reader

Comment by stathibus | Hacker News Reader

Why?

> Instead of writing firmware code in C/C++, Elk allows to develop in JavaScript. Another use case is providing customers with a secure, protected scripting environment for product customisation.

Right, but why would anyone want to do that? Who thinks that JavaScript is a good choice for this?

Why is JavaScript a bad choice for this?

Many reasons occur to me, but the top few would be:

* Lua already exists and is better suited to this

* JS is a relatively complicated language to evaluate

* JS requires a large amount of dynamic allocation

* JS isn't really the first thing (or in the top 25 things) I would pick when developing on a platform where I wasn't already stuck with it

- JS requires a large amount of dynamic allocation

One of the top listed features of this interpreter is a fixed memory footprint

- JS is a relatively complicated language to evaluate

In developing this interpreter they eliminated some of the languages features to make it simpler.

> In developing this interpreter they eliminated some of the languages features to make it simpler.

That means you can't run general-purpose code safely, which means you should probably write/rewrite/adapt it, which means you might as well use a different language.

I'm a JS developer, but the parent might have a point here. Why run something like this in production when you're likely to end up in unexpected situations? Either a runtime is compliant, or you're going to have a bad time.

The project is cool, but I wouldn't use it as an example for what JS can do.

> One of the top listed features of this interpreter is a fixed memory footprint

In embedded systems that is often a necessity but calling it a feature instead of a constraint is a good idea.

I imagine it's nice for things like a product that allows some amount of scripted control by end users.

People who know javascript

And can now run in a tiny engine!

People that grew up with BASIC, z80 and 6502 Assembly and know C isn't the answer for everything.

The example with ESP32 is quite, the hardware is much more powerful than pre-Windows PCs, so why pretend it is something where C and Assembly are the only answer, when MS-DOS had plenty of languages to chose from.

Ok that's an argument for other languages, but not for JavaScript. JS is not good.

Just out of curiousity, how is Pike[0] for this type of use-case?

[0] https://pike.lysator.liu.se/development/git/

Look up how many Js basics tutorials there are, then check how many Pike basics tutorials there are

Because "20KB on flash/disk, about 100 bytes RAM" is smaller than practically anything out there in the space.

Forth is at that size. Tcl implementations are at least triple that. As are all the Schemes I have seen. Lua similarly.

Anything I've missed?

I can imagine this would be great if you want to have multiple tiny apps running on a small embedded device - even with some basic multi-tasking! This is actually super cool.

Literally just yesterday I was trying to find the equivalent for Java, byte code or otherwise. I want to attempt to run several nano JVM apps on an ESP32, but I'm starting to think that it might not be possible.

Many years ago now I ran a custom 'script runner' that fit into 512 bytes of assembly language for a custom kernel (that was also 512 bytes) [1]. I would really like to play with something like Elk and see what can be done!

[1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...

It seems to me that embedded Lua would be a more appropriate choice, and barring that, there is already a quite robust embedded Python implementation.

Don't get me wrong, this is a cool project, but I don't see why you would ever choose to use JS in an embedded context except for fun. The arguments for using lua or micropython are already very narrowly applicable.

Seems inarguable to me that JavaScript is much more widely known and adopted than Lua. So it makes sense to use JS in 'toy' like environments where someone is learning an embedded platform.

JS is more common, but this is not a complete implementation. So those skills may not transfer 100%.

But they certainly will more than they would to a completely new language…

I don’t understand why people are so focused on preventing anyone from ever having to learn a new language. If you already know JS, learning lua should be trivial.

Interesting, could you link me the Lua and Python libraries you are thinking of?

Micropython and eLua come to mind

Microsoft also considers JavaScript makes business sense.

https://www.microsoft.com/en-us/makecode

Did you look hard enough?

https://www.microej.com/product/sdk/

https://developer.microej.com/supported-embedded-runtime-arc...

It doesn't take away from the point that the thing exists, but the licensing for this sort of stuff is almost always horrid. You're sparing yourself the headache of semi-supported open-source options, but it always feels like anything you saved by doing that is completely offset and then some by getting your balls busted in perpetuity by whatever vendor you went with. I don't blame anybody for sending these types of things to the mental trash bin when they see them.

Some supermarkets take pull requests, unfortunely most of them still like to get cash instead.

I'm gonna be honest -- I don't entirely understand what you're trying to say. Are you implying that the work needs to be paid for it get done? Of course that's the case, and open source embedded libraries can and do make plenty of money through consulting without having to annoy the customer with per-architecture and/or per-product licensing, and without having to hire salespeople to convince customers that that's necessary.

> Did you look hard enough?

I did see microej but I'm specifically interested in open-source - and from what I can tell this is some kind of paid service. I didn't look particularly close though [1]. The ESP32 device they do support appears to be a very specific development kit [2].

[1] https://github.com/MicroEJ

[2] https://github.com/MicroEJ/Platform-Espressif-ESP-WROVER-KIT...

Well you didn't mentioned you were looking after free beer.

There were several very small implementation of JVM over the years. One semi-popular one was leJOS for Legos Mindstorms. At one point, I recall even building it for DOS to test some things.

https://lejos.sourceforge.io/

Seems interesting, how was the porting process?

I was just looking at the Java bytecode and thinking "in theory, one could build a small JVM for this" [1]. But it still looks like an enormous effort to build, test and then use in a meaningful way.

[1] https://en.wikipedia.org/wiki/Java_bytecode_instruction_list...

IIRC, at the time, building on DOS w/djgpp was fully supported since leJOS is designed to be fairly OS independent. There's not much room for an OS in the Lego Mindstorms MCU. You can think of it a bit like how people today build minimal Rust or Go-lang OS experiments.

> Anything that good hackers would find interesting.

Totally on topic. I dislike JS but this is rad. And like upthread said, clean understandable implementation. Very educational.

Because your system may require that you can change code at runtime without reflashing your micro. I very, very much dislike JavaScript, but it's not an outlandish requirement and there's not a lot of (what I would consider) great options in that arena with expansive C interop (which you would need for a "real" application). There's basically JavaScript, Python, and Lua. There's plenty of other stuff out there, but none with the same amount of backing as those three.

Embedded development is the bat country of software. You will definitely have to do some unsavory things to get where you're trying to go.

Wouldn't there be better options for that? python, lua, tcl, perl, ... ?

Prototyping and hobby use are the two obvious use cases I can think of.

Reply on news.ycombinator.com