CupricTea

People should be giving more credit to Bevy regarding Tiny Glade, particularly the people who like to bring up Tiny Glade's custom renderer to detract from Bevy's accomplishments and capabilities. It takes substantially more software infrastructure to make a game engine than just the renderer. Looking through Tiny Glade's third party licenses, the following are listed:

  bevy_app 0.17.3
  bevy_derive 0.17.3
  bevy_ecs 0.17.3
  bevy_ecs_macros 0.17.3
  bevy_input 0.17.3
  bevy_macro_utils 0.17.3
  bevy_math 0.17.3
  bevy_platform 0.17.3
  bevy_ptr 0.17.3
  bevy_reflect 0.17.3
  bevy_reflect_derive 0.17.3
  bevy_state 0.17.3
  bevy_state_macros 0.17.3
  bevy_tasks 0.17.3
  bevy_time 0.17.3
  bevy_utils 0.17.3

The fact that Tiny Glade was even able to just turn off Bevy's renderer while keeping the entire rest of the needed infrastructure so that they could write their own custom renderer on top of it is nothing short of remarkable.

Learning lifetimes in Rust I've found to be quite like when I first learned pointers in C/C++. They're the hardest most enigmatic thing in the world until at one point something suddenly "clicks" and they just make sense, and you'll wonder how you ever struggled with them in the first place.

For me the actual toughest thing to learn were procedural macros, and the reason for that is because actually implementing them is more on the niche side of programming compared to using them, so most "learning Rust" resources just hand wave them away, and their usage is so special cased that all the limited learning resources around them target specific niche use cases that might not be what you in particular would use them for.

Imagine my dismay to find out Crunchyroll does not offer Japanese subtitles for anything.

Netflix is a little better in this regard, but Neflix in particular goes out of its way to obnoxiously clutter the screen when I pause...even though I paused specifically to try and read something on screen or mine vocabulary from subtitles.

Title should be changed. Async Rust != RTOS. RTOS's are preemptively multithreaded while async is done cooperatively with yield points.

Perhaps "Embedded async Rust vs. C RTOS"

I can't help but think at this point that Ghostty's "departure" from GitHub is unserious. It's been two and a half months now and not even a single peep of discussion about where they may be migrating to or what they may be doing.

I'm honestly a bit shocked this was done entirely using declarative macros. Normally when I see such arbitrary syntax I assume it's implemented as a proc macro.

I cannot overstate how huge and exciting bsn is for bevy. This is as big of news as when bevy itself was first announced six years ago.

I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex<T> and enough operator overloading to type vector expressions like a human being.

I was just in Europe this February. I took a bus from France to Germany and customs checked the passports of everyone on board.

>who want zig to "win over rust" for whatever reasons

I don't understand why this mentality is so common. Zig and Rust are both fine languages with markedly different design goals and they can coexist.

Rust has never been about outright eliminating unsafe code, it's about encapsulating that unsafe code within a safe externally usable API.

When creating a dynamic sized array type, it's much simpler to reason about its invariants when you assume only its public methods have access to its size and length fields, rather than trust the user to remember to update those fields themselves.

The above is an analogy which is obviously fixed by using opaque accesor functions, but Rust takes it further by encapsulating raw pointer usage itself.

The whole ethos of unsafe Rust is that you encapsulate usages of things like raw pointers and mutable static variables in smaller, more easily verifiable modules rather than having everyone deal with them directly.

>when you a pass a pointer to my function, do I take ownership of your pointer or not?

It's honestly frustrating how prevalent this is in C, and the docs don't even tell you this, and if you guess it does take ownership and make a copy for it and you were wrong, now you just leaked memory, or if you guessed the other way now you have the potential to double-free it, use after free, or have it mutated behind your back.

I remember talking about this concept with my brother a while back. Since LLMs have no neuroplasticity, they are locked in to what they were trained on in the time they were trained in. A model trained in 2026 would stay exactly the same for use by someone in 2126 to gain an insight on our time. Like a book that you can actually talk to.