Rust and C/C++ vs Node

[Aus Lacroix]

Hi All,

It would seem that the major options that we are considering as far as language are Rust and C/C++ but I think that it would be ideal to use node.js on device, especially if we're already running linux.

* Node provides TLS support (including TLS sockets!).
* There is a very robust Hawk module available. (https://github.com/hueniverse/hawk)

* Node LTS v6 is scheduled for October 1st which would get us a lot of the latest and greatest JavaScript features. Will be supported for a minimum of 3 years (https://github.com/nodejs/LTS#lts_schedule).

* Enables seamless updates of our software package. The sensor could check for updates with little to no effort. (https://kjur.github.io/jsrsasign/ can provide signing and authentication of the source, we could also use this library in lieu of Hawk, we could also use the built in crypto api -- https://nodejs.org/dist/latest-v6.x/docs/api/crypto.html)

* Has i2c libraries available (https://github.com/kelly/node-i2c)

* We all know JavaScript already which will definitely speed up development and iterating.

* It's stable, unlike Rust which changes weekly.

* If we were hoping for strong type checking, for example, as a motivation for Rust, we can use Flow (https://flowtype.org/) to provide this in JavaScript. We also have TypeScript (https://www.typescriptlang.org/) as an option there.

* MQTT, if we deem it necessary (https://blog.risingstack.com/getting-started-with-nodejs-and-mqtt/).

I could list more but I feel I may sounds like a broken record. ;) What are the actual, real world advantages, of using rust? Seeing as this isn't a high performance device and our hardware options are fairly beefy I'm really having trouble convincing myself that it makes sense. It think we would not be stacking the odds in our favor for a successful launch of this product by using Rust.

--aus

[Dylan Oliver]

Thanks for starting the conversation Aus. Let's have the discussion and make our choice by next Wednesday along with our hardware selection.

For me, our familiarity with javascript and the maturity of the node ecosystem would make me feel more comfortable going that direction. We did use Rust on the metrics team earlier this year and ran into a number of speedbumps along the way due to the learning curve and frequent language updates. There is going to be time pressure on this project -- other things being equal we should use the tools which enable the team to be most productive.

_______________________________________________
mozilla-dev-sensorweb mailing list
mozilla-dev-sensorweb@lists.mozilla.org
https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb

[Fabrice Desré]

Hey all,

First, it's clear that the core task (pushing sensor data to the cloud)
is relatively simple and can be implemented with a bunch of different
languages (bash+curl anyone? micropython?).

From an ecosystem point of view, both Rust and Node have more than
enough to offer, so it's hardly a deal breaker, with maybe one
exception: among the things we'll need at some point is crash reporting.
I could not find much for Node itself (though there seem to be something
for Electron, so there's hope). For Rust there's enough interest from
Rust-in-Gecko and Servo to be sure this will happen.

Testability and tooling in general are good for both.

Rust has stable releases every 6 weeks so you don't have to be on the
unstable nightlies. The Rust team takes great care to not break
compatibility between versions and I would actually trust them more on
that point than the Node people.

Team familiarity with the language is also good for both. Maybe Aus
hasn't done that much Rust, and Dave that much JS but does that really
matter? Learning is fun and we'll have to break down tasks (there's more
to do than just the data gathering on device).

It's quite clear that resource usage would be lower with Rust, but I
can't pretend that Node would not run even if we choose a single core
SOC (we got Gecko to run on lower specs than what we'll have for
sensorweb). However, robust system software is exactly what Rust was
designed for. I have no experience with node running unattended 24/7 for
very long periods, but I was running Link 24/7 on a RPi and it was rock
solid.

Also, I think it would be nice to eat our own dogfood and support the
work of the Rust team by showing how usable it is in the IoT space.

It's a personal matter, but I like the "peace of mind" feeling I get
from writing Rust code. I never got that with C, C++ or JS.

So my vote goes to Rust.

On 09/15/2016 04:45 PM, Dylan Oliver wrote:
> Thanks for starting the conversation Aus. Let's have the discussion and
> make our choice by next Wednesday along with our hardware selection.
>
> For me, our familiarity with javascript and the maturity of the node
> ecosystem would make me feel more comfortable going that direction. We
> did use Rust on the metrics team earlier this year and ran into a number
> of speedbumps along the way due to the learning curve and frequent
> language updates. There is going to be time pressure on this project --
> other things being equal we should use the tools which enable the team
> to be most productive.
>
> On Thu, Sep 15, 2016 at 11:20 AM, Aus Lacroix <a...@mozilla.com
> <mailto:a...@mozilla.com>> wrote:
>
> Hi All,
>
> It would seem that the major options that we are considering as far
> as language are Rust and C/C++ but I think that it would be ideal to
> use node.js on device, especially if we're already running linux.
>
> * Node provides TLS support (including TLS sockets!).
> * There is a very robust Hawk module available.
> (https://github.com/hueniverse/hawk

> <https://github.com/hueniverse/hawk>)

> * Node LTS v6 is scheduled for October 1st which would get us a lot
> of the latest and greatest JavaScript features. Will be supported
> for a minimum of 3 years (https://github.com/nodejs/LTS#lts_schedule

> <https://github.com/nodejs/LTS#lts_schedule>).

> * Enables seamless updates of our software package. The sensor could
> check for updates with little to no effort.
> (https://kjur.github.io/jsrsasign/
> <https://kjur.github.io/jsrsasign/> can provide signing and
> authentication of the source, we could also use this library in lieu
> of Hawk, we could also use the built in crypto api --
> https://nodejs.org/dist/latest-v6.x/docs/api/crypto.html

> <https://nodejs.org/dist/latest-v6.x/docs/api/crypto.html>)

> * Has i2c libraries available (https://github.com/kelly/node-i2c

> <https://github.com/kelly/node-i2c>)

> * We all know JavaScript already which will definitely speed up
> development and iterating.
> * It's stable, unlike Rust which changes weekly.
> * If we were hoping for strong type checking, for example, as a
> motivation for Rust, we can use Flow (https://flowtype.org/) to
> provide this in JavaScript. We also have TypeScript

> (https://www.typescriptlang.org/ <https://www.typescriptlang.org/>)

> as an option there.
> * MQTT, if we deem it necessary
> (https://blog.risingstack.com/getting-started-with-nodejs-and-mqtt/

> <https://blog.risingstack.com/getting-started-with-nodejs-and-mqtt/>).

>
> I could list more but I feel I may sounds like a broken record. ;)
> What are the actual, real world advantages, of using rust? Seeing as
> this isn't a high performance device and our hardware options are
> fairly beefy I'm really having trouble convincing myself that it
> makes sense. It think we would not be stacking the odds in our favor
> for a successful launch of this product by using Rust.
>
> --aus
>
> _______________________________________________
> mozilla-dev-sensorweb mailing list

> mozilla-de...@lists.mozilla.org
> <mailto:mozilla-de...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb
> <https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb>
>
>
>
>
> _______________________________________________
> mozilla-dev-sensorweb mailing list
> mozilla-de...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb
>


--
Fabrice Desré
Connected Devices
Mozilla Corporation

[Marcus Cavanaugh]

Stable software can be written in both languages, and as you've all pointed out, they both have a lot to offer. (Node is popular in server-side applications, which need to run 24/7 without crashing. Without going into detail here, I think Node provides ample, clear error-reporting facilities.)

We should choose a language that allows us to express our problem clearly and concisely, without getting bogged down with irrelevant concerns. I feel that with Rust, we would often find ourselves distracted by low-level implementation details (such as fighting the borrow checker when we don't have a need to micromanage memory), causing us to move more slowly and resulting in a less accessible codebase. Supporting the Rust team is a nice gesture, but I also think there's value in facilitating JavaScript as a serious IoT language.

With the caveat that my preferred chunk-of-the-pie would not include sensor-level device software, I think Node would be a wiser choice, especially with our aggressive timeline. I would be interested in hearing Dave's thoughts as well.

[Dave Hylands]

I'm not at all familiar with node, other than to know that its JavaScript.

I was extremely impressed with the stability of the rust code we did for project link.

I think that most of the work for this project will be server side, and there won't be all that much code running device side.

So I'd probably lean more towards rust for device side.