6 ms·

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I'v

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge package downloads (my project folder was roughly 1gb for a simple 2D project), and of course Rust itself was difficult to get into with lifetimes and having to wrap and unwrap my variables constantly and getting into wrestling matches with the borrow checker. I kept telling myself that everyone loves Rust and the community loves to rave about anything Rust-related and maybe I just don't get it, but it took some time to realize that no... It's just a terrible choice for it. I even tried to make UI with eGUI and was still miserable. Rust is a systems programming language but the community is trying to convince everyone should be used for general purpose stuff. And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix. I am curious about Bevy when it becomes mature and has its own editor, but for now I'm just not convinced gamedev with Rust will ever take off.

DarkNova6 2y ago
Just a small addition: Godot also has great C# support. It is a real charm to work with.
- treyd 2y ago
  The godot-rust project crates take a minor amount of adaptation to understand how it exposes the Godot object system in Rust but it's also pretty well developed.
  - DarkNova6 2y ago
    Nice to hear! Really want to get into Rust at some point. This might be a nice segue into it
- leduyquang753 2y ago
  Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.
  - DarkNova6 2y ago
    How long ago was that? I only started with the most recent version of godot and it all works as expected. However, I am also using Rider.
  - nazgulsenpai 2y ago
    Godot C# works pretty seamlessly with VSCode and has improved dramatically over the years. It did regress a bit in Godot 4 after swapping to the newer .net "core" (in terms of platform support) but as of 4.2 I have had no issues at all.
fleventynine 2y ago
I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).
- iknowstuff 2y ago
  https://dioxuslabs.com/blog/release-050 https://dioxuslabs.com/blog/release-050 Seems promising, very React-esque with little boilerplate
  - vacuity 2y ago
    I hope Rust does gain mature options for its GUI ecosystem, but the author of the article makes a very good point that in other languages, there would be mature options in use already. "Seems promising" is too little, too late.
    - iknowstuff 2y ago
      For sure! I would not write a game in Rust in 2024.
      - pigpang 2y ago
        Many games are written in Rust already, but they are not AAA games. Example: https://bfnightly.bracketproductions.com/chapter_0.html https://bfnightly.bracketproductions.com/chapter_0.html
  - alimnes 2y ago
    Development speed is many times lower than with Typescript frameworks, while the result is not faster or significantly more stable. Why should anyone choose Dioxus over Sveltekit, Next or Nuxt? I never had an issue with a frontend app that the borrow checker would have catched. Error handling was an issues some years ago but is solved by now when using one of those modern frameworks. (I don't know if Dioxus has error boundaries, though.) Those Rust fullstack frameworks make sense only for people wanting to use Rust, not for people looking for the right tool for the job.
vacuity 2y ago
Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization. * name intentionally made to make people angry
- suby 2y ago
  If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.
  - estebank 2y ago
    I would assume that it would opportunistically try to run the borrow checker, and if it fails on the access of a specific field, turn that access into an Arc/Rc everywhere, leaving any other access as references. This leaves you with invisible performance cliffs, where accessing a field in a new place suddenly increases the cost of accessing it everywhere else, but it does give you the "just do what I want, damn it!" development experience. I doubt Rust itself could do that without alienating its current userbase, but a RustScript could.
    - suby 2y ago
      Thanks for the reply, it's an interesting idea.
- efnx 2y ago
  There’s [Rune](https://github.com/rune-rs/rune/ https://github.com/rune-rs/rune/).
hi-v-rocknroll 2y ago
Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;) Perhaps learn another language like Haskell, Swift, or Kotlin before Rust. Get cargo-bloat, cargo-cache, and cargo-outdated. Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location. Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.
pcwalton 2y ago
> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix. Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.
- kbenson 2y ago
  > but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood. I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.
  - pcwalton 2y ago
    Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png https://i.imgur.com/oXUxC2h.png You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!
    - VS1999 2y ago
      The problem is that most of the gameplay code is linear, and people have already gotten good at splitting parallel work across threads. Serious physics engines (see jolt) are already designed to run on another thread and distribute the work across multiple cores. The main part of graphics drivers when using opengl or vulkan run on another thread and the UI you access just passes data to it. Rust's parallelism hasn't proven to be faster than C/C++, let alone less annoying to achieve.
Quothling 2y ago
We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++. I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires. > my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.
- otabdeveloper4 2y ago
  > C/C++ is not something that exists in the real world.
jvanderbot 2y ago
This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc. I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.
- pigpang 2y ago
  It's possible to write unsafe and slow code in Rust.
nialv7 2y ago
> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it? Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?
- spacechild1 2y ago
  > So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it? Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.
logicprog 2y ago
As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here. Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful. This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development. I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.
ciwolsey 2y ago
Garbage collection causes performance issues.
alimnes 2y ago
> Rust game development feels like a solution looking for a problem to fix. The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.
- neonsunset 2y ago
  This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools. As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better). Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).
  - obdev 2y ago
    I mean, if we are allowed to lie in order to promote Rust, why don't we just smear all the C/C++ code bases in the world as security hazard needed to be sorted out ASAP? Unless we already do...
    - neonsunset 2y ago
      I doubt security is the matter everyone is concerned with but rather the quality of tooling and developer experience. It is, of course, difficult to convey to developers who only experienced C and C++ build systems, or Ruby tooling and brittleness, or Python way of managing dependencies, or setting up the packaging when using Java, that fast and easy to use solutions do not come from trade-offs but from just better ways of doing so - using cargo and Rust or dotnet and C# is night and day difference compared to options listed above. I said it here in the past and will say it again: it's not that Rust (or .NET for that matter) are that good, it's a lot of other popular languages and platforms are that bad at one or another aspect (or many at the same time), that make it sufficiently painful to never tolerate a downgrade when you worked with a tool that offers better all-around experience.

DarkNova6 2y ago

Just a small addition: Godot also has great C# support. It is a real charm to work with.

treyd 2y ago
The godot-rust project crates take a minor amount of adaptation to understand how it exposes the Godot object system in Rust but it's also pretty well developed.
- DarkNova6 2y ago
  Nice to hear! Really want to get into Rust at some point. This might be a nice segue into it
leduyquang753 2y ago
Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.
- DarkNova6 2y ago
  How long ago was that? I only started with the most recent version of godot and it all works as expected. However, I am also using Rider.
- nazgulsenpai 2y ago
  Godot C# works pretty seamlessly with VSCode and has improved dramatically over the years. It did regress a bit in Godot 4 after swapping to the newer .net "core" (in terms of platform support) but as of 4.2 I have had no issues at all.

fleventynine 2y ago

I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).

iknowstuff 2y ago
https://dioxuslabs.com/blog/release-050 https://dioxuslabs.com/blog/release-050 Seems promising, very React-esque with little boilerplate
- vacuity 2y ago
  I hope Rust does gain mature options for its GUI ecosystem, but the author of the article makes a very good point that in other languages, there would be mature options in use already. "Seems promising" is too little, too late.
  - iknowstuff 2y ago
    For sure! I would not write a game in Rust in 2024.
    - pigpang 2y ago
      Many games are written in Rust already, but they are not AAA games. Example: https://bfnightly.bracketproductions.com/chapter_0.html https://bfnightly.bracketproductions.com/chapter_0.html
- alimnes 2y ago
  Development speed is many times lower than with Typescript frameworks, while the result is not faster or significantly more stable. Why should anyone choose Dioxus over Sveltekit, Next or Nuxt? I never had an issue with a frontend app that the borrow checker would have catched. Error handling was an issues some years ago but is solved by now when using one of those modern frameworks. (I don't know if Dioxus has error boundaries, though.) Those Rust fullstack frameworks make sense only for people wanting to use Rust, not for people looking for the right tool for the job.

vacuity 2y ago

Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization. * name intentionally made to make people angry

suby 2y ago
If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.
- estebank 2y ago
  I would assume that it would opportunistically try to run the borrow checker, and if it fails on the access of a specific field, turn that access into an Arc/Rc everywhere, leaving any other access as references. This leaves you with invisible performance cliffs, where accessing a field in a new place suddenly increases the cost of accessing it everywhere else, but it does give you the "just do what I want, damn it!" development experience. I doubt Rust itself could do that without alienating its current userbase, but a RustScript could.
  - suby 2y ago
    Thanks for the reply, it's an interesting idea.
efnx 2y ago
There’s [Rune](https://github.com/rune-rs/rune/ https://github.com/rune-rs/rune/).

hi-v-rocknroll 2y ago

Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;) Perhaps learn another language like Haskell, Swift, or Kotlin before Rust. Get cargo-bloat, cargo-cache, and cargo-outdated. Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location. Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.

pcwalton 2y ago

> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix. Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.

kbenson 2y ago
> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood. I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.
- pcwalton 2y ago
  Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png https://i.imgur.com/oXUxC2h.png You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!
  - VS1999 2y ago
    The problem is that most of the gameplay code is linear, and people have already gotten good at splitting parallel work across threads. Serious physics engines (see jolt) are already designed to run on another thread and distribute the work across multiple cores. The main part of graphics drivers when using opengl or vulkan run on another thread and the UI you access just passes data to it. Rust's parallelism hasn't proven to be faster than C/C++, let alone less annoying to achieve.

Quothling 2y ago

We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++. I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires. > my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.

otabdeveloper4 2y ago
> C/C++ is not something that exists in the real world.

jvanderbot 2y ago

This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc. I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.

pigpang 2y ago
It's possible to write unsafe and slow code in Rust.

nialv7 2y ago

> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it? Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?

spacechild1 2y ago
> So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it? Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.

logicprog 2y ago

As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here. Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful. This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development. I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.

ciwolsey 2y ago

Garbage collection causes performance issues.

alimnes 2y ago

> Rust game development feels like a solution looking for a problem to fix. The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.

neonsunset 2y ago
This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools. As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better). Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).
- obdev 2y ago
  I mean, if we are allowed to lie in order to promote Rust, why don't we just smear all the C/C++ code bases in the world as security hazard needed to be sorted out ASAP? Unless we already do...
  - neonsunset 2y ago
    I doubt security is the matter everyone is concerned with but rather the quality of tooling and developer experience. It is, of course, difficult to convey to developers who only experienced C and C++ build systems, or Ruby tooling and brittleness, or Python way of managing dependencies, or setting up the packaging when using Java, that fast and easy to use solutions do not come from trade-offs but from just better ways of doing so - using cargo and Rust or dotnet and C# is night and day difference compared to options listed above. I said it here in the past and will say it again: it's not that Rust (or .NET for that matter) are that good, it's a lot of other popular languages and platforms are that bad at one or another aspect (or many at the same time), that make it sufficiently painful to never tolerate a downgrade when you worked with a tool that offers better all-around experience.