Hacker News new | past | comments | ask | show | jobs | submit login
Moving Fast on Hardware with io.js (tessel.io)
66 points by tiles on March 12, 2015 | hide | past | favorite | 19 comments



<<we had built a custom minimal runtime that “transpiles” JavaScript code to Lua and runs that Lua code on a Lua VM.>>

What's the point? Why not just write Lua instead of JavaScript? It's a better language anyway. This 'JavaScript everywhere' fad is just pandering to people who are too lazy to learn another language.


Because the group they are "pandering" to is huge. What you're asking is "why would a company looking to sell a product use a hugely popular platform to do so, when there's a much better, little known and barely understood platform available?".

One man's "pandering" is another man's "responding to the market".


Did you read the article? It's about how there isn't a Lua VM anymore on the new hardware


Did I read the article I quoted from? Yes. "Anymore" is the key word. I'm questioning the need to have JavaScript at all when they started out with a perfectly good language. Their problem wasn't that there was anything wrong with Lua; the problem was in transpiling JavaScript to it.


Don't have time != lazy, but that's a different argument. One of the cool things on this new one is it runs Rust, arguably the best language for this purpose, so you don't have to use JavaScript if you think it's stupid


What do you mean by "runs Rust"? Rust compiles to native code. The old one could run Rust code too.


Rust will be supported by the tools the same way JS is. `tessel push` will run the cross compiler, and Rust libraries will be provided to access the hardware and modules.

Yes, you can get to the underlying Linux system and run anything you want (including Lua), but the point is to abstract away the OS so you only have to think about your code and the hardware.


If you're going to make comparisons, you need to compare the ecosystems and not simply focus on specific details. Focus on being clever at the system level, not on the line of code level, and you will be considered great.

Lua's ecosystem is nowhere near as mature as JavaScript's.


Genuine question. What makes Lua a better language than JavaScript?


Native coroutines & LuaJIT? Not sure, the languages aren't really better or worse than each other. Lua has no libraries so it's irrelevant.


Also, 1 indexed arrays which offend some people.


I'm hoping the server that stashes binary builds will be accessible to not just Tessel users but everyone who is running Node on a MIPS architecture (for example, wrtNodes).


It seems io.js is taking over. This doesn't happen often, but it has happened before, with Mambo and Joomla, and Hudson and Jenkins. I expect it will happen more often as open source projects mature and the goals of the community diverge from the goals of the organizations that own the trademarks.


I think there has been some talk about reconciling the two projects though...

http://readwrite.com/2015/02/27/node-js-io-js-reconciliation...


I'm aware of that. I think it's unlikely to happen.


It's interesting how power, not compute, has become the new limiting factor in what developers can do.


It seems like high powered devices are becoming almost as cheap as low power devices, almost purely as an artifact of the rise in mobile sales. So, to your point, the thought process of which microcontroller/microprocessor to pick lies almost solely in whether or not it's connected to wall power.


I'm ridiculously excited about this. The original tessel was an amazing step away from the dichotomy of Arduino | Embedded Linux, allowing you to focus on what makes your project different instead of fiddling with breadboards or operating systems. Sound familiar, Rails / Django devs?

The coolest thing is that it's a fairly modular product, instead of being some custom monolith that tries to solve every problem for you. It hooks into npm and the command line, and runs JavaScript.

Unfortunately, the Tessel1 ran Colony, a custom implementation, which didn't do well with things like Bluebird promises (Q promises worked, but slowly) or generators or observables. Most hardware projects are actually reactive systems, and those are difficult to build with an Arduino. Coordinating callbacks is very painful.

I can't wait to get my hands on a Tessel2. Hardware has been needlessly hard for too long. Glad to see hardware hackers adopting more hard-won solutions from the past 6 decades of software engineering.


Excited about this!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: