[octo_t]

The phrase

> 'What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.'

is beautiful and is a pattern I've seen multiple times before. Its not feature creep per-se, but more something a bit more insidious in software development.

[simias]

That's a good lessons for people wanting to create a new languages too. One of the reasons C++ was successful in the first place is that it needs almost no glue to interface with C code. Contrast that with all the languages providing a more or less cumbersome FFI.

Rust for instance looks very promising but you still have to go through the tedious task of redeclaring all the prototypes of the C functions before you call them, it cannot directly parse C headers (as far as I know). That makes writing hybrid code (for instance incrementally porting code from C into Rust) much more difficult and error prone than they need to be.

[kibwen]

Actually, one of the first tools to appear in the Rust ecosystem was a port of the "bindgen" program written for the Clay language, which has been solving the problem of parsing C headers for years now:

https://github.com/crabtw/rust-bindgen/

There are also long-term plans for adopting this into the compiler itself:

https://github.com/mozilla/rust/issues/2124

[simias]

Ah, thank you, I knew I saw something like that when I looked into rust a while back, but there was no mention of it in the Rust FFI guide[1]. It should definitely be included in the compiler at some point, it's a vital feature IMO.

[1] http://static.rust-lang.org/doc/master/guide-ffi.html

[pjmlp]

Another one is that all successful system programming languages have a OS vendor shipping them on their OS SDK.

That is the only way to make people adopt them. Otherwise they become just another language to do business applications.

[squidi]

I love the irony of the contrast between this article and https://news.ycombinator.com/item?id=7584285. Not that either are wrong, but it demonstrates the constant flux of the software world.

[jeremiep]

There's a world of difference between a web server handling each requests within ~1-30 ms and a game simulating the entire world made from thousands of entities under ~16ms.

It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so. Note that unless you're writing a Gears of Wars, you don't really need such performance and productivity wins once again.

[Guthur]

"It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so."

Sounds definitive, interesting considering that in some cases languages like OCaml outperform C++.

C++ does not mystically provide good performance. Knowledge of algorithms and appropriate data structures are far more beneficial.

Does the coder know how to come up with something like http://en.wikipedia.org/wiki/Fast_inverse_square_root or the cost of a hash map verses indexed array lookup. These will win you far more than any language choice.

[jeremiep]

I completely agree about knowledge of algorithms and data structures being far more important to programming than the choice of language.

Many languages can outperform C++ in some cases and this language it would not be my choice for a next-gen game engine either (D would be).

The thing about going native, however, is that you also control the memory layout of these data structures easily to lower cache miss rates. You can write highly performant code in all the cases where its needed. For a game engine that's very likely to be most of the sub-systems updating the game objects and interfacing with the hardware. Writing native code makes it pretty straightforward once you learn to structure your data for cache locality and prefetch the memory when you know its going to be needed. Video game engines are chock-full of use-cases for this.

I'm mostly a functional programmer now and I do love referential transparency. It's perfect to reason about the logic of our programs and has completely changed how I view software now. But the tradeoff for this is that we lose the ability to easily reason about the execution speed of our programs without deep knowledge on how it gets compiled, and is usually dependent on the compiler vendor.

For real-time applications crunching tens of thousands of objects 60 times a second running sometimes on sub-par hardware written by armies of programmers straight out of Java-School, this makes C++ a no-brainer.

[ksk]

Any specific examples? It would be interesting to go through the commit logs.