How to counter erroneous criticism of Rust?

I'm not sure if I've got it down just yet, but I generally try to phrase it as something like "do you want to say anything more on that?" If they were particularly brief, like in that case. I got the feeling that they were trying some kind of baiting from some of their later responses, but it wasn't all that different to other people saying that sort of thing, so who knows.

Perhaps there actually are a bunch of real angry Safety Justice Warrior types on social media or something? I wouldn't know.

One piece is that when someone is rude and deragatory about anything in a space where there are people who like that that thing, they will generally be able to find someone who responds a little rude and deragatory back.

But maybe more important is that some people can be very rude to some people because they think it is very rude of those people to exist at all. Since Rust tends to be friendly to minorities, there are lot of fascists (i.e. people who think is is very rude of e.g. trans or black people to exist) who dislikes Rust just for that, and extend their hatred for those groups to any groups who tolerate them. To them, it is very rude of rust to exist.

4 Likes

Ha, excellent!

One of the worst cases I have come across is this:

"The Rust Programming Language Is A Political Trojan Horse"; https://www.youtube.com/watch?v=e0xAmR_iIAs&t=20s

Totally deranged.

5 Likes

The comments alone are incredible.

1 Like

I imagined it was bad.... but not this bad :S. This is the side effect of the political propaganda from the cold war... even 30+ years after the disolution of the soviet union there's people who still see the world in terms of commies vs. freedumb.

I did not notice the shirt. Judging by scrolling through his other videos he is actually unhinged.

1 Like

To stay on topic, please make sure that this thread doesn’t turn into a comments & discussion section for one specific YouTube video that was only first mentioned far down the topic.


Also note that even when addressing off-site questionable content, it should still be avoided e.g. to criticise people’s personal appearance or make unnecessary rude remarks. This forum respects the CoC, and that will also be the case when it’s about people who aren’t part of this forum, or about people who have themself published content elsewhere that would violate our CoC.

11 Likes

In order to stay cool, it might be best to present rational arguments while maintaining the perspective that if someone refuses to hear them, it's not that big a deal, not worth getting upset about. Better times will follow, and there will be some who will listen to reason.

Even if it's not attacking a strawman, must of this discussion isn't responding to the strongest reasoning. There are sensible, grounded arguments to be had. Here's one of them (I'm summarizing it here):

Rust is a solution to a problem that few of us actually have. Garbage collection can be a cornerstone of high-performance systems, like RCU. As for correctness, Rust's other main design pillar, strong type systems can be found elsewhere, too.

Switching to Rust might be an overcorrection if you started with something like Python. I hear C# and Ocaml are pretty nice.

It's a reasonable argument, but just because you want a GC doesn't mean you want the built-in version (for example, RCU is not built into C). The language built-in GC is like the language built-in list or string: they're pretty fast for most normal programs, but probably won't be optimal for yours.

For example, GUI code wants very predictable latency, but batch code wants high throughput even if it causes long pauses. A single GC algo can't do both, but a single application will often contain code that fits both patterns. An ownership-based system like Rust can combine a Gc with arenas and Rc, and the combined result is much more elegant than a polyglot system, even if the individual parts aren't as nice.

This results in abstraction inversion in tightly-optimized managed code. Or it just results in things being slower than they should be.

Sure, but Rust is actively the wrong tool for building delightful, interactive experiences like games. You don't build fun games by carefully ensuring that every system works exactly the way you think it should. Fun games are built by relentless iteration and acceptance testing by prospective players. Who care if it's a flawless implementation of the wrong thing?

I don't think Rust is the ideal solution for building games, or many of the other things it's used for. But it's good enough for enough things that people think they're better off with Rust than they would be with multiple programming languages, which is what they'd be doing if they weren't doing Rust.

Maybe they're wrong, and would be better off adding a scripting layer? I've implemented internal GUI tools with Tauri, and it was actually pretty nice, though technically not a game so maybe I'm off-base here. But I know a lot of investment in Rust comes from Google and Microsoft, and both of them have GUI frameworks written for memory-safe languages that aren't Rust.

2 Likes

Acknowledged, understood, and adopted as a practice.

2 Likes

I don't think anything is the ideal solution for building games: they're in a rather absurd situation of being stupidly complicated (the whole point is adding lots of one off bits of interlocking logic), with huge amounts of data and extremely tight performance concerns, but also critically need contiguous tight iterations of all of this to find the fun.

The general approach for the Big Pants studios seems to be:

  • Existing mature tooling developed over decades
  • With a poorly performing, quickly iterating scripting layer
  • And a final performance push to get the worst of the scripting rewritten in the lower level language.

Rust is a terrible solution to the middle point, but in theory at least, a great solution for the first and last; because it allows for more adventurous rewrites to improve the tooling without breaking things, and because it's better at avoiding the rewritten scripts from introducing last minute bugs (both for several reasons)

It currently doesn't actually have this mature, developed over decades, tooling yet, so it's kind of a moot point. I do find it a lot more fun to play with than in C++, though!

6 Likes

FWIW, almost certainly.

I apologize in advance for ranting on this, but it sure tickles my "favorite FUD about Rust." So here we go!

TL;DR: The linked article confuses engine code for game code.


There are countless examples of games out there (blog posts, GDC presentations, you name it) that document the use of a first class scripting language or a VM for game code. Or more abstractly, represent game code in serialized data as a DSL. Engine code is an interpreter for the data.

ECS has been the tool of choice for treating data as your high-level DSL for as long as I can remember. Though, it's been in constant evolution and details differ depending on who you ask. Take for example these two posts from the same author written in 2007 and 2013, respectively: The Brain Dump: The Nebula3 Application Layer and Entity-Component-System Revisited. ECS isn't "solving the wrong problem." It isn't even improving performance, it's probably hurting perf. It isn't working around the borrow checker any more than handles workaround pointers. ECS does one thing only: managing your data.

Time for me to come clean: None of these links are about Rust! That doesn't mean it's impossible or even less likely to build this kind of architecture in Rust. Of course you can, the language is Turing complete, after all. On the contrary, it just means that I mostly picked references that predate Rust. And yet they support my claim that there is an important distinction between engine code and game code.

So, what about scripting languages? There are many games that use lua. Some of them are mostly lua, not just a few lines of simple glue code or "only for mods". Mods work because they use the same basis as the rest of the game.

Don't forget Python! EVE Online "has at its core the programming language known as Stackless Python." And there are a few others.

Here's a telling screenshot from the Scott Bilas/Gas Powered Games slide deck (2002) linked above:

It's as if you can s#Rust#C/C++# in that overlong rage quit and it reads like the last 4 decades of game development wisdom. Sometimes you just have to learn the hard way. Wouldn't it be cool if institutional memory was a thing?

I don't know, maybe their point is "making game engines is hard", and they wouldn't be wrong. But the problem is they represent Rust as being unsuitable for writing engine code, then list all the problems they had writing game code. It's frustrating every time that article comes up, because the author got so close to the right conclusion. Now everyone uses it as an example of why Rust is bad for games, but none will also admit that C and C++ are bad for games.

I cannot fix this kind of confusion. But I can point out the history and the state of the art. The motivation for data-driven design does not change just because you are using a new language.

Related:

8 Likes

Many C/C++ fans hate Rust, because it is a threat.

These people have invested many years into mastering these languages and thought themselves at the forefront for languages for performant/embedded/systems programming. They expected C/C++ to be the dominant languages in these domains for a long time, at least our lifetimes.

Because most of us believed a compiler will never guarantee memory and thread-safety unless it is too restrictive for most applications or comes with a huge runtime overhead. They thought C++ may be painful, but the pain is necessary, which makes C++ users heroes.

And then it suddenly turns out that a compiler that guarantees memory and thread safety does exist! Suddenly, it turns out C++ may be obsolete. Based on its growth so far, Rust may pass C/C++ in a few years.

So some people are grasping any straws to make themselves believe this cannot be true.

It is similar to people having grown up with the belief that their country is forever the greatest and can accomplish anything. When faced with evidence to the contrary, they react with anger.

5 Likes

The use of Rust is on the rise, even if some don't like it. The long-term trend in its TIOBE Index graph for November, 2024 is one indication of that, regardless of whether or not we can quibble about the details of how the statistics for that indicator are compiled. Other indicators show a similar trend. Meanwhile the TIOBE Index graphs for C and C++ show a general decline over the long term.

Time is on Rust's side, even as the erroneous criticism goes on. With the feeling of security from our knowledge of the general trends as a backdrop, we could just remain cool while countering the specifics of any erroneous criticisms of Rust with actual facts. There's no need to cite the trends as an argument in Rust's favor, but the knowledge of them can serve as the basis of an internal personal strategy for remaining cool.

1 Like

I agree. But it is never just one thing. Some are reacting to Rust evangelism they perceive as exaggerated (and sometimes it is), some just like to argue, etc. I don't see any benefit to paying attention to that sort of talk on any topic. What matters to me is how to answer Rust questions asked by those who sincerely want to know the answer, which is what this forum is about.

5 Likes

@jumpnbrownweasel I could not agree more.

I don't think psychoanalyzing strangers over the internet is going to help. If you're wrong, then you're wrong, and you've just thrown a bunch of dehumanizing rhetoric at someone and lost them forever. If you're right, then they're already lost, and you've still accomplished nothing.

We're all better off focusing on open-minded people with real problems. There are plenty of people who are giving it an actual try and not succeeding, and that's where room to grow can be found. We are doing ourselves a disservice by focusing on weak-man arguments instead of countering the erroneous criticisms that kinda have a point.

4 Likes

That is very heartening. I have reservations about pop charts like TIOBE but there is plenty of other evidence to indicate increased take up of Rust.

I agree, I would not like to use such popularity claims as an argument in favour of Rust. It smells of trying to justify a claim by consensus.

1 Like

Agreed, and I have reservations about pop charts in general; after all, my favorite music hardly makes a showing there, with its being alternative, rock, and folk. :person_shrugging:

As for the little dip at the end of Rust's TIOBE chart, it's in part due a big jump in Python's stats, since the charts are about percentage share. Here's the last year or so of Python's TIOBE chart:

But Python's not really the issue here anyway. Rust is solid on its own merits, and this discussion is about coolly presenting those merits to skeptics.