Not the same commenter, but I’d guess: enabling some features for bindless textures and also vk 1.3 dynamic rendering to skip renderpass and framebuffer juggling
DuChinese does have an integration with HackChinese, which is basically a Mandarin only paid version of Anki with a sleek interface. I use it for convenience because I find managing Anki decks too tedious.
I prefer the first example, to be honest. Much of the time your API is more or less a wrapper around the DB, so why introduce more indirection? I don’t really buy the testing argument since the interesting stuff which really needs testing is often in the queries anyway. Swapping out dependencies is not a huge issue in a language like rust, the compiler gives you a checklist of things to fix. I also don’t like that you call this function which handles transactions internally, inevitably you’ll end up with a handler calling two different functions like this resulting in two transactions when they should be atomic.
At $work we’re slowly ripping out a similar system in favour of handlers calling database functions directly, such that they can put transactions in the right place across more complicated sets of queries. Code is simpler, data integrity is better.
It's not really about being able to swap out the db or something, that's just a bonus. It's about being able to write a proper domain model (ie. entities and business rules etc.) that is clear and testable and independent of details like persistence, serialisation, i/o protocols etc. If your system is just CRUD, then you absolutely don't need anything like this, but if you have business rules (high level stuff) and intermingle it with low level details then it quickly becomes a mess that is hard to reason with.
But you should totally do what you're doing until it breaks. You only start looking into better architecture when things are not working. Being aware of something like this means you'll have something to look up if/when you run into the problems that inevitably crop up in simple "db wrapper" type APIs.
It is for testing, but you don't indirect over class A because you want to test class A, you do so to test class B.
By all means, write a test to make sure the queries actually work on the database. It will be slow, stateful and annoying, but still probably worth it.
But you don't want to bring that slow-statefulness over to every other upstream test in the entire system: want to test if the permission system (in some outer class) is allowing/blocking correctly? You'll need to start up a database to do so. Is your test making sure that an admin with permissions can create a user (without error?), well it's going to start failing due to USER_ALREADY_EXISTS if you run the test twice. To avoid that you'll need to reset and configure its state for every single invocation.
> To avoid that you'll need to reset and configure its state for every single invocation.
Good testing frameworks just do this for you.
I generally prefer focusing testing efforts around what you describe - spinning up the entire system under test - because that's how the system is used in real life. There's definitely times you want to test code in isolation statelessly, but I find that engineers often err on the side of that too much, and end up writing a bunch of isolated tests that can't actually tell you if an http call to their API endpoint performs the correct behavior, which is really what we want to know.
> Much of the time your API is more or less a wrapper around the DB, so why introduce more indirection?
That's an easy scenario. General utilities should aim to make hard things possible and then minimize the overhead in easy scenarios, so the fact that this is more complex than the dumbest thing that could possibly work, is not by itself a good argument against.
Anyone who believes Hancock’s ideas should really watch the debate with Flint Dibble[0], in which Hancock eventually admits he has no evidence of his ancient civilisation, and Rogan, who is a long time friend and believer of Hancock, seems to end up siding more with Flint.
Absolutely agree with the comments on ECS and Bevy in particular. I tried getting to grips with it for some time, doing things the Bevy way, and it just felt like a big step backwards because it’s not suitable for most things. The renderer was really slow at the time too, although I imagine that has improved. Switched to plain rust + vulkan (via ash) + dear imgui and haven’t looked back.
Some of those issues with Bevy might have more to do with its immaturity. It still needs at least a few years to be a solid choice for all sorts of games, in my opinion. I do think the hype should be toned down; people shouldn't feel pressured to worship Bevy or Rust or whatever is the hot new thing.
The pink car is in the wrong lane if it wants to stay on the roundabout for a later exit. The pink car can take either the first or second exits here. The orange can take the second, third, etc.
For anyone wishing to get a taste of very modern graphics programming with Vulkan, I enjoyed Arseny Kapoulkine’s YouTube series [0]. Although he focuses somewhat on mesh shading, he does also build a more traditional pipeline alongside it. I found it much nicer to follow along with this than grind through the first X hours via written tutorials.
Hadn’t heard of shifted pointers before, thanks. There is an open PR to Ghidra which adds them, they seem very useful. I’ve run into many places which would benefit from them.
