I am a sucker for badges

The manual for Semantic Mediawiki sucks donkey balls. For so many reasons.

But today's comes courtesy of some fucking genius web designer.

So I'm reading the manual to see if this thing will help me with something I'm working on, and I realise this particular help page has some loading it's doing.

Those three grey bars are animated. It's a nice little animation.

It's also moving the entire fucking sidebar up and down +/- 5 pixels.

@Arantor yeah...was just reading this bit, which hits those points:

Rust is the type of language where wanting to do a new type of upgrade might lead you down a path of refactoring all of the systems, and many would even say "that's great, now my code is much better and can accommodate so many more things!!!". It sounds like a very convincing argument, one that I've heard many times, and one that has also caused me to waste a lot of time chasing down solutions to the wrong problems.

A more flexible language would allow the game developer to immediately implement the new feature in a hacky way, and then play the game, test it and see if the feature is actually fun, and potentially do a bunch of these iterations in a short amount of time. By the time the Rust developer is finished with their refactoring, the C++/C#/Java/JavaScript developer has implemented many different gameplay features, played the game a bunch and tried them all out, and has a better understanding of which direction should their game be taking.

And I can definitely see his point. I often do that sort of thing, even in not-game-development. Then throw some things away and maybe start over if it was actually too ugly and the Final Solution actually sparks some ideas about how to do it better.

It's a fascinating post for sure.

The thing that I would tend to try and hone in on: the complaint that he's making about Rust's unsuitabilty is not 'everything you do forces you to refactor' as a universal big bad, because outside of game dev this trade off is often but not always useful for exactly the points being made about reliability/maintainability.

Game dev is actually very weird in this regard that you don't (generally) need to think about long term maintainability in terms of adding new functionality incrementally and stably the way the rest of us shmucks have to do.

His main beef boils down, very very hard, to 'game dev is basically experimental science from the off and Rust kinda sucks for doing that' which even in my limited experience of Rust, I'd tend to agree. Rust is great when you sort of know the direction you're going in and your overall trajectory isn't wildly going to change but you can incrementally improve it.

But game dev especially in the early phases leans super hard on the thrashing around sense of 'is this fun, what about now, what about now' where you don't (and shouldn't) care about maintainability or long term management because you're essentially making lots of little prototypes and refinements to understand what works and what's fun.

Rust sucks for this - and I'll back up his points about egui and Bevy, having tried egui raw and learning about Bevy in the process to understand how I was supposed to do things in egui... it's not good. It solves a specific need, sure, but the need seems to be almost theoretical on some level.

ECS in Rust has this tendency of turning from something that is considered a tool in other language to become almost a religious belief. Something that should be used because it is pure and correct, and because doing that is the right way.

Programming language communities often have certain tendencies, and having been a serial language hopper over the years I find it interesting to compare these. The closest thing to Rust's view on ECS I can think of is Haskell, except, and I know this is an oversimplification but I'll say it anyway, I do feel that the overall community in Haskell is a lot more mature, and that people in general tend to be more reasonable about the existence of other approaches, and view Haskell as a "fun tool to solve problems where it fits well".

Rust on the other hand often feels like when you talk to a teenager about their preference about anything. What comes out are often very strong opinions and not a lot of nuance. Programming is a very nuanced activity, where one has to often make suboptimal choices to arrive at a result in a timely manner. The prevalence of perfectionism and obsession with "the correct way" in the Rust ecosystem often makes me feel that the language attracts people who are newer to programming, and are easily impressionable. Again, I understand this doesn't apply to everyone, but I think the overall obsession with ECS is in some sense a product of this.

Leaving Rust gamedev after 3 years

An interesting post from a former rust gamedev. My company has lots of "upskilling: () stuff, which is pretty cool. Right now they're doing a rust class, and sent out an email soliciting responses for a second. I'm not sure I want to commit to something like that, but they mentioned that they used The Rust Book and some Udemy course.

I've been slowly reading through the book, since about the only rust exposure I've had has been around here. I don't really do a lot of systems type programming any more, but the promises of rust are certainly interesting, so I've been trying to get something of a handle on it.

Anywho...I thought this bit was interesting:

But, and I say this having spent the past ~3 years and written over 100k lines of game-related code in it across the whole ecosystem of frameworks/engines and having made my own, many if not most of the problems don't go away if one isn't willing to constantly refactor their code and treat programming as a puzzle solving process, rather than just a tool to get things done.

To me, that "puzzle solving process" is what makes coding really fun. I mean, I like standing back after the fact and appreciating the stuff I made, but the solving is really engaging for me. He elaborates:

The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them "write good code", but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean that this is a desirable way to write code. I've often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.

Eh...well...there's nothing so permanent as a temporary solution. I can understand having mixed feelings about this, but I can also say that when I've done this sort of thing, I'm usually much happier with the end product than in cases where I've considered a significant refactor of a work in progress and didn't do it because it seemed like too much.

This is a long post and I'm still in the first section.

https://www.bleepingcomputer.com/news/security/fake-job-interviews-target-developers-with-new-python-backdoor/