Technically you can have some sort of command in your C++ program to make it fork itself, that is restart itself disk, maybe after freeing non-shareable resources like listening sockets. One could even imagine that this command includes self-recompilation by invoking make (or whatever your build system is).

An alternative is to have your program expose its pid somewhere, and your make file could send a signal to that pid when a new version is ready. The advantage is that if your program crashes on startup, you don't have to do something different to restart it.

If your application has to include an "auto-update" feature (like browsers), use that instead - its certainly better to eat your own dog food. Maybe just hack it a little bit so that you can force a check programmatically (e.g. by sending it a signal) and so that it connects to a local updates server.

It is true that C++ is an overly complicated language; if you don't need maximal performance, you have a lot of AoT languages that are a bit slower ( something around 0.5 C ) but more "user-friendly". In particular, if you are into servers and want fast edit-compile-run loops, Go might be a good choice.

> I've never needed anything to be that fast

In a world where you are billed by ressources used, wouldn’t it be a good idea to have light and fast services that don’t consume those ressources ?

I’ve been wondering this for a time now.

Go will get you 90% there in performance. I recommend that instead of C++ because it compiles fast for that edit-build-refresh cycle. Go also has the benefit of producing static binaries by default which solves a lot of the problems Docker was for.

C++ is more for the extreme control over memory. An optimized C++ server can max out the NIC even on a single core and even with some text generation/parsing along the way.

If you're a ruby user looking for extra performance, try Crystal[1]. Everything you love + types compiled to native binaries. You can set up sentry[2] to autocompile and run every time you save, so the feedback loop is just as tight.

[1]: https://crystal-lang.org/

[2]: https://github.com/samueleaton/sentry

It doesn't have to be C++ of course. The main point of OP lies in C++ being fast and easy to deploy (at least it can be). Go, Rust, to some extend C# and Java also fall in that category. This feature set becomes interesting, because it has the potential to simplify everything around it. If you don't need high fault tolerance you can go a very long way with just a single server, maybe sprinkled with some CDN caching in front if your users are international.

If you do need higher availability you can go the route StackOverflow was famous for for quite some time of having a single ReadWrite master server, a backup master to take over and a few of ReadOnly slave servers, IIRC. With such setups you can ignore all the extra complexities cloud deployments bring with them. And just because such simple setups make it possible to treat servers like pets, doesn't mean they have to be irreproducible undocumented messes.

The other day (actually years) I did a gamejam in Go, I bound Cmd+R to essentially the following:

    system("go build")
    exec("./main")

Not a literal hot code reload that some advanced stuff get to enjoy, but nice enough to shorten the feedback loop.

Working in strongly statically typed languages is quite different, because the types (and the IDE/compiler) guides you. You don't have to hit refresh that often.

Even just working in TypeScript with TSed and a few basic strongly typed concepts (Rust's Result equivalent in TS, Option or Maybe, and typed http request/response, and Promise and JSON.parse) makes a big difference.

A lot less okay, just echo/print/log this object (or look up documentation eew), look at what does this look like and how to transform it into what I need. Instead you do that in the IDE.