Readit News logoReadit News
IceSentry commented on Bevy 0.13: ECS-driven game engine built in Rust   bevyengine.org/news/bevy-... · Posted by u/_cart
martin-t · 2 years ago
It also has a statically typed storage for game entities, something ECS-based engines are lacking and in fact many people have tried to write an ECS wit hstatically typed entities and all (including me) ended up conclusing it's not possible in the current Rust.

Oh and if you care about "deep level details" then i can still say fyrox has better internals. I know people who have given bevy many more chances than me and each time ran into a brick wall when writing an actual game.

IceSentry · 2 years ago
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.

IceSentry commented on Bevy 0.12   bevyengine.org/news/bevy-... · Posted by u/przmk
pests · 2 years ago
Yep. Built with Bevy similar to how Godot is self-hosted. They are still figuring out the details like which UI framework to use and how to save scenes. Which abstractions to introduce - nodes like Godot, objects+components like unity, etc? Then debate on how "prefabs" are designed - are they just bundles? Entity and component serialization.... Tons of architectual decisions.

It's coming together.

IceSentry · 2 years ago
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.
IceSentry commented on Bevy 0.12   bevyengine.org/news/bevy-... · Posted by u/przmk
Buttons840 · 2 years ago
I'm put off by the limited docs. I've read the Bevy book, only takes a few minutes, and just like that I'm out of resources to turn to when I get stuck.

When will the docs improve? I look at the release notes and ideally every one of those features would have several pages of docs. I understand that's a lot of work, and maybe things will have to stabilize before we get full docs?

IceSentry · 2 years ago
Bevy does have plenty of documentation here: https://docs.rs/bevy/latest/bevy/

What's missing is tutorial type documentation, but individual features are generally documented.

IceSentry commented on Backward Compatibility, Go 1.21, and Go 2   go.dev/blog/compat... · Posted by u/philosopher1234
tester756 · 3 years ago
>The quality of the average codebase written in 10 layer-abstraction-heavy

This meme needs to die. I've seen "10 layer abstraction heavy" code base only once

The code was simulating hardware/firmware behaviour when the real impl. was not available, and when the real impl. was delivered, then it was called instead.

So that was quite reasonable why they went with this like that.

Normal apps are mostly MVC-like where controller receives HTTP request (like 5 LoC?),

moves it to some handler which performs business logic / calls db and the returned stuff is either HTML or JSON.

That's your average web app.

IceSentry · 3 years ago
Well I guess you've just been very lucky.

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.

IceSentry commented on Throw away your first draft of your code   ntietz.com/blog/throw-awa... · Posted by u/herbertl
extr · 3 years ago
As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is:

* Start with a blank `main` file and proceed linearly down the page, executing as I go.

* Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file.

* If I need to parameterize them, add those parameters as needed - don't guess at what I might want to change later.

* Embrace duplication - don't unnecessary add loops or abstractions.

* Once the file is ~500 LOC or becomes too dense, start to refactor a bit. Perhaps introduce some loops or some global variables.

* At all times, ensure the script is idempotent - just highlighting the entire page and spamming run should "do what I want" without causing trouble.

* Once the script is started to take shape, it can be time to bring some OO into it - perhaps there is an object or set of objects I want to pass around, I can make a class for that. Perhaps I can start to think about how to make the functionality more "generalized" and accessible to others via a package.

This is literally the only way I've ever found to be productive with green field development. If my first LOC has the word "class" or "def" in it - I am absolutely going to ripping my hair out 12 hours later, guaranteed.

IceSentry · 3 years ago
I don't understand why you consider loops an abstraction. They are some of the most basic building block.
IceSentry commented on Rust vs. Julia in scientific computing   mo8it.com/blog/rust-vs-ju... · Posted by u/EvgeniyZh
cozzyd · 3 years ago
Is there something like OpenMP for rust? (there must be...) But I imagine MPI is probably not a great fit...
IceSentry · 3 years ago
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.
IceSentry commented on Rust vs. Julia in scientific computing   mo8it.com/blog/rust-vs-ju... · Posted by u/EvgeniyZh
jjnoakes · 3 years ago
> it is not a language that lends itself to quick prototyping

Maybe it depends on your perspective, or maybe it is simply personal preference, but I find rust pleasant and quick to prototype in.

IceSentry · 3 years ago
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.
IceSentry commented on Bun v0.7.0   bun.sh/blog/bun-v0.7.0... · Posted by u/sshroot
jsomedon · 3 years ago
AFAIK there are competing javascript runtimes including Bun, Deno, Rome, Node and other runtimes that I don't know about. So which one to use?
IceSentry · 3 years ago
Rome is not a runtime and picking one depends on your use case and personal preference about certain features.
IceSentry commented on Bun v0.7.0   bun.sh/blog/bun-v0.7.0... · Posted by u/sshroot
tehbeard · 3 years ago
Really odd since the logo design is around a pastry rather than a rabbit to mix such memey naming conventions.
IceSentry · 3 years ago
Why is that odd? Why are you even talking about a rabbit?
IceSentry commented on Taskfile: A Modern Alternative to Makefile   cloudnativeengineer.subst... · Posted by u/EntICOnc
rewmie · 3 years ago
> 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.

IceSentry · 3 years ago
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.

u/IceSentry

KarmaCake day89March 31, 2017View Original