plexchat

Yes because the code emitted by a compiler is directly proportional to the size of the specification? I fail to see the point.

Source? I've never had an issue compiling legacy code.

Old news. See https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...

It's somewhat analogous to how we went from 16 bit registers to 32 bit registers with the extended opcode variants, so if you understand x86, x86_64 isn't really much of a stretch.

I hate to be a naysayer because this is great work and all, but frankly, managing all these platforms is going to be a nightmare. In a traditional engine, the code for each platform is embedded at the lowest level of abstraction. That is the way it works for iOS and android at the moment, but adding new platform support via extensions will make the code harder to manage and reason about. I don't want a separate extension for OSX, Windows, and Linux. I want all the code about, say, filesystem handling to be in a single place (in neatly separated platform specific files). This applies to networking code, rendering, input, etc. I know at the bottom of the article there is hope of integrating it with the original project, but given that we are starting literally on the opposite end of the spectrum, I'm worried we will never reach this hypothetical nirvana. The original react native team needs to prioritize getting other platforms in the original codebase, and I may be mistaken, but I have not yet observed this, and so have some cause to worry.

I think these are salient points. Part of my rationale for writing it the way I did is that howistart is slightly editorial in nature and is a collection of opinionated overviews of a professional workflow by design. In the real world, C++ is never used in vacuum (since its runtime is a very thin layer on top of the operating system). Also, C++ is generally chosen because it compiles on many platforms, and awareness of meta-make systems and how executables are structured and run is important in a professional working environment.

This is why I make it clear at the beginning that the article isn't meant to be an introduction to the language (non-goal!) and also point out references for a beginner to learn from later. I also mention that learning a single IDE first and learning it well is a good idea.

The speed of the GC isn't the issue (although it certainly can be). The non-determinism is. It's hard to control when a GC should happen, and when it happens at a bad time, the ramifications are perceived as an awful user-experience.

Other languages, not all other languages ^^. Yes of course there are several languages that map more directly to one's mental model of how code is executed. Rust (which you're working on) is an one such exception. Optimizations are certainly aggressive but the micro-optimizations are usually either well known (like NRVO, loop unrolling, function inlining), or not important relative to more costly operations that are occurring (allocations of heap memory, fetching from the heap, executing a system call, acquiring a mutex, etc).

At PlexChat[1], we intend on using C++ to write a lot of our infrastructure (where it makes sense, that is). The language has advanced significantly in the last decade and writing idiomatically correct, and safe code, is much easier than it used to be.[2]

Garbage collection is certainly a part of it, but really, it's about programming with a deterministic runtime. Controlling memory budgets and doing things described in this talk is possible in an environment where the programmer has control, but instrumenting a blackbox runtime to identify performance bottlenecks and pain-points can be a huge endeavor. Other languages optimize understandability of the programming semantics (what is this algorithm doing) but do very little to aid in expressing runtime semantics (how will this algorithm execute on the machine).

[1] http://plexchat.com [2] https://www.jetbrains.com/cpp-today-oreilly/books/Cplusplus_...