Live data from Hacker News

IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

github.com

21–30 of 45 posts

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#21
post #17
post #11

Earlier quoted context omitted.

I believe to get this production ready will take some years. From what I understand in the projects FAQ page they want to implement the concept of a Unikernel and this is what the Rump Kernel at http://rumpkernel.org/ is intending too. May I am wrong because I am not to deep into it. If it is a research project then they should go on... It looks like it is because it is beeing developed at a university in Oslo, Norwa…

No, a rump kernel is not an unikernel, check the FAQ linked from http://rumpkernel.org/ However, you can use rump kernels as a major component of a unikernel implementation. A rump kernel provides environment-agnostic drivers, meaning you can integrate them pretty much anywhere. Now, what is a unikernel? From my perspective it's essentially: 1) application 2) config/orchestration 3) drivers 4) nibbly "OS" bits So fro…

That clarified the difference! Thank you.

I think I mixed rump kernel and rumprun. I saw a talk long time ago and am not very deep into that nowadays.

Therefore, double thanks!

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#22

Earlier quoted context omitted.

This seems more like MirageOS/Ling than a rumpkernel. From what I remember, rumpkernels are more general, at the cost of being less "unikernel-y" (i.e. lean and fast). I agree that it would be easier and faster to use a rumpkernel if the intention is use in production soon . I can't tell if this is a research project, or intended to be production quality at some point.

>I can't tell if this is a research project, or intended to be production quality at some point. Found this on their website [1]: >IncludeOS is the result of a research project at Oslo and Akershus University College of Applied Science (hioa.no) >IncludeOS is not production ready - but we're working hard to become so. [1]: http://www.includeos.org/

Thanks, I didn't catch that. I'll have to make some time to play with this, especially once it gets further along.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#23
post #8

I like this idea, but I don't understand describing it as "node.js-style". I guess they think of Node as being a particularly ideal platform for implementing "microservices", but honestly I don't think there's any particular property of Node.js itself that makes it microservice-friendly. To me "Node.js" simply means "server-side Javascript", which obviously this isn't (it's C++).

ASP has had server-side "Javascript" for years. The magic sauce in Node.js is the combination of async, JS, and package management.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#24
post #3

I wrote something similar a while ago, combining the easy-to-use asynchronous programming model of Node.js with the speed of C++. http://gladdy.github.io/c++/2015/07/26/NodeDemystified-pt1.h... source code: https://github.com/Gladdy/Mininode

The example looks really clean. Amazing how far modern C++ has gotten in that area.

Losing memory safety is a pretty big deal though.

In particular, the capturing semantics with [&] are going to result in a big surprise (use after free) if you try to close over and capture variables like you do with node.js.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#25
I never been fun of Node.js (neither the hype of writting server-side in awful JS), so sometime ago I've written https://github.com/alfanick/rest-cpp - "tiny Rails-style web services in highly efficient C++" ;) Code has not been updating for some time, but it is near production-ready.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#26

Earlier quoted context omitted.

The example looks really clean. Amazing how far modern C++ has gotten in that area.

Losing memory safety is a pretty big deal though. In particular, the capturing semantics with [&] are going to result in a big surprise (use after free) if you try to close over and capture variables like you do with node.js.

Got no expertise there. I always assume it with C or anything derived from it. But C++ commenters here keep telling me modern C++ and its libraries have all kinds of ways to prevent common issues with memory. They've demonstrated a few. So, I'd be curious to see a comparison of what happened in practice between the two.

That said, typical C++ applications might be easier to get right than Javascript runtimes, JIT's, or whatever. A lot of eyes go into the JS foundations but so do a lot of complexity and problems.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#29

Earlier quoted context omitted.

Losing memory safety is a pretty big deal though. In particular, the capturing semantics with [&] are going to result in a big surprise (use after free) if you try to close over and capture variables like you do with node.js.

Got no expertise there. I always assume it with C or anything derived from it. But C++ commenters here keep telling me modern C++ and its libraries have all kinds of ways to prevent common issues with memory. They've demonstrated a few. So, I'd be curious to see a comparison of what happened in practice between the two. That said, typical C++ applications might be easier to get right than Javascript runtimes, JIT's,…

> That said, typical C++ applications might be easier to get right than Javascript runtimes, JIT's, or whatever. A lot of eyes go into the JS foundations but so do a lot of complexity and problems.

It is untrue that typical JavaScript applications are vulnerable to anywhere near as many memory safety issues as C++ applications are. Even "modern C++".

As a very relevant example, closures are modern C++, but neglecting the right annotation on the capture clause—the difference between writing one ampersand and not—can lead to use-after-free. In JavaScript, the runtime will manage the lifetimes of the closed-over variables for you, and you can't get it wrong unless there's a bug in the JS engine. Accidental use-after-free due to JS implementation bugs is so rare that I wouldn't be surprised if it's never happened in practice.

Re: IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++

#30
post #13

Earlier quoted context omitted.

There is actually an active unikernel project called IncludeOS ( http://www.includeos.org/ ), which could be a good place to start.

Exactly this is what the original post is about... ;)

Urgh, completely thought that the name was clobbered by a second project. Silly me.
Post reply on HN