I love building a startup in Rust but wouldn't pick it again

I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docker, there's not much difference between a JVM app and any other kind.

Your comment is super interesting, don't let me sound like I'm trying to shoot it down. I'm being deliberately terse to avoid creating receptors for language war antigens to bind to.

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap", Jupyter notebooks, and in many other domains, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and without the plumbing libraries none of the higher-level applications can function.

[1]: https://github.com/pyca/cryptography

> want back ends that can interoperate with those front ends.

You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

> I’d love to use C# without having to deal with distributing the runtime, so I’d like to hear more!

In the later versions of DotNet there are a couple of common ways to distribute (I'd suggest either DotNet 6 [LTS] or preferably DotNet 7 [current]).

You'd usually use the dotnet publish command, which ideally produces one of three things, all of which are self-contained and can be deployed to a clean server without any framework. Ordered by worst-first (in relation to your requirement):

1. The halfway house from dotnet publish is a folder with your app/site/api alongside all the dlls needed from the standard library and/or nuget. This is a standalone folder, though messy.

2. With an extra couple of options on the dotnet publish command you get it all as a single binary which is exactly what you say: a big executable.

3. There is another option available on the dotnet publish command which will use magic (probably tree-shaking but I can't remember) to produce a smaller single binary by removing unused code.

As an aside, it's also worth noting a couple of extra points:

* The dotnet publish command can cross-compile ready-to-deploy outputs for any supported platform (eg Mac or Linux, using x86, AMD64, or ARM64) just by specifying the combination of platform and CPU as command line options.

* Within C# you can mark your assets as embedded resources (like an embed FS in Go) and they will also be included in your output.

The final result varies in size depending upon what your code does (and hence included libraries), and some code (eg reflection) may interfere with the tree-shaking (or whatever) of option 3 - but it warns you whilst it generates the output, and you can either ignore it or use option 2.

Generally speaking the option 3 builds are between 1.5 and 2 times the size of a Go one, but you're looking about 20MB to 30MB for useful stuff. Not tiny, but still quite small these days. Option 2 builds probably double.

In use (and this is subjective) they consume a bit more memory than Go, but seem more consistent/stable in that usage.

Also note that within that 20MB-30MB build, for an api or a website you get a built-in web server that can sit behind nginx etc as usual, but is also good enough to expose directly.

I think it's dismissive and overly simplistic to say that Rust is almost always a better option than C or C++. They're different languages with different strengths.

One strength of C++ is that it is far more established than rust - and that comes with a lot of advantages:

* It has a larger number of people who know how to work with it

* It has a huge catalog of established, fully functional libraries for everything you could imagine from UI to game development to embedded systems to simulation to anything else

* It has broad support in developer toolsets in general like editors and IDEs, static analysis tools, formatters, pre-commit hooks, etc

If I'm starting a new project with C++, I can immediately know that there's a huge landscape of programming already carved up and ready to work with. I can't do that as easily in Rust. The language, the libraries, the tools are all younger. Some of it isn't as fully featured, some of it isn't nearly as stable.

That will improve with time, but it's a huge advantage to C++ right now.