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

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

#31

Post by pjmlp » Wed, Dec 16, 2015, 10:52 AM UTC

nickpsecurity wrote: post #26

pcwalton wrote: post #24

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,…

To add my input to pcwalton.

It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage.

The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else.

If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new VSC++ static analyzers, only 1% of the audience said they ever used one.

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

#32

Post by seren » Wed, Dec 16, 2015, 10:59 AM UTC

pjmlp wrote: post #31

nickpsecurity wrote: post #26

Earlier quoted context omitted.

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,…

To add my input to pcwalton. It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage. The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else. If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new…

From what I have seen, the issue is that in big risk-adverse entreprise, the mentality of "don't change anything if it works" goes a bit too far.

I feel a bit ashamed, but to give you some rough idea of the age of the toolchain, the c++ compiler we are using does not even support namespace. We are slowly fazing out old platforms but this is really a long drawn struggle. Basically you have to wait that the underlying HW is not produced anymore for 10 years, before maybe thinking the SW side should be upgraded.

I would be very eager to use some nice feature of Cpp11 but it won't be in this company...

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

#33

Post by gpderetta » Wed, Dec 16, 2015, 11:58 AM UTC

pcwalton wrote: post #29

nickpsecurity wrote: post #26

Earlier quoted context omitted.

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…

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

The OP was talking about JS runtimes and JITs.

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

#34

Post by pjmlp » Wed, Dec 16, 2015, 12:57 PM UTC

seren wrote: post #32

pjmlp wrote: post #31

Earlier quoted context omitted.

To add my input to pcwalton. It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage. The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else. If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new…

From what I have seen, the issue is that in big risk-adverse entreprise, the mentality of "don't change anything if it works" goes a bit too far. I feel a bit ashamed, but to give you some rough idea of the age of the toolchain, the c++ compiler we are using does not even support namespace. We are slowly fazing out old platforms but this is really a long drawn struggle. Basically you have to wait that the underlying…

No reason to be ashamed, I have seen many companies that only use platform SDKs (e.g. aC++ on HP-UX) and IT has the last word over what tools are allowed on dev machines.

However the situation is no different in other languages.

I am aware of some companies still using Java 5 on production, just to cite one example.

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

#35

Post by jbandela1 » Wed, Dec 16, 2015, 1:42 PM UTC

pcwalton wrote: post #24

nickpsecurity wrote: post #19

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.

I agree, that it can be a big deal and one must think about ownership and lifetimes whereas in Javascript there is no need to. Especially in code that will exit the surrounding function before the callback is executed, I do not use &, and explicitly specify the captured variables so I can think about what type of capture.

However, C++ is improving in this regard. I think lambda capture initializers with C++14 help in this regard so that unique_ptr can be used. In addition, the memory safety tooling is improving - see Herb Sutter's CppCon 2015 keynote. Finally, C++17 should have co-routines which will make this type of callback code less used and allow one to use "normal" logic without callbacks that will also be non-blocking.

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

#36

Post by hanez » Wed, Dec 16, 2015, 2:01 PM UTC

timClicks wrote: post #30

hanez wrote: post #13

Earlier quoted context omitted.

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

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

Uh, he ist not a bot, he is not a bot, he is not a bot... :D

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

#37

Post by nickpsecurity » Wed, Dec 16, 2015, 3:00 PM UTC

gpderetta wrote: post #33

pcwalton wrote: post #29

Earlier quoted context omitted.

> 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…

>It is untrue that typical JavaScript applications are vulnerable to anywhere near as many memory safety issues as C++ applications are. Even "modern C++". The OP was talking about JS runtimes and JITs.

Exactly. There's attacks on them posted quite regularly.

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

#38

Post by nickpsecurity » Wed, Dec 16, 2015, 3:01 PM UTC

pjmlp wrote: post #31

nickpsecurity wrote: post #26

Earlier quoted context omitted.

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,…

To add my input to pcwalton. It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage. The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else. If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new…

That is a sad reality. Got tools to get the job done effectively and they collect digital dust.

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

#39

Post by pcwalton » Wed, Dec 16, 2015, 4:38 PM UTC

nickpsecurity wrote: post #37

gpderetta wrote: post #33

Earlier quoted context omitted.

>It is untrue that typical JavaScript applications are vulnerable to anywhere near as many memory safety issues as C++ applications are. Even "modern C++". The OP was talking about JS runtimes and JITs.

Exactly. There's attacks on them posted quite regularly.

Note the emphasis on accidental memory safety violations.

There's an enormous difference between attackers running JavaScript that they control and attackers having to exploit memory safety issues in JavaScript that you wrote. Virtually all attacks against JavaScript JITs have been of the former type, in that they rely on perfectly crafted hostile JavaScript that nobody would write on purpose. But in a node.js type of server side scenario, attackers do not have the ability to run arbitrary JavaScript. They only have the ability to interact with the JavaScript that was already written to be non-malicious. So it's much, much harder for an attacker to exploit memory safety problems in the JS engine in a server side scenario—so much harder, in fact, that I wouldn't be surprised if it's never been done.

If your argument is that JS JITs are hard to write, well, sure. But I think that's totally irrelevant to this conversation. Clang and LLVM are also hard to write and are just as trusted in this scenario.

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

#40

Post by pcwalton » Wed, Dec 16, 2015, 4:43 PM UTC

pjmlp wrote: post #31

nickpsecurity wrote: post #26

Earlier quoted context omitted.

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,…

To add my input to pcwalton. It is true that modern C++ with the proper tools can mitigate many of the issues that come from C heritage. The sad reality is that despite the tools that C++ offers for memory safety, the majority of enterprise developers don't buy into them and the code looks more like C with classes than anything else. If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new…

> If you look at CppCon 2015 when Herb was presenting the Core Guidelines and the new VSC++ static analyzers, only 1% of the audience said they ever used one.

That's interesting.

It's especially interesting to note that those static analyzers work on unmodified code! The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations…