A parasite leaches off it's host to the hosts harm. Maybe it's not a good analogy, but Im in china, and it's painful after paying money for a VPN to bypass censorship to find myself routinely blocked by CDNs because they decided I'm not human. I'm honestly feeling more opressed by these middlemen than the government sometimes. For example, maybe I can't log in to a game due to being blocked by the login API, and the game company just responds by telling me to run an antivirus scanner and try again since they are not personally developing that system that lack awareness. Such people with genuine need for VPNs and privacy tools are the sacrifice for this system.
The article states that he previously said he was going to keep going until he passed away, it he suddenly announced it at the end of the meeting without anyone except his close family knowing.
As a casual onlooker, reading blog posts here and there, it's evident the topic of Rusts' suitability for game development is a hot topic of discussion and research. Sometimes it feels there is a sort of existential dread coming with the thought that Rusts' design maybe simply makes it too much of a pain in the long run in attempt to force code to comply with it's required way of thinking.
Do you ever find yourself wondering if its the right path to commit to for future games?
The strong criticism Rust got in this area is being poorly suited for rapid throwaway prototyping. I think that's fair — slow compile times and language's focus on writing things properly on the first try are the opposite of what you want when trying out random ideas and seeing what sticks. I think that may be fixable. Partly it's a skill issue (with enough experience, you can cut corners when you known which ones to cut). Partly it could be improved by tooling for hot reloading, and perhaps a scripting language integrated with Rust.
In Bevy in particular almost everything happens through ECS, and the ECS has a Reflection API, so you can hook it up to whatever you want, and manipulate it from any language.
I also wonder what about the rest of the game development lifecycle. Games are taking many years to develop, and not all of that is quick exploration. The more of the game starts taking shape, the more you actually need stuff to work. You need ability to refactor, polish, and extend the implementation without breaking things. You need to be fixing gameplay bugs, not wasting time on hard-to-reproduce crashes.
I personally love working with Rust. I think it delivers on the various buzzwords that made it popular. In general when people critique Rust in this context, it comes down to:
1. Rust's ownership / mutability features
Bevy ECS specifically alleviates a lot of the ownership problems that newbies often encounter in Rust. It doesn't solve _all_ of those problems ... there are definitely still UX rough edges. This _will_ be a sticking point for some people. The cost / benefit here is also hard for newbies to evaluate, as it is a _very complicated problem that requires years of experience in the space_.
From my perspective, the cost is worth it. Strict mutability and ownership rules allow us to parallelize everything safely and automatically. Strict mutability allows us to (via the DerefMut trait) _perfectly and automatically_ detect all changes to components and allow developers to react to them. This is something that is unique to Rust, at least in the mainstream. You will not find this type of feature in ECS-es written in other languages, as they literally don't have the semantics to globally distinguish between a read vs write pointer deref.
Opt-in garbage collected ECS is something that people are experimenting with in Rust right now), which would allow people to define "do whatever you want" code.
And _right now_ you can always just use Bevy ECS's unsafe api variants to do whatever you want when the "safety" isn't worth it to you.
I value what I like to call "progressive disclosure of complexity". I want people to be able to quickly and easily use the tools I build without much experience. And as they gain experience, I want them to be able to seamlessly dive further down the stack. I believe Rust handles the encoding the "low level" stuff better than every other language, both by more accurately modeling system constraints and by protecting people from doing the "wrong thing". It also allows you to use those low level pieces to "climb up" the stack until you have something like the Bevy API.
Unlike most engines, in Bevy you can start "at the top" in your program, hit F12 in your IDE to "go to definition", and keep going until you hit the core language APIs. And _then_ you can hit F12 one more time and go into Rust's source code. This experience is extremely empowering, coming from engines like Godot, which have a "high level" API with a "hard cut" before you go into the engine with a completely different language and paradigm (and no good way for your IDE to bridge the gap).
Bevy (and Rust) are for the developers that care about understanding (and controlling) their tools from top to bottom, and are willing to undergo a bit of initial pain (relative to scripting languages) to make that happen. Rust is not a perfect language and it isn't the best "constraint solve" for everyone. But I am most interested in building a holistic experience that empowers people that value that kind of thing.
3. Compile times
Rust compile times can be long if you aren't intentional about it. That being said, Bevy is built in a way to make compile times reasonable. With our "fast compiles" setup (see the getting started guide on our website), I can compile a change to our examples in ~0.5 seconds. Thats close enough to "instant" for me. The trick in general is (1) make sure you aren't writing code in a such a way that requires recompiling EVERYTHING (2) use dynamic linking for large deps (we do this for you in Bevy via the dynamic_linking cargo feature) (3) use a fast linker (covered in our guide).
Ensuring you follow principle (1) in large projects is a skill that needs to be honed. But on the Bevy side, via our opinionated Plugin structure (and dynamically linking those plugins), I think we can provide bounds that discourage people from shooting themselves in the foot.
I will close by saying that it is worth thinking critically about what tools you use and not following hype trains blindly. Picking Rust _and/or_ Bevy for your project _is_ currently something that many people should not do. However I think that Rust and Bevy are both VERY good tools that will be right for some people. And due to their "carefully and seamlessly climb up the stack" approach instead of "riskily climbing down when necessary", they have extremely solid foundations, and their user experience improves constantly. They are both increasingly suitable tools for more and more categories of people, and I expect that trend to continue.
I heard syncthing has recently given up on developing the android app. Unfortunately the filesystem in android has become more and more restrictive so using an app to manage files globally that reside in each individual apps container is becoming more difficult. i onced synced 70k small files to android and it took 2 months to complete due to the virtual filesystem.
Manny people mistakenly recognise Bopomofo as katakana. I use bopomofo and get this reaction a lot, it just have to mention its actually bopomofo/zhuyin and then they know what it is.
I can't remember enough to say, but it certainly emphasis the interactions and feelings between different characters. The story has an initial ending, and then a continuation which focuses on therapy recovery from all the psychological damage inflicted to the characters. Lots of dialogue
I once saw a video of a highly aerodynamic solar car. Due to the high laminar flow of the air around it bugs would just go around the car. Perhaps this also causes modern cars to splatter less bugs.
It very much doesn't work like that. I work on Guix a little, and I remember someone saying ~5% of packages were broken at any given time. there is something of an equilibrium between packages breaking due to changes and someone fixing them. Packages are also not truly functional in the functional programming sense. For practical reasons, Nix/Guix just try their best to remove as much state as possible to make things behave consistently. But for example, the number of cores available is different between different machines and race conditions can occur.
I heard from an Anton Petrov video it would reduce the planets average temperature by half a degree for some time, but I don't know where he got that info from.
It's possible that estimate was based on the eruption size, not the SO2 amount. It seems that the amount of SO2 emitted wasn't that much, so maybe something much less than 0.5 degF.
reply