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.
I only skimmed this article, but, despite it being very negative about Rust, I almost 100% agree with it: Rust is a HORRIBLE choice for game dev. I might quibble with how they outline the costs and benefits of some of the design patterns that rust forces you into, for instance I think command lists are actually incredibly useful and perfectly fine as a game development thing and not the huge problem they consider them to be, and generational arenas basically solve any pointer ownership problems in game development in my opinion, but they are right in the main.
I know, because I've tried it. Once. I would #never* recommend Rust to game developers, especially not indie ones. In fact I'd recommend against it strenuously!
And this is precisely because Rust is explicitly and knowingly focused on correctness, safety, perfectly clean code, etc at the cost of iteration speed and flexibility and dynamicism, and that's bad for designing game mechanics and even just getting a game done — games have an inherently short life span and development cycle, so safety and correctness and code quality don't matter a whole lot. It's okay if they crash, etc, as long as they work enough to play. It's okay if the code is ugly, you probably won't be working on it for very long. This is even moreso the case, as the author says, because in writing a game you really want to be able to iterate quickly and just. Do shit as an experiment, even if it's temporary, to see how it feels.
On the other hand, who I would recommend Rust to is the people writing game engines, where you really will probably be working on that code for years to come, where stability and correctness is pretty important, and so where Rust's strengths will really shine — but crucially, even then, I'd tell them to make it a real engine, not a game framework like Bevy, by adding a highly flexible, dynamic scripting language like Lua or even C#, and a data format for specifying scenes and entities, and an editor. That way you don't write your game in Rust at all!
I'm disabled so I don't have a lot of energy to work on it often, but, especially once I nail down the last few design issues, I'd really love help, or even just a few eyes on the project to encourage me ;)
I like it, I read the Design Document. Do you have any game concepts you are building with it? It seems like the kind of project that would be built with a game side-by-side.
I don't think they could actually do that. They provide funding for Fedora's infra, but they don't make up the majority of contributors, and if you read through the actual governence model (note that the higher up the group, the less power it seems to have — the Fedora Council or whatever basically only exists to solve disputes that bubble up from lower, entirely community run and elected, groups), while Red Hat does have some influence/positions, they have far, far less power than the community just by numbers and also by who controls various things, and everything is also done by consensus to boot, so Red Hat couldn't just unilaterally change how Fedora works. At best they could withdraw funding (making Fedora less well-tested) and their people on the governing bodies, but it wouldn't amount to much. And Fedora is upstream from Red Hat Linux and CentOS and provides them with an utterly massive amount of labor and testing they couldn't hope to achieve on their own that they get by virtue of it being FOSS, so it would be a pure harm to them to shut Fedora down or make it closed even if they could, whereas the story is very different with CentOS and RHEL.
I'm not a maintainer of any significant open source projects, but I'm very sympathetic to the author here. My personal philosophy has always been that I want to try to support, either with my time or my money, the creation of any projects that I find useful or use in my day-to-day life, and that anything I get from open source contributors or maintainers is supererogatory, a surprise, a free gift to be excited and happy about, instead of to take as something I am owed and demand more. I think the entitlement that much of the open source community directs towards our maintainers, where we expect them to fix all of the bugs problems we have, add all of the features we need, and somehow conform to everyone's vision and use case for the product, or else they are evil and selfish and "don't listen to the community," is just fundamentally unfair and unjustified: these people are doing work for free, and as such don't have any sort of obligation to us. No one deserves an ounce of free labor from anyone else, but the opposite of that seems to be the mentality that the FLOSS community has fallen into, and that sense of draining, entitled, almost childish obligation is naturally going to burn out maintainers and contributors at a pace faster than we can probably afford to replace them, because who wants the Sisyphean task of tirelessly and thanklessly appeasing hordes of childish demands? This is not to say that the demands themselves, they're specific technical content, are necessarily childish — of course they probably aren't. This is just to say that the expectant, demanding tone most requests are made in, which betrays the entitlement that motivates them, is itself childish. Neither is this to say that all requests made towards an open source project must be childish, as there is a way to make a request that doesn't seem like a demand, or contacts where demands are fair, like asking them to fix a CVE.
I do also think though that some of the author's problems also probably stem from the fact that they used an open source license instead of a proper free software license like the lgpl or mpl, which means that they weren't able to force individuals and companies to contribute back to the software commons they were all benefiting from, and therefore ended up with a free rider problem. A copy left license would have at least made people contribute some of their time to the library, if nothing else. But it isn't a perfect solution either.
In any case, I think this author's solution to the conundrum here is actually pretty reasonable. I've been pretty sympathetic to the idea of providing all of your source code — enough to compile and build a complete and functioning version of your project — as free and open source software, but asking for money if someone wants the convenience of pre-built binaries or packages, or access to a package repository or continuous integration system or something. It seems extremely fair to me to say to the user, essentially, "yes, you can get all of the source code you need to build a version of my project, so I'm not taking a way any of your basic software freedoms, but I'm not going to do anything more than the absolute bare minimum for you if you don't want to do anything more than the absolute minimum for me". Because while I believe in the idea that information should be free, and that open source is the best development model, and that libre software is important for user rights, I don't think that people are entitled to project authors going out of their way to provide conveniences like pre-built binaries or packages or package repositories.
On the same subject, I think this sort of entitled mentality in FOSS actually compromises the quality and diversity of the open source ecosystem as well: instead of each open source project being free to pursue, on its own terms, its own unique vision for what it wants to do and how it wants to achieve that, and everybody getting to choose which projects to use based on whether their vision happens to align with the vision of the project, instead users seem to just pick a project at random, based on whatever was provided to them by default or whatever they came across first, and then petulantly demand repeatedly that the project conform to whatever they want, making every project an exercise in regression to the mean through the eternal process of satisfying some giant collection of random people, until any unique coherent vision or direction for the project is lost under the weight of democratic cacophony. See GNOME vs KDE, essentially.
I tried to use this to get better completions with nushell, but it just doesn't have the breadth and depth of completions that fish has as of yet, nor does it have automatic completion generation from manages (although it does have a tool for that) so I eventually gave up and just made fish itself my nushell's completion engine. However I'll be keeping my eye on it, because it's a really cool idea to have a shared completion engine for all shells, so that everyone can pool their work, and because of course having to install two entire shells just to use one of them is a bit silly so eventually I'd like to make the switch.
The completions don't work sometimes (for instance you don't get completion for some commands when running them with sudo) and it doesn't fall back on providing file completions if it doesn't know what other completions to provide, which is a bit annoying, but it generally works and I'm sure there are ways to fix that too.
This honestly seems like a bit of a vapid piece — vascullating between facile, melancholy speculations with little to back them up on the way to concluding very little.
I think this article is pretty telling, but not in the way you think. He complains that you are no longer allowed to cite Fox news, which has literally declared itself and Entertainment Network masquerading as a news network, that is known for sharing flipped or mislabeled or otherwise deeply misleading graphs and just completely lying on television. I just watched a clip from Fox News yesterday where they were just asking questions about whether Taylor Swift is an n a t o plant LOL. Likewise those Nobel Prize winners speaking out about covid that he mentions, if I'm thinking of the right ones, are people trying to claim it's a hoax and touting horse dewormer and stuff because they have Nobel prizes and doctorates in completely unrelated fields and don't know what they are talking about but have Nobel syndrome.
I think Fox News is just more honest about their bias than most; its certainly not true that CBC, CNN, etc. are unbiased lol. There is a distinct bias in wikipedia that is unavoidable if you happen to disagree with the NYT on a controversial social issue.
I don't think CBC, CNN, the NYT, etc are unbiased at all — I don't think any news source even can be unbiased, and I think the notion of neutrality that many news sources attempt to apply, most especially the NYT, actually acts as its own sort of bias; but I think you are engaging in a bit of a fallacy here: the fact that no source is precisely unbiased does not mean that all sources are equal, nor that all sources' biases manifest in the same way.
(Nor would the absence of bias automatically mean that every point of view would be treated with equal respect and giving equal time in which to air its ideas, because that in itself, if there is an inequality in the quality of the argumentation or facts of the relevant sides, would in fact be a bias in favor of the worst, least correct side.)
The bias of centrist liberal news sources tends to manifest more in the language they use to describe issues (excessive passive voice, waffling on things) or in what they choose to cover (focusing excessively on detransitioners when they make up a tiny minority compared to the vast majority of trans people who are happy with transitioning), not in a gross manipulation of and distortion of actual facts as is the case with Fox News. Speaking of which, I don't know what you could possibly mean about Fox News being more honest about their bias then cnn. They regularly claim that they are the only clear-headed, unbiased news source, that they are the only ones willing to tell you the real unvarnished truth compared to everyone else, but they are the only sane ones in this clown world, etc, and they present things in an exceedingly misleading way to the point of lying far more often than any news source which I don't think you could count as being honest about one's bias in any way unless you intend being honest to just mean being brazen.
Probably because most people actually prefer them, now that the vast majority of people are past the point of needing skeumorphic metaphors to understand user interfaces, because we grew up with computers. I would certainly throw my computer out and go live in the woods if I had to deal with beveled, gradiented garbage with dense, tiny interfaces cluttered with stuff with no proper spacing to let it breathe. When I upgraded mg family computer from Vista to 8 as a kid, or when iOS went from skeumorphic to flat a bit later, I was so relieved, it was like getting a cold glass of water.
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.