Tessel, a NodeJS-based microcontroller | Hacker News Reader

Tessel, a NodeJS-based microcontroller

dragoninnovation.com

54 pointsbpierre41 comments

I don't understand this craze to use JS everywhere. It's not the best language for every job. The main argument seems to be 'if you know JS you can use it in product X'. If you're not competent enough to learn another language then are you competent to write good enough JS?

I think it's fine for rapid prototyping. It has WiFi and is positioned for internet-connected stuff. There are lots of people who use node.js and packages from npm to interface with internet services, so this gives them an easy way into working with an embedded device without a large learning curve.

There are lots of Python libraries too, and PIP. This wasn't necessarily a dig at just this platform but the general principle of re-inventing multiple wheels, except this time with JS.

Python can run on a microcontroller too[1], do you think that's a bad as well? I can't figure out what your criticism is: that they choose not-C or that they specifically choose JavaScript?

[1]https://wiki.python.org/moin/PyMite

I think in this case there are a few reasons:

1) Node.js has a huge ecosystem and it's easy to use

2) JavaScript is known by many

3) JavaScript may not even come close to being a proper language for hardware programming but it is good enough for these kind of devices

Also, the event loop seems work well with these fun hardware projects

You can have event loop in any language that has enough access to underlying OS facilities (select/poll/epoll/kqueue) out there. Can't name a non-esoteric language where you can't off the top of my head.

It's not just a theoretical question about whether a particular language is capable of supporting an efficient event loop. It's also a significantly practical question about whether there are a large number of libraries and community experience built up around programs organized this way.

This is also one of the big reasons why the people who wrote node.js picked JavaScript in the first place [0].

[0] http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf

Any reason large number of libraries should even know about they're using evented/async IO? I believe most of them consist of purely sequential actions (say, "connect then send then receive then process then return") and gain no benefit from non-blocking (function-wise, not program-wise) IO. If the core is smart enough to run them as coroutines (for example see Python's gevent.monkey) that yield back to event loop on waiting for IO, they'll automagically do the right thing without being infested with CPS callback ladder hell.

> Node.js has a huge ecosystem

So do many other platforms.

> JavaScript is known by many

So are many other languages.

> JavaScript [...] is good enough for these kind of devices

So are many other languages.

The question, as I got it, was "why JavaScript is chosen among many possibly alternatives?". Your comment does not answer it, I believe.

Even if you used the same argument for all my points, the intersection of the result sets seems to be empty.

To be more clear, AFAIK, no other platform accomplishes those three goals as good as JavaScript. Maybe Python? GitHub language stats used to say otherwise (until they removed them). I also have the impression that as far as dynamically typed languages go, JavaScript is one of the most optimized ones. Well, Lua and some others beat it on speed but they are not as popular and/or provide what node.js provides.

Many embedded projects these days do command and control via a small web server. So you've likely got a fair amount of JavaScript in your project anyways. The rest is often written in a combination of c and Lua. Lua might be a better language than JavaScript in isolation, but it might be better to avoid the cost of context switching your brain several times a day.

Tessel actually transpiles JavaScript into Lua, which is what is actually running on the device.

That's cool. Do you know what library they use to do the translation?

I don't, but their FAQ says that they will be open-sourcing their code and hardware.

Oh, way cool. Did you build the transpiler in-house?

I don't work for them, I just read the FAQ at the bottom of TFA:

  | What's running JavaScript under the hood?
  | We're currently running a custom-built, real time operating
  | system on top of a Lua Runtime. Your JavaScript is compiled
  | to Lua bytecode when you push your code, and that bytecode
  | is run on the runtime. It's this runtime that allows us to
  | have such low memory overhead. We may switch over to an
  | implementation of Libuv or a microLinux flavor in the future,
  | but that shouldn't change anything about the user experience
  | with Tessel (except it will be faster!)

In that case they've buried the lede, as this is arguably more noteworthy than the microcontroller. Has anyone done a production-worthy JS-to-Lua compiler before? The idea has come up many times because the two languages are so similar. But I've not seen anything as complete as what they must have if they're running Node. (What about the non-JS parts of Node? Can those just be handled with a standard compiler?)

JS-to-Lua might not be well-suited to this sort of platform, since it is so easy to just write Lua instead. But it would be useful if you want to get existing JS code running on new hardware, or if you want your program to be able to run in a web browser as well.

The community is one of the best development communities out there. Node + NPM have created an ecosystem with lots of contemporary tools that fall in line very well with the UNIX Philosophy. The few people that I've shown Node to have been surprised about how easy it is to use NPM and tackle dependency management.

> If you're not competent enough to learn another language then are you competent to write good enough JS?

I used to say that about Java Developers that didn't know C/C++. As I've grown, the thing I've realized is that the end user/customer/client doesn't care what you write your application in (Unless you're on a Government contract). They care if it works.

JavaScript is built around events and the event loop in a way that few languages are, which makes it well-suited to a hardware environment like this.

Not really? Javascript interpreters, and the DOM tend to be (and Javascript interpreters only are because they're geared towards being embedded in browsers, primarily). The language isn't any better for it than any other language that supports closures, though.

> The language isn't any better for it than any other language that supports closures

Which puts it pretty high up to begin with. Factor in the number of libraries that assume an event loop (all of them that care either way) and that are asynchronous by default because of this (most of them) and it becomes pretty hard to beat.

Also, this is not just a property of the language itself, it's a property of the ecosystem built around the language.

It's not strictly NodeJS based - According to their site it runs on top of Lua...

There's also another JavaScript microcontroller crowdfunding at the moment: http://www.kickstarter.com/projects/48651611/espruino-javasc...

AFAICT the Espruino and Tessel are slightly different. The Espruino's focus seems to be providing an ultracompact, low-power, very simple JS-powered Arduino, which (with physical adapter) could be used with existing Arduino shields. The Tessel seems to be focused more on the interfacing-with-the-internet side of things, with built-in wifi.

I think there's plenty of room for both, and it's exciting to see continued efforts towards making it easier to bridge the gap between embedded devices and the software world!

For the price, I still think that most developers are better off buying a BeagleBone Black for $45MSRP which can run a flavor of nix. The default "IDE" it ships with is cloud9, and has js libraries to control the pinouts, etc. JS fans can use this happily, or you can put nix on it, and just install Node.

I agree. Even the default distro that the BeagleBone comes with (Angstrom linux) has Node preloaded onto it, out of the box. And the power that thing offers for $45 seems almost impossible to beat.

The question I have for this is, why not just use Node with Firmata on an Arduino? Anyone give me the apparent weakness of that setup that makes this more preferrable?

I've played with Arduino and the #1 complaint I have about it is that in order to do anything I have to learn a whole lot about electronics. With Tessel you just plug a new module and npm install and you're good to go.

See relevant discussion here: https://news.ycombinator.com/item?id=6214553

Is there any information on when it's shipping? Read through the crowdfunding site a few times, but might have just glanced over it.

February 2014.

Isn't it a bit too expensive? I think it is, especially when considering the competition (Arduino).

I really wanted to back this one but I cannot justify paying $99+. Instead of one of these I bought one of these

http://www.kickstarter.com/projects/48651611/espruino-javasc...

and one of these

http://www.kickstarter.com/projects/2021474419/flutter-20-wi...

Yeah, I'm also getting an Espruino. I'm living in Germany so, I can't get the Flutter yet - I'm dying to get my hands on a pair though.

I think you aren't taking into consideration the differences between this and the competition. The Tessel is intended to be a powerhouse right out of the box. For example, 160MHz compared to <20MHz, and 32MB of flash and RAM compared to 32-256kB.

You can achieve the same level of flexibility and more with arduino + raspberry pi, put together in a custom case. It still doesn't cost that much. I really wanted to play with this, but I find it too expensive for having it just to play with it.

The difference I see with Tessel is that you require less learning electronics and you're right away capable of programming modules just after you plug them in. To me that has considerable value.

Well now that just ruins the fun of programming on a microcontroller. I like my little Arduino and Teensies because its low level programming, bare metal programming.

https://twitter.com/shit_hn_says/status/234856345579446272

Sources tell me that the Arduino will continue to exist and continue to run C programs.

Reply on news.ycombinator.com