> Many would love a better language. Matter of fact, they tell us in Rust threads here.

Absolutely, but my emphasis was on the difference between "love" or "want", and "need". Switching a programming language is extremely expensive, doubly so in systems programming. Organizations won't pay the price for something that doesn't make a big impact. Unlike many other new languages, Rust does have the potential to make a big, bottom-line impact, but that impact is almost entirely due to safety.

> They might benefit if the app is aiming for max performance (esp HPC), memory efficiency (eg embedded), or minimal latency

I don't think max performance is an issue at all, nor even minimal latency where you need it (there are realtime GCs, and GC languages do support arena GC allocation in embedded and realtime settings, like realtime Java), but definitely it's a big gain in memory efficiency.

But again, I said they could benefit. It's just that the main focus shouldn't be on those that would benefit, but on those for whom the language is indispensable, or tremendously beneficial.

> I think Rust might have good, network effects if it takes off.

Absolutely, it's just that if you want Rust to really have an impact rather than just be popular, you need that network effect to be in the right network, and for systems programming, that network is not well represented on HN and Reddit. While these venues are good for marketing, and while the message will get to some of the most important crowd, it may have a negative effect as it would attract many that don't really need Rust, and if they end up making up most of the community, they may slowly push the language in directions that may make it less appealing to those who really need it.

"I don't think max performance is an issue at all"

I'll consider believing that when you remove both the performance-enhancing aspects and their marketing from your company's products that appear to target enterprise space of people using GC's and concurrency. Rust's safety w/out performance hit affects those two, specific areas. I think they might be interested.

Not to mention businesses doing analysis they want to happen faster, game developers, real-time groups wanting no runtime (or close to it), HPC that definitely cares about max performance, and small (or cloud) companies like those switching from Python to Go specifically due to lower costs from higher performance. Maxing performance is always a benefit if you can tell them it saves time or money but comes with the tools essentially free. That's actually how a lot of better JVM's (esp AOT) were sold.

"(there are realtime GCs, and GC languages do support arena GC allocation in embedded and realtime settings, like realtime Java)"

They're not default in these GC languages. We both know about them but most people don't. I've been telling Java & C# developers about those things for years with not one ever having heard of it before. Recently explaining to people that think an OS can't be written in Go that both OS's w/ GC languages & real-time, concurrent GC's existed. So, in their minds, there's horrid C/C++ w/ no safety, all these languages with GC's that have GC issues, and now a safe language with no GC. It's a perception thing that gives Rust an advantage over tech you described.

" but on those for whom the language is indispensable, or tremendously beneficial."

I'll cede you that. This would almost solely be aimed at the C, C++, Objective-C, and Fortran crowds. People stuck with caveman tools and unsafety.

"and for systems programming, that network is not well represented on HN and Reddit."

Definitely true.

"end up making up most of the community, they may slowly push the language in directions that may make it less appealing to those who really need it."

This is a real risk they should consider more. The best route would probably be to send people to the sites, conferences, and companies heavily into C and C++ for many use-cases. Get all this feedback they're getting from them at least as much as the others if not more. That might inform the language design in a way that addresses the risk you're bringing up.

> Rust's safety w/out performance hit affects those two, specific areas. I think they might be interested.

:) Let me put it this way: if for some reason Rust ever takes a serious market share from Java (or other similar languages) in the enterprise space, I will surely be well into my retirement by then, so my interest isn't financial. I was a C++ developer for many years, working on very large soft (and some hard) realtime systems, and I was a Java holdout, but once most of the defense industry switched, virtually nobody (including us) ever complained about a performance decrease. So even if the claim that GCs adversely affect performance in large, complex programs (where RAM overhead isn't an issue) were true, the number of organizations that build software of that kind and where this performance would matter more than in defense, is very, very small (not to mention that most of the current performance deficiencies in Java are not related to GC). If that's the kind of user that would be a significant portion of Rust's userbase, then Rust is in trouble. Companies that sell ultra-low latency GCs for a fraction of the cost it would take for enterprise shops to adopt a language like Rust, are, well not exactly on their way to the Fortune 500. The systems software space -- drivers, kernels, filesystems, and the entire embedded space -- is at least one, if not two, orders of magnitude bigger.

I wasn't saying you were shilling to dodge competition so much as better performance is in your marketing material like many others. ;) I agree that a lot of the space they should be targeting won't have a humongous difference between a well-tuned GC and a typical, native implementation. You're right on that.

"Companies that sell ultra-low latency GCs for a fraction of the cost it would take for enterprise shops to adopt a language like Rust, are, well not exactly on their way to the Fortune 500"

That's a good point. Switching costs would be huge in many of these organizations. They'll make better inroads with something within their existing stack (typical) or doing new projects in the improved language (also typical). They're not rewriting all that stuff, though.

With rust you don't need to rewrite though. Just integrate it a little at a time.

Hopefully. With the legacy codebases or preferences, that means hiring people that really know C or C++, training them for Rust, and maintaining two codebases in one. It becomes trickier. Hopefully the incremental option works well for Rust but it didn't with most languages & platforms.