>not just tar it by association with C++.

To build on this and your last paragraph: I think it's arguably a feature of Rust that it combines:

- A syntax that's highly familiar to the legions of C++ programmers already out there

- A bunch of features C++ has had in the works but that aren't quite there yet (specifically, a proper module system comes to mind)

- Features from ML/OCaml/Haskell, like a first-class option type, first-class (powerful) pattern matching, and an emphasis on immutable-by-default variables

Having this without the cruft of the decades of backwards-compatibility that C++ has had (not without good reason, granted) makes Rust the hard refresh of C++ that I and hopefully others have been waiting for for a while.

.NET has these features for decades. It compiles really fast, much easier to use than C++, and has awesome IDEs.

C interop is pretty much same as in Rust.

GC is not an issue in modern .NET even for resource-demanding apps running on slow ARM CPUs. Here's an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo BTW it consumes non-trivial amount of C APIs like V4L2, ALSA, and audio decoders.

The reasons .NET never really competed with C# for the longest time were a handful:

- First-party support for .NET only existed on Windows systems until 2015ish with the release of Rosetta

- Third party support across platforms via Mono never really picked up steam for a number of reasons

- Early on, .NET code, much like JVM code, wasn't in the same league as C++ in terms of performance

- I'd like to be proven wrong on this one, but .NET remains a poor framework to do systems programming in. GC is IMO still a factor because even though modern M&S GCs are impressively performant they still add a degree of unpredictability to your runtime, and sometimes that's not acceptable — so reference counting or something even more basic is preferred, if only for the consistency.

> .NET remains a poor framework to do systems programming in

Have you clicked that link? Essentially, I’ve re-implemented parts of ffmpeg’s libavformat and libavcodec in C#. On Raspberry Pi, the software uses 15% of CPU time while playing 12 mbit/sec 1080p video, on par with VLC, while using 20% less RAM than VLC. If that’s not a system programming, then what is?

BTW, I don’t think I allocate any objects on heap while playing the video, therefore no GC is involved, and no degree of unpredictability is introduced. Wasn’t hard at all, just recycling buffers between frames.

Object recycling often works fine to avoid GC issues for simple stuff, but in more complicated applications you really do need to dynamically allocate and free memory and GC is going to get involved.

> for simple stuff, but in more complicated applications

Media engine part of the library has 45k lines of code, this is mostly due to the complexity of V4L2 API, and of the MKV and Mpeg4 containers. I wouldn’t call that “simple stuff”.

> you really do need to dynamically allocate and free memory

Memory allocation in .NET ain’t limited to GC.

First of all there’s stack. I use Spans + stackalloc in quite a few places there. Modern .NET even has these `ref structs` where the compiler guarantees they are never accidentally boxed into the heap.

Another thing, no one stops you from using malloc/free, like I did in that class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud...

Finally, the mere presence of GC doesn’t affect performance in any way, only usage of GC does. Even for latency-sensitive applications like that media engine it’s OK to allocate stuff on managed heap, as long as it only happens on startup, or otherwise rarely. I allocate quite a lot of stuff on the heap, megabytes, when opening a media file.

Funny, before your comment showed up, I was actually going to edit in an addendum to link to

https://robert.ocallahan.org/2018/10/the-costs-of-programmin...

... to pair with the mbeddr link.

You seem to be at a place where you think of Rust as already entrenched, but I'm at a place where I still see Rust as a proposition—one that could lead to that place, or not if we think better and nix it (following the reasoning above).

I don't think Rust is going away. You may not like it; it may not be adopted by the Linux kernel. But it is widely used in real codebases (including, say, Firefox). It's not brand new. And the article linked above discourages creating new languages; valid or not, that horse is well out of the barn.

The post as written, and whether intended or not (admittedly by current signs, I guess it'd be foolish to wager anything other than "not"), ends with an observation that's still highly relevant here but that you're neglecting to account for.

> I hope people consider carefully the social costs of creating a new programming language especially if it becomes popular, and understand that in some cases creating a popular new language could actually be irresponsible.

And being widely used is not the same thing as being entrenched, not the same thing as being unable to say, "nice prototype; let's wrap this up now and do it for real this time".

> ends with an observation that's still highly relevant here but that you're neglecting to account for.

No, that's kind of the sentence I was responding to. Rust is already popular; that horse is out of the barn.

> And being widely used is not the same thing as being entrenched, not the same thing as being unable to say, "nice prototype; let's wrap this up now and do it for real this time".

I don't care to argue about the first clause, but I don't understand how you can argue the latter. Who is going to say "nice prototype; let's discard this?" Do you expect the Rust-using projects to just fold? Do you expect Rust developers to just disappear? Again, it sounds like you don't like Rust, which is fine, but as someone external to the community, why do you think anyone would listen to you about spinning down Rust?

As someone who's spent the last few years writing a 170K line Rust project ... I consider it entrenched!

I stand by that blog post, though I recognise it's controversial. I think Rust clearly qualifies as "worth the cost of a new language". There simply wasn't, and still isn't, any other serious contender for safe GC-free systems programming. New contenders will arise but in the meantime lots of projects are doing safe systems programming that without Rust would have been done in C or C++ and would have had to be unsafe.

Even if the benefits are "worth the cost of a new language", is using the new language worth the cost of it being Rust?

You have not made your argument clear.

Are you questioning whether Rust is simply not good enough to be worth using by anyone? Lots of people, including me, have judged that is worth using for us, both before we tried it and after we've put Rust projects into production.

(BTW once again you have implied there is something deeply wrong with Rust that cancels out its benefits, without saying what that might be. That is annoying.)

You're not seeking answers; in place of anything that would lead to a better understanding, you're asking the questions that make it easier to defend the position you've staked out. (Great job, Brendan!)

If someone released a memory-safe, highly concurrent, systems-oriented version of INTERCAL, you recognize that someone might look at that and say, "Gee, I don't think that's really worth using", and the comment's lack of detail doesn't nullify the substance of what makes the comment true or not? And an opponent could approach in the same way you are now, with the primary goal of "beating" the other participant—by making it burdensome to respond—and by all appearances do so?

It's not my job to painstakingly prepare a perfect, incontrovertible response for a hostile adversary, particularly since absolutely nothing would come of that time investment. If your idea of success is the sound of all your colleagues telling yourselves that you won the conversation and you're on the right track and nothing needs to change because there really aren't any issues... then, hey, that's just fine.

You asserted that Rust should be thrown away, but decline to provide any reasons why you think that. So yeah, in the absence of any supporting argument, I reject your claim, and so would any other reasonable person who doesn't already believe it. You have added nothing to the discussion.

> You asserted that Rust should be thrown away, but decline to provide any reasons why you think that.

That simply isn't true.

> I reject your claim

That's fine.