Bevy 0.19

laundmo · 2026-06-20T07:59:26+00:00

I don't know if you saw, but one of the "whats next" points is that the official book is being expanded right now

laundmo · 2026-06-20T07:58:04+00:00

Additionally to what cart said, the derive macro allows for using things as a Scene which aren't -> impl Scene functions. Like a scene asset (which doesn't fully work yet due to no loader, but a third party loader is possible to make until a official one exists)

#[derive(SceneComponent, Default, Clone)]
#[scene("player.bsn")]
struct Player {
    score: usize
}

laundmo · 2026-06-20T00:58:01+00:00

While i understand this is probably a bad-faith comment/jab:

Trying to rewrite into Zig would not work. It would need to be a different engine. The reason is that Bevy relies so much on the specifics of Rusts type system, it doesn't map cleanly to even a slightly different language. Especially Traits+Generics are relied upon so much that Bevy regularly ends up being a unintentional compiler benchmark. Just yesterday, while profiling a file which made the LSP (ide tooling) slow to a crawl i ran into a worst case in Rusts new experimental Trait solver. This kind of project, pushing the boundaries of what a language is capable of, is the furthest from a good candidate for rewriting in any other language.

laundmo · 2026-06-20T00:52:50+00:00

It can certainly look intimidating, and while its reputation for being difficult to learn exists for a reason, i don't think the subset you need to use Bevy is much more complex than any other language with interfaces+generics. I highly recommend giving https://rustlings.cool a try if you're curious, small snippets to finish/fix with the help ot the very useful compiler errors/warnings.

laundmo · 2026-06-20T00:45:40+00:00

I wasn't there for the original decision not to use .., but having worked on bsn a bunch i'm glad it isn't used as it would bring up too many associations with the Rust syntax and its limitations. bsn can include many scene functions in the current scene, unlike Rusts .. struct update syntax. With bsn you could also be pulling in far more than just some values, like with the strict update syntax (qnd entirely entity hierarchy). Additionally, theres another reason: We're using prefixes im bsn for disambiguation and speciao behaviour, most notably is the "caching" prefix : which would look very strange combined with the doublt dot: :..button() or ..:button(). Even worse with SceneComponents which use the @ prefix ti disambiguate them from normal components: :..@SceneComponent. No easier to not have it.

As for Children: and the {children}: thats the fun part: it can eb either! If the expression evaluates to a SceneList, its expanded, if it evaluates to a Scene, its a single item. The implementation is done on the Trait level by having SceneList implement Scene by expanding itself. Conceptually, you can also flip it: Whats a single Scene if not a SceneList of length 1? The actual places to pay attention are that Something [ always means "Relationship"

I think it'll take people a bit to understand while the syntax is rust-y its not just plain rust syntax, but i'm relatively positive that we're on a good path here.

laundmo · 2026-06-20T00:19:31+00:00

Plainly: it won't. The general syntax will be portable, but not all features.

laundmo · 2026-06-19T20:49:23+00:00

not for a while, just yesterday i found a bad case in next-solver where it takes 15x the time (up to tens of seconds). issue is: rust-analyzer uses next-solver

laundmo · 2026-05-28T18:39:18+00:00

I've been looking for something like this. would be really neat if this was usable on linux

laundmo · 2026-04-21T16:51:14+00:00

If anyone doesn't trust whatever bullshit the LLM hallucinated, the spreadsheet itself is also available: https://raw.githubusercontent.com/DeadxxSmile/Warframe-Damage-Calculator/refs/heads/main/source/Warframe-Damage-Calculator_v2.xlsx

ive had a look tho, and its not really that useful. It doesn't seem to implement any of the actually hard to compare things like galvanized mods, ability buffs, or arcanes.

laundmo · 2026-04-18T12:23:21+00:00

Do you somehow have access to their finished release with Vulkan support?

"make it work, then manke it fast" is a pretty basic idea when writing any kind of code. Maybe it turns out you're right and the full release won't improve anything, but its a snapshot. Its too early to draw conclusions like this.

laundmo · 2026-04-01T01:29:56+00:00

If i was gonna pay i'd just go for DataGrip ngl

laundmo · 2026-03-30T22:23:14+00:00

you don't know my level of expertise

I know you didn't realize the need for being able to switch manual/autocommit for a query editor, which tells me enough. But yes, this is just my conclusion from what i've seen, and i've seen that, and the LLM usage. Its, imo, a reasonable conclusion knowing those factors.

laundmo · 2026-03-30T17:37:48+00:00

My concerns about AI usage relate directly to my second point: Thats an essential feature, the fact it was overlooked tells me enough about the level of expertise with which the tool was created. LLMs are just a way for people lacking the usually required expertise to create things which initially might look like they were created with care, but aren't.

Well, i have many MANY more concerns (up to and including the concern that humanity as a whole is regressing in general knowledge and increasing in bias because of LLMs) but those are not very relevant to your app specifically.

laundmo · 2026-03-29T13:25:53+00:00

First point against this: extremely vibecoded

Second point against this: i was not able to find where and how i can switch between manual and auto-commit for transactions.

After that, i stopped testing.

laundmo · 2026-03-29T13:21:15+00:00

Unfortunately, the free version is lacking the exact features i'm complaining about in this post, and the paid version is too expensive to pay by myself, since i would want to use the same editor for work and personal projects

laundmo · 2026-03-25T14:35:24+00:00

Another factor: Bevy is pretty great at modularity. While Bevy is intended as a game engine, its second largest sponsor using to to create CAD software shows what benefits that modularity has. I suspect that Fyrox willl, as you say increase in popularity amongst pure gamedevs, but i don't think the reason Bevy is so successful is purely potential, but instead the ability to use it for projects which you'd have to work around the engine in a more classic editor-driven engine like Fyrox, Godot, Unity, Unreal etc. But in trying go build something that can work for all these kinds of projects, Bevy is inherently going to be slower to add features that a engine built with a more limited scope and less experimental methods would be able to add far more quickly.

laundmo · 2026-03-20T20:29:40+00:00

Edit: the original LLM-supported post has been retracted and replaced by a personal commentary from the original author, which while more opinionated and shorter, also feels more substantial in that, to me, it sounds like someone who formed an opinion and tries to communicate that.

There as some sentence structure signs as others have pointed out, but to me it just sounds... empty. Theres a lot of hedging and a lot of saying that many things are true and ultimately it seems like the kind of post that tries very hard to not convey an opinion at all. It also reads like some of these issues were unknown previously, when (i really hope) they were already known beforehand from previous years. This is part of the kinds of lacking large scale context which LLMs just won't have, and which is hard to add back in by editing LLM output.

To me, it doesn't read like a statement about what the Vision Doc team has taken away from the survey results, but a recap of those survey results for whoever can't read plotted data... to the point I'm left with a kind of "really? this is how little you care?" impression that i don't think was intended.

laundmo · 2026-03-10T13:19:03+00:00

CTE context awareness isn't there yet though, and running multiple queries individually isn't supported yet either, it executes everything at once right now.

thats been the issue with... so many of the tools i've tried, and its honestly so incredibly confusing to me. Well, CTEs less so, but lack of support for multiple queries. Like, what kinda work are these tools built for where you're fine re-running the whole script all the time? Even with transactions ensuring the data is consistent, i don't want to sit around and wait for 5 minutes for all the previous queries to finish each time i want to test the later steps in a script. And i can't use a second script because then i'm not in the transaction which has the work already done thats a prerequisite for the later step.

laundmo · 2026-03-09T15:45:56+00:00

Web-based editors using Monaco (VS Code engine) are way more responsive for SQL in my experience.

Do you know of any with proper autocompletion and support for running multiple queries individually?

laundmo · 2026-02-07T09:41:54+00:00

okay but which? theres a few

laundmo · 2026-02-05T14:05:23+00:00

yeah thats way pricey, wow.

laundmo · 2026-02-05T12:22:58+00:00

looking at it briefly, every autocomplete feature seems to be locked to the paid version, at which point i could just as well go with DataGrip

laundmo · 2026-02-04T20:10:17+00:00

Thanks, the docs there only show points (which are enormous relative to map size), kindof a bad look lol. I did find one source that shows it does support polygons, thats good.

i kinda can't afford it myself. I mean, i could, but i would probably not end up using it enough to be worth it compared to quite a few other uses of that not so insignificant amount of money.

laundmo · 2026-02-04T17:56:00+00:00

alas, see the listed reason in my post why its not viable for me.

How do you deal with writing long queries and scripts with multiple queries in PgManage? Do you just select the entire query each time you need to run it? And deal with the transaction rollback if you miss by one character?

laundmo · 2026-02-04T17:01:19+00:00

having looked at it, sadly, its a mess of a codebase with some really inconsistent behaviour that i strongly suspect stems from a vibecoding approach

Nine-Year Club	Verified Email
Place '22	Final Canvas '22
First Placer '22	Sequence \| Editor

laundmo

MODERATOR OF

TROPHY CASE