Speaking from experience, using MicroPython is trivial and often "good enough", as are implementing modules for MicroPython in C should they be needed (C isn't my first language by a long shot, but I managed to write a module for MicroPython with little problem).

Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS?

Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.

> Why not just use C instead of mJS?

Perhaps mjs has a repl? Don't really know, but that would be the only real advantage imo.

Indeed, share the vision of the product instead and how does it add value to the existing ecosystem.

The advantage is time. Many (most?) embedded environments are overly difficult (IMHO), and/or proprietary. Also, even in a good environment, C/C++ typically requires more lines of code than dynamic languages like Python or JS.

Therefore, the industry has been looking for ways to combat both the below par developer experience, and the development time. Samsung's Jerryscript [1] is another example.

That said, I think these things are aspiration more than they are practical.

[1] http://jerryscript.net/

Note: Edited to clarify C++ vs. dynamic languages.

Sure, I think I see the reasoning behind: reduce the time to market for embedded products.

But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so. It seems that both are capable of handling this problem, however mJS seems aiming at a compromise between JS and C, and my opinion on this is that it will introduce huge overheads on any projects. This mostly stems from my being wary of multi-language projects.

The process involved in embedded platforms seems heavy enough as it is, no need to blur the lines further.

> But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so

I agree with your concern: to me Micropython seems like a much better choice. On the other hand, it's pretty limited to what hardware it runs on.

mJS allows you to use C/C++ SDK functions directly without writing a glue code - basically, you can prototype things quite fast with the libraries/drivers that do not have any scripting support yet.

But why not make that for micropython instead of making a whole new language?

Ideally you don't want to port the C/C++ over to Python: that's the value proposition of mJS, I think.

> Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point)

If i was having an IoT company or start-up, i would make sure to hire proper engineers; the ones that have no problem with switching between Javascript, C, and Python, or learning them on the fly if needed.

Seriosly, is this really a problem at all?

It is obvious that it is quicker to prototype in Python or JS or whatever scripting language. While for real world usage you would also care about performance and efficiency issues which would better be solved by having more direct control over the bare-metal (C, even assembler.)

> Seriosly, is this really a problem at all?

Yes. I write Python and C everyday. I am highly proficient in both. I would quickly withdraw from a project that mixes both in the same code base.

I'd also be slightly alarmed to see someone claiming to be able to distinguish proper engineers and not being aware of the issue with multi-language projects :-) .

My issue with multi-language project is that you introduce a lot of overhead to the process surrounding the code. The code-review / static analysis, build and test all requires an additional toolchain and associated best practices. It is already an issue with single-language projects to do this right, it quickly becomes a nightmare when you introduce an additional language.

And that's without even considering the need of FFI integration or likewise, with possibly (preferably) framework to handle the generation of the interfaces, and thus the introduction of another dependency, a possible sub-par codebase with the associated bugs, and potentially very subtle bugs due to your objects not playing nice with the intermediate representation.

I did it with a C++ / Java interface, never again. I would never greenlight such a project.

This has nothing to do with the proficiency or the willingness to learn of your engineers.

Fast prototyping is the answer. If you or some others are skilled in C/C++, you don't need JS.

For others, having a simple way to prototype fast on the target hardware is a big benefit.