And I know people that have used bevy to make games and liked it more than any other engine they tried before. Many people are already using it in production, there's also multiple games built with bevy released on steam with many more in progress.
It's completely expected that it doesn't click for everyone, but I don't get why you are framing it as if hitting a brick wall is the only experience that people have when making games with bevy. Plenty of people just don't like the ECS model. That doesn't mean that bevy is bad. It's just not for them. We are lucky enough that there's a great alternative in the rust gamedev ecosystem like Fyrox for those people. It doesn't have to be a competition.
The UI framework will be bevy_ui just like godot uses godot ui library. What needs to be done is improve it so it can actually work for making a complex app.
I've seen a codebase where half the features were implemented by inheriting the controller class and adding some behaviour and then that wqs wrapped in another layer adding more behavior. It had about 5-6 layers of that. I guess it's not 10 layers, but it was still extremely shitty code that was very not fun to deal with.
People are getting caught up on the loops thing. All I meant was in my line of work I often end up with many special cases of general processes. Writing a loop prematurely always bites me - I end up writing control flow for handling the one-offs, it somehow always becomes more obtuse than just listing things out literally.
Goto. In the end it's all about manipulation of the instruction pointer.
Loops as deduplication is a very specific subset of looping that is very popular in some languages and almost nonexistent in others. If you don't have destructuring and convenient list literals you might never ever see it in the wild.
But even the Java 7 version (iterating an ImmutableList.of multi-nested Maps.immutableEntry of new FunctionN) can be workable despite its hilarious amount of repeated type annotations, if you have learned to stop worrying and love the tooling. Stuff like typescript makes it a breeze, so much that one might occasionally forget that it's not the regular form of looping.
There's rayon, which in my opinion makes writing multi threaded code even simpler than openmp. It's also nice that it doesn't rely on any compiler feature. It's just a library.
It's one of the thing that annoys me the most about these discussions. The best language to prototype in is the one you know the most. For me and probably for you too, that's rust. So it's trivial for me to start a new project and have everything I need very quickly. With pretty much any other languages I need to relearn some syntax or apis which is a massive waste of time when prototyping.
UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows. Build tools that assume a unix environment is present aren't a solution.
Posix is cross platform. There's a reason it's easy to build stuff on mac os, free bsd and linux.
Just because Windows decided to do everything differently to Unix and you decided to use Windows doesn't mean everything else has to adapt to be "cross platform".
FWIW, GNU Make runs fine in Windows if you're allergic to WSL
> UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows.
I fail to understand what point you tried to make. There are already plenty of Make implementations for Windows. If you think that installing a third party tool like Task is ok, I don't see how doing the same with a Make implementation would exclude it as a valid alternative.
I don't think using Task is better either. I was just replying to OP saying to just use unix tools. Unix tools aren't cross platform so they aren't a good build tool either.
nmake has been part of MS Visual Studio and former incarnations such as MSVC since basically forever (1988?). And while the shell language recognized by command.com limits nmake's usefulness, tar and curl have been added to standard Win installations only recently.
It's completely expected that it doesn't click for everyone, but I don't get why you are framing it as if hitting a brick wall is the only experience that people have when making games with bevy. Plenty of people just don't like the ECS model. That doesn't mean that bevy is bad. It's just not for them. We are lucky enough that there's a great alternative in the rust gamedev ecosystem like Fyrox for those people. It doesn't have to be a competition.