We Built a C++ Rendering Engine for the Web (opens in new tab)

What's so wrong with POSIX sockets? It's maybe not an elegant API, but not because "it's designed for C". It's problems are for example 1) it's doing too much abstraction (sockets). 2) you have to deal with some arcane data structures and ancient formats (endian conversions).

But, it does its job well enough: allowing the user to send and receive packets from the network.

If you're writing a networked application that works, chances are you either don't give a sh*t what API to use as long as it lets you send and receive packets (and thus you go with the relatively portable POSIX sockets (at least for Linux / WinSock2 on Windows)), or you use a lower-level API (probably proprietary) to reduce syscall overhead / get more control.

If you're parsing text, chances are all you need is fread() to read in the next chunk from a file, and from this you'll build a "next_byte()" function and then a "next_token()" function on top.

(I've done a lot of network code as well as parsing code, and the I/O API is among the least of my concerns).

All these fancy bottom-up kitchen sink libraries implementing "proper abstractions" or whatever do not provide any value past being able to be combined to form barely working and un-fixable applications where you will pull your hair out when you actually need some control over what's happening.

For something better, you'll need exactly this from external libraries: a clean programmatic (function call) interface that gives you control at a reasonable level of abstraction.

> which is no more at risk of buffer overflow attacks than vanilla javascript.

This is quite wrong, a Wasm program can overflow internal buffers due to a missing bounds check and access unrelated data as a result. See HEARTBLEED for a case where this created a very real vulnerability. The Wasm safe sandbox only protects the boundary with the rest of the system.

> "Simply down-voting without adding a reply why you disagree with an opinion does not really help."

This looks like a general criticism of using C++ which has nothing to do with the topic of this post. You're free to criticize, but this criticism alone brings absolutely nothing constructive to the conversation and only serves to incite more useless "have you considered writing this in Rust?" conversations. You're not even suggesting what you think they should've used instead.

> "I have been interested in security for a long time"

Here's a tip for you then: security is not an absolute, and things usually aren't as black or white as you might think. Take a moment to consider the fact that C++ is one of only a small handful of languages with which everything around you has been built for the last 30+ years. Do you know something all of those other engineers don't already know? Otherwise, humility goes a long way.

According to the article, the C++ code is compiled via Emscripten (presumably to WASM, or maybe to asm.js), so it's running sandboxed either in the WASM or JS runtime. Any potential memory corruption caused by unsafe C++ code is contained within the sandbox (which is the whole point of JS and WASM really).

The security implications are exactly the same as writing the code in any other language (incuding Javascript or Rust). If the sandbox is buggy, then a "safe" language wouldn't help either.

Well, you're not starting of to great by randomly claiming that it's a security issue that it's written in C++. It's not really productive. A lot of software is, for better or worse, written in C or C++, that's not going to change.

For years people have been yelling: "It's broken because it's written in C/C++". That same "attacks" was made to promote Java 20 years ago.

Sure, maybe they could have picked a memory safe language, but they didn't. Perhaps because they know C++ and doing the same project in a language they're just learning would result in a ton of other bugs. They even write that they hired a few brilliant C++ programmers, so chances are that they know how to safely handle memory in C++.

I disagree with the commenters who are saying your comment was just "C++ bad". The point I took from your comment is that this particular class of application, which is parsing many complex formats from external sources, several of which probably have extensive warts and edge cases, and rendering the output to a browser, is the type of application may be the most vulnerable to the downsides of C++ when it comes to security.

I think it's a reasonable point, and a step or two above "just use Rust".

You're not trying to have a discussion, your post is essentially 'why didn't they use Rust'. Sadly predictable.

There is no-one on HN who doesn't know that C++ has historic memory management difficulties.

you suspect wrong. I've written Photoshop readers since 1993. They all still work. Photoshop has never broken their format

If I remember correctly, PSD files have an optional header (when files are saved in "Compatibility Mode", which I think is the default) in which is encoded the rasterized image. It's then "easy" to display the image, but very difficult to edit it, as you then need to implement the whole renderer.