It has by far the most broken type system which is basically a facade for the programmer to feel safe

Unity is trash and I’ll just leave that alone.

Using Rust for a game engine with wgpu, unless you already know Rust intimately and have used the Vulkan API before, is going to be difficult for you. I recommend you give it a try, but last I checked wgpu expected you to be familiar with Vulkan and is missing comments on most crate types and functions.

You might have better luck with something like macroquad or miniquad, but you’ll probably hit a wall and realize you want to do something that the developer didn’t think to expose an API to make possible. You’re also on your own for sound. Bevy has many components and I know it’s popular, but I don’t know if it has rendering. Maybe macroquad is the missing piece? Oh, and then text rendering. That’s a tough one.

I recommend a couple options: browse lib.rs or AreWeGameYet for game engines that aim to provide a complete package.

For non-rust, recently Relogic gave a bunch of money to Godot and FNA, so I would check those out. That’s going to be your quickest start (towards minimalism and performance) that isn’t unity.

You have much to learn Young Padawan. If you’re wanting to make a desktop app in Rust it behooves one to avoid embedded web environments. For performance reasons of course.

If your Nixpkgs input uses a specific Git branch, such as nixpkgs-unstable, it needs to be a supported release branch.

Don’t like this. Some projects are only intended to use nixos-unstable. And it wouldn’t make sense to expect users to override the flake’s nixpkgs input with .follows, if they use unstable, because often there are significant differences between code that uses stable and unstable. If the flake targets stable and this is overridden, it’s likely things will break.

Your Nixpkgs input must have been updated in the last 30 days.

Seems reasonable.

If your Nixpkgs input is a GitHub repo, it needs to have the NixOS org as the owner. In principle, you could have a Nixpkgs input owned by someone else, for example inputs.nixpkgs.url = "github:EvilCo/nixpkgs".

The reasoning behind this is valid but what if it is a project that needs a fork? This is probably rare, so I guess I’m okay with it.

All in all, I think these are the wrong checks to be doing. There are probably many other assurances that could be made, like correct output attributes (what is known of the official schema plus ones made standard by precedent), validate the values, and suggest making tests for certain common outputs.

The project makes me think that if it gains popularity and people start following these guidelines, you’ll see badges on repositories that make newbies think that’s the sanctioned way to do things. But there is no sanctioned way to do things yet, flakes are supposed to be freeform.

I think these checks need to be thought out more than they have been, and I think especially the first check has the potential to fragment the community more.

For businesses using Nix, maybe it makes sense.

That’s pretty cool, I’ll dig around in that later. Was looking for a better way to do nftables.

Yes. The format is widely accepted by the community and generally everybody’s preferred way of organizing and sharing code.