> It might not be obvious how much effort it takes to manage bugfixes in dependencies where every few weeks there's a new breaking API change in egui/winit/wgpu, and while these probably seem extremely minor to those who spend all their time building an engine on top of said libraries, sinking a day or two in figuring things out and fixing stuff on every release is a gigantic waste of time in my view.
That's insane. For comparison SDL does breaking API changes every ~10 years (and they implement the previous version's API as a wrapper around the current version's API to support legacy software). Maybe the egui/winit/wgpu devs just expect that every end-user will just pin their package versions for the duration of a project, but it seems like a real burden for devs of libraries like Comfy that depend on them.
The entire Rust ecosystem for gamedev is kind of like that - it was only recently that people really started writing games entirely in Rust, and even now there are very few actual released commercial games out there. I think there's a bit of a loop happening where it's like, until Rust is considered "stable" for serious gamedev work, libraries will be developed in this kind of "unstable" way where breaking changes should be expected at any time, but at the same time, that instability is making it less of a serious contender for gamedev work.
Forget about gamedev. An anecdote: a friend wrote a personal Rust project which purely works with website's APIs and some minor file operations (basically a scraper).
And I, as his only user, have to constantly update my local Rust installation to newest dev to be able to compile his newest code base.
I understand it's more about him being on edge than the language itself alone -- but it still feels insane for me. In most of other languages, you can't make your code so backwards incompatible even if you actively try.
It's not more, it's 100% on your friend, I'm afraid. One is not supposed to jump to the newest version every time simply because one can. Updating the minimum supported Rust version is a breaking change that should not be done lightly.
> Updating the minimum supported Rust version is a breaking change
This is not the majority sentiment, for better or for worse. The project stopped releasing "what version of Rust do you use most" in the survey results in 2020 (which is a shame, imho) the vast, vast majority of folks use the latest stable, and very few use a previous version of stable. I have no real reason to believe this overall trend has changed since then.
This is especially true for an application, which this project seems to be. Libraries may have more of a reason to explicitly lag behind the latest, but there's not really a good reason to bother if nobody else is going to depend on your code.
That makes sense to me. I usually use asdf to version Rust in personal projects, so I'm not always on the latest. But when I work on a new release I'll almost always update rust and any of my other dependencies, as I'd otherwise never keep them up-to-date. Or if a new language feature I want to try just came out.
And God forbid you fall behind on React Native major releases in a project. I think the Expo project's solution to this is for all of the native configuration be done via plugins and cross-platform config[0]. Otherwise you'll be dealing with large diffs of native Android/iOS code that would have even native mobile devs tread carefully.
[0] https://docs.expo.dev/workflow/prebuild/#sensible-upgrades
> Updating the minimum supported Rust version is a breaking change that should not be done lightly.
Someone should tell that to Rust library devs, because from what I understand, their packaging ecosystem pretty much always assumes that all libraries are running on the latest version of Rust.
There's no "commonly used versions" or LTS builds for Rust, so it seems that every packaging maintainer just supports the latest and everyone is up shitcreek if a new version changes and hard breaks code for older Rust. With how micropackage oriented Rust is, you practically can only jump to the newest version if you want your builds to keep working since I doubt you'll be using stdlib-only Rust.
Compare and contrast every (anecdotal) Rust users favorite bugbear, Python, where if you're building a library, it's pretty commonly assumed that you can follow one of the two major deprecation points for Python versions (end of bugfixes or end of security updates), which means most major libraries usually follow one of the two for the internal features (and therefore lowest version) they use.
I've only done a few hello world style projects in rust, and my python experience is also almost 8 yrs ago now, so I might be wrong... But doesn't rust pull it's dependencies as bytecode vs python (which is a script language at its core) that pulls the source code?
The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...?
I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally.
And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now.
And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style
Crates.io stores packages as source code.
Rust does not have a VM, and doesn't use bytecode.
That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.
> Updating the minimum supported Rust version is a breaking change that should not be done lightly.
Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.
It is also about how easy rust makes it to use libraries, and depend upon external libraries as a part of your public API. C in particular makes this pretty inconvenient,
so a lot of projects include data structures and things that otherwise might be pulled in via library themselves. That lends itself towards less reliance on external deps but also more internal stability.
At the very least I can say, that experiences I've had that are common in rust, where I have dependency X needing to be upgraded in lockstep (the same version) across multiple external dependencies with different maintainers. Are things that I've basically never experienced with C based languages.
At least I don't think it is just that things need time to stabilize, but also just the packaging system causes network effects which you don't get the joy of experiencing if you don't have one.
Well. Rust has lock files, so breaks will only happen when you decide they are allowed to happen, by running cargo update.
In C they also only happen when you update the dependencies you have.
Granted, Rust makes it easier to pull on dependecies, but it also makes it easier to keep them up to date.
> Rust has lock files, so breaks will only happen when you decide they are allowed to happen, by running cargo update.
great in theory but ``cargo install`` will straight up ignore lockfiles by default[0], meaning trying to install a binary package is a roulette of "did this tiny package update before everyone in the dependency tree noticed"
[0]: https://github.com/rust-lang/cargo/issues/7169
This is the right answer. Crates.io comes with a whole mixed bag of experiences. Increases initial project development velocity at the expense of long-term velocity (and sanity). After 2.5 years of doing Rust full-time it's the one thing I'd look back and say I'd rather see done entirely different.
What do you think some of the alternatives for library distribution and management are that would be more successful. I am an unabashed proponent of the C style manage t dependencies yourself in a manner consistent for your own work, but many people are 100% adverse to that position. Do you think a middle ground would be possible?
Then vendor your dependencies in Rust. If you don't want libraries to change and the depenency maintainer won't commit to stable API, you have to vendor it.
I am currently working on a Rust project of about 70 crates that builds with Bazel. I ended up with vendoring everything because of very subtle bugs in rules_rust for Bazel that caught me off guard and seem to happen on non vendored deps. Fun fact, all Rust code in rules_rust is vendored by default so it's clearly the way to go.
Also, previously I had weird quirks occuring randomly, but after having switched to vendored deps, everything works stable, reliable, and as expected.
I don't agree with the fast pace of how often certain crates produce breaking changes, but I found that with Bazel at least stuff works all the time regardless. Also, builds are noticably faster because downloading and building sub dependencies can take considerably time in large projects.
I prefer "vendored" self managed dependencies as well. However the Rust ecosystem will fight fight fight you in this regard.
I am leaning towards starting future Rust personal projects on buck or bazel or gn, instead of Cargo. And checked-in vendored dependencies.
It's not a popular position, but I have seen the crates explosion in larger projects go so wrong... And 10 years at Google taught me that vendored third party deps is an entirely reasonable approach for that.
Cargo includes a vendor command. You can do the checked-in vendored dependencies if you'd like.
That said I am intrigued by using buck more as well, though I haven't been actually doing it yet.
The vendoring support in Cargo isn't really what I'm looking for. It's more "download all my deps from crates.io and make local copies" and it has various limitations I kept running into which I don't have time this morning to go back and document. It really felt like an afterthought and not at all like the third_party workflow that people who have worked with the Google monorepo would be used to.
I am interested in what vendoring means other than “put all of my dependencies’ code in my repo” but if you don’t have time, that’s chill. I’ve only seen open source projects using buck/bazel and haven’t ever seen google3, so I’m sure I’m missing something.
Not OP but a difference is in who manages the updating of a vendored dep. You don’t want to update every time there’s a release, but you don’t want to never update either.
If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event?
If vendoring just means we periodically pull a copy of upstream into our repo then you can have unbounded time when you don’t know there’s a vuln and therefore haven’t considered whether you need to act.
This is obv different from the situation where we all just cargo install (without —locked) and different from c style dep mgmt where we get sec fixes for many libs via our OS patching.
> If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event?
You still retain the Cargo.toml and Cargo.lock, so the exact same way as if you didn't vendor: `cargo-audit` would inform you, you'd update the version, and re-vendor.
It’s not how do you do that, it’s What (systemically) triggers you to do that?
Are some developer(s) on the team responsible for subscribing to the relevant vuln lists and scanning them each day? Do you buy in some tooling?
The cargo-audit I referred to in my previous post is that tooling, it's commonly run in CI regularly.
But, also, this is pretty far afield from my original question: I understand why keeping copies of your dependencies can introduce various things you should handle, but my original question was "what is vendoring your dependencies if not 'keeping a copy of the source code of your dependencies in the repository'"? That's my understanding of the definition of "vendoring," so I was curious what my original parents' definition was.
There's nothing preventing you from using the defined-by-spec-but-not-actually implemented C++23 methods, either. You can write perfectly spec-compliant C++ code that will only work on the latest version of MS C++ because other compilers don't support the feature yet. Shortly after new C++ specs are released, it's even possible to write spec-compliant code that no production compiler can even compile!
It's just that developers in the slow languages don't do that often.
With the guarantee to be able to build older projects (version specified in the Cargo.toml file) and only one real mainstream compiler (the "can compile code but lacks any of the language checks" GCC version doesn't really count), there are few downsides to always having the latest compiler, something other languages sometimes struggle with.
Coming from Rust, I made the foolish mistake of installing the latest Clang and GCC, only to find out that tons of software suddenly stopped compiling because apparently the code requires old compiler bugs/features to work (that are not emulated in newer versions). I've had similar issues with Java, where JRE 17 or 21 could not compile Java 8 projects without modifications to the project because of the new modules feature.
In an environment where updating your compiler toolkit is basically worry-free, it's a lot easier to use recent or even unstable functions. This invites developers to make use of recently added APIs, whereas developers from other ecosystems will wait months or years before even considering new APIs that have been stabilised.
I don't understand, it's recommended practice to update your Rust install to the latest whenever there's a new version, because Rust itself is wholly backwards compatible, so 1.0 code should continue to compile with whatever the latest version is. Are you saying the libraries he's using are deprecating functionality instead of the core language? If so, then yeah I've had that issue too with certain libraries like clap.
No, he’s saying his friend sees a new, shiny, just stabilized function in the standard library and first thing they do is jump to using it
I mean, so what? I think in actuality what they're implying is that one shouldn't update Rust to latest, even though that's the recommendation. So it shouldn't matter what the friend does, as long as they're always on latest Rust. In fact, the friend is in the right, in this scenario.
> I mean, so what?
That mindset leads to the start of this thread:
> It might not be obvious how much effort it takes to manage bugfixes in dependencies where every few weeks there's a new breaking API change in egui/winit/wgpu, and while these probably seem extremely minor to those who spend all their time building an engine on top of said libraries, sinking a day or two in figuring things out and fixing stuff on every release is a gigantic waste of time in my view.
But not really, because the person we are talking about is, if I understand correctly, a user of the software their friend wrote, not someone who is implementing any features themselves and thus needs to rely on a stable API. All they need to do is to update their Rust version, which is really the same as any other software that must update over time.
This same sentiment is also echoed by Steve Klabnik here [0], it seems.
[0] https://news.ycombinator.com/item?id=41488337
Can't agree because updating code to utilize new shiny features frequently impacts those who use the code because of leaky abstractions. Or even deliberate breaking API changes to accommodate said new language features.
As I said, the mindset.
How does it impact the user? Again, this is an application, not a library, so I really don't see how, just as using some desktop application that the developer updates should not affect the end user themselves. If this indeed were a library, then sure, I'd agree, but by my inference, it does not seem so.
The rust ecosystem is young, most of those libraries haven't even reached 1.0.
Basing any serious project on 0.x libraries is always subject to this issue.
On the flip side of this, when libraries in rust do reach 1.0, they often are just done. The serialization/deserialization library serde which has become the de-facto standard has been on 1.0.xxx for the past seven years. https://crates.io/crates/serde/versions
I think this speaks to rust's strengths in that if you know your spec, you can write a rock-solid version of it - and its weakness, where if you don't know your spec you'll be making breaking changes a lot.
> Basing any serious project on 0.x libraries is always subject to this issue.
So I guess I'll hold off on having random numbers in Rust then [1].
[1] - https://docs.rs/rand/latest/rand/
It's already at 0.8, just another 20% and..!
I'm always puzzled with people saying that things move too quickly and that they fail to keep up, in any language. Why do you guys even try to keep up in the first place? Unless there's a bug in a dependency you're using, if version 0.4 works, you don't have to use 0.5 or 0.6. Or maybe there's a new feature that you need in the newer version, then you can afford to spend time doing the migration but in this case you should also be happy the the pace of development is fast because that's how the feature ended up landing in the first place.
For most use-cases, it's fine to stay on out of date libraries for years, and that's what the Linux distros do all the time (mostly patching crippling bugs and security vulnerabilities).
90% agree. The scenario that I've seen that messes with this is when you include lib x which has dependency on version 0.5 of y, but your code depends on version 0.4 of y.
cargo handles this just fine, unless you get lib y objects through the lib x api
I believe a post from one or two weeks ago showed it seems more of a systematic Rust ecosystem problem.
What, exactly, is the problem? That libraries/projects remain below 1.0 for too long? Because lots of breaking changes before a 1.0.0 release is to be expected for anything following semver (which as far as I know, most if not all of the Rust ecosystem uses).
Things move quickly because there is so much development being put into these base libraries. Which is of course a blessing and a curse.
I cannot find the article right now, but it was a wonderful piece on why a language like Rust is by design incompatible with the whole idea/process of making games. (I hope it rings a bell for someone who can find it.)
It went something like this: you start with a nice little tidy spec for basic arithmetic; how "a + b" must be the same as "b + a", etc. Then the designer comes back to you and asks for the ability to make numbers blue. You're like wtf but ok, when you add a blue "a" to a non-blue "b", the result becomes blue; you must remove half of your tests (because they no longer even apply) and rewrite the other half to match the spec, and a week of work later the result somehow still makes some mathematical sense. Then the designer comes back to you with the request to make even numbers shoot sparks on death, and to remove all fives...
And it's just how it goes. Games need to be iterated on quickly and efficiently, with a tight feedback loop on what ends up being fun during playtesting, and what doesn't. Rust might be great for writing low-level code / engines, but it will constantly get in your way where you need to respond quickly.
It is from the same author, they link it on the readme.
Interesting because there was a rust keynote by kyren arguing the exact same thing for why games were a poor fit for OOP/C++. Arguing for data oriented which rust does well. ... or C I suppose.
It might be that rust ecosystem this dev was dealing with was itself draining with continually shifting APIs, but that's not the same as the language itself.
https://kyren.github.io/2018/09/14/rustconf-talk.html
wgpu only got the first non-0 release this July and started 4-ish years ago. They didn't even have a chance of taking 10 years. I'm sure SDL wasn't very API stable in 1998.
4 years after starting SDL was already deep into 1.2, which is the API that's still supported today via sdl12-compat (and the original codebase as well, which is still maintained even though it's deprecated).
Some crates are better than other.
For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible.
We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.
I sat down one weekend to try and make a demo in Bevy. The ECS system was cool, it's almost like querying a database. However every tutorial I found, even the most recent ones, were already outdated. They had just moved from 0.14 to 0.15 which broke a ton of things. I opted to mess around in Godot instead.
Exactly, this is poor SWE. If you need a new feature from a latest rustc or an upstream, and can stomach losing users, then perhaps you mark things #[deprecated] for a release or two (which should be months, not days).
AND don't bundle bugfixes with API breaks if it can be avoided.
Otherwise, just don't bother!
This is hype-driven development at its worst.
I'm by no means a Rust fanatic, but I've had quite a different experience to many of the other commenters (especially around libraries etc) and I thought I ought to share it.
My background is as a generalist full stack developer using Node, Python and similar things. I have used C but only deployed one very small thing in production. I have managed devs using C++ but I took the view that I wasn't up to coding C++ for production (more or less Pit of Failure vs Pit of Success thinking).
I started a commercial project some time ago which required one application (think data ingestion) to be high performance. I decided to try Rust and these are my observations:
1. I was able to learn Rust while writing a daemon/service application which performs well and is robustly handling millions of "objects" per day for the last 6 months. I don't think I would have managed this with C++ without blowing my own foot off several times.
2. Library support for everything I needed was excellent. I have yet to experience a breaking change since starting the work more than a year ago.
3. Library devs have been very responsive and chatty about problems etc...
4. Really enjoyed working a strongly typed and compiled language. Bugs are bugs, but I realize that I've had a habit of just spotting problems in production after the fact and fixing them for things that just shouldn't happen. It's like DB integrity once you get used to it, it makes you feel a lot better.
5. Syntax is ugly as all hell.
6. Async / Tokio stuff makes you feel like you have no idea what's going on.
I think somewhere between the "Rebuild it in Rust" and "Rust is a horrible Deadend" there is a real opportunity to have a solid language which can allow devs of my level build decent software.
For certain things, Rust is painfully slow with no real benefits. We are starting to learn where we should and should not use Rust. If you ask me, Rust is becoming the new Ada.
Update: when I wrote slow, I meant development pace, not runtime performance
The author has one major issue with Rust in gamedev: they can't easily try out new game feature ideas or gameplay tweaks by writing quick and dirty code.
Such unfinished code can be obviously buggy and unsafe, but in game dev it matters more to have short feedback loop to try how things feel, than to have a perfectly correct code all the time.
Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
This is a substantially different situation from other domains like application and services development, where it's easier to plan what you're going to implement, correctness is more important, and you don't need to try out 20 different JSON parsers to see which one has the most satisfying feel.
C++ doesn't do quick and dirty either. That's why experienced game developers combine a core engine written in a high-performance language (C++, Rust, C#), with a scripting language (Lua, Python, hand-rolled).
That approach gives you the best of both worlds: high-performance core with high-velocity iterations for gameplay. Don't use Rust or C++ for scripting... madness lies that way.
C++ will easily let you write non-thread-safe code anywhere, won't complain about multiple mutable pointers to the same object, will let you leave pointers dangling and resources leaked.
Such code is of course crappy, but the OP wants to test if things are fun before committing to implementing them properly. Rust wants things done properly on the first try (which usually is a good thing, except throw-away prototypes).
https://loglog.games/blog/leaving-rust-gamedev/
"C++ doesn't do quick and dirty either."
You can do very easily do quick and dirty in C++. (And shoot your foot off also..but that's a different thing)
It also introduces a lot of complexity where the two languages interact.
Except hot code reloading and interpreters is something that C++ devs can reach for, and Rust ones not, at least for the foreseable future.
This the bare minimum, https://liveplusplus.tech/
Also supports is kind of relative,
"CHR is very new and experimental feature of the engine, it is based on wildly unsafe functionality which could result in memory corruption, subtle bugs, etc."
Why is that the bare minimum?
I also think that doc page is a little old. The feature is over 2 years old now and hot reloading is inherently "unsafe" in any compiled language. It's just letting you know that Rust's safety guarantees might go out the window if there are bugs in the code that handles hot-reloading.
Because that is what existing game studios expect, as shown by their customer list.
Also that was only one example, there are other similar ones.
That live reload probably already works with Rust — they say they don't parse any source code, and instead analyze the compiled binary and debug info.
> Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
The problem might just be an aversion to using quick and dirty solutions. Rust does a good job of making it feel wrong to write code that's not production ready, but there's nothing stopping you from using unsafe wherever you want.
Disclaimer: never actually shipped a game.
I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major "downside" you need to account for is that the type system will try to prote you from crashes. Which can be a bit of a chore since youknow it won't crash with the values you've given it. But if you're comfortable with .unwrap and the occasional unsafe while prototyping, it's honestly fine (at least within Bevy).
Alternatively, they could try "scripting" behaviour first before implementing it in Rust, although from what I understand bevy's scripting support (I don't think it's explicitly supported, but bevy is very extensible) is still very early in development
ECS is like a whole another language on top of Rust, and it is dynamically typed.
If you add a scripting language and blueprints, you're shortening the feedback cycles by using Rust less.
I like Bevy, but it seems like Rust currently is much better suited for making game engines than the games themselves. Some "RustScript" is needed.
> ECS is like a whole another language on top of Rust, and it is dynamically typed.
Can you elaborate? Or did you mean dynamically dispatched?
1. You dynamically add components to any entity, so entities don't have a static type. Semantically they're comparable to a JavaScript Object where you can add and remove properties at will, rather than being structs or class instances with a closed set of fields.
2. Bevy's entity references are generational IDs, without static lifetime guarantees (and restrictions) of Rust's references.
> so entities don't have a static type.
They do, they're `Entity`, always.
> where you can add and remove properties at will
I don't think this is true for either `Component` or `Entity` in Bevy. You set what fields a `Component` has when writing the code, then it remains so during the runtime. There is no dynamically adding/removing fields at runtime, at least yet.
What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime, is that maybe where the confusion comes in?
I think they used it more as an analogy: components fill a similar role as properties do in JavaScript.
But that's not really true either, is it? You don't query properties in JavaScript, at best you query for Objects of a certain shape/name. You don't encapsulate data in properties so one object has many different behavior based on those, you either split the Object into many different ones and have one parent, or you mix the behavior into the same Object.
Yeah I it's not right. Although, it's a decent early mental model for a JS dev learning ECS to adopt until better intuition develops!
Something wrong with Lua? ;)
A lot of big expectations were placed on Rust; plenty will have turned away and decided the trade-off on development velocity wasn't worth the guarantees of memory safety or the promise of zero cost functional abstractions; not to mention it still requires expertise to write something performant. I've certainly done it myself, dipping my toes in the water out of curiosity and realising it wasn't what I needed.
Many people here say that languages like Ruby or frameworks like Rails are dying, or some such, but in reality these languages just carve out their space, settle into it, and become the go-to choice because there's nothing surprising about them any more. If Rust can be considered stable or boring in this way then it will have succeeded where a lot of new and novel languages tend to fade into obscurity.
Thing is, if one can tolerate automatic memory management (regarless of the form), than the guarantees of safety are already there, with faster compile times.
It is already great that it managed to bring affine types into mainstream, making many programing languages designers consider how to integrate similar capabilities into existing languages, and maybe put some pressure on WG21 to take security more seriously (I remain a dreamer).
Outside very specific use cases, we already have Ada like safety on programing languages with automatic memory management.
Watching people try to force Rust adoption everywhere over the last decade has been watching a car crash unfold at 0.00000001X speed.
For what things Rust is painfully slow? You mean runtime or build time?
Build times are a bit slow, but runtime is just as fast as what you'd get doing the same thing in C or C++.
Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic.
> Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic.
I don't mean to be dismissive, but if this was really true we'd all be writing TLA+ specifications/Coq proofs before finalizing our Ada SPARK implementations. In reality, static analysis only improves development time if time_lost_to_debugging > time_lost_to_arm_wrestling_compiler, and in my experience that's not always as common as one would like to believe.
If you're wrestling the compiler, you should improve your programming skills before trying to analyze programming languages.
Ah yes, I'm sure that all of your Rust code compiles the first time :^).
> focus entirely in your code's logic
That is if your code satisfies the borrow checker out of the gate, fine. I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not.
It's been a while when I worked with Rust, but when I did I felt like people are misusing Rust references. IIRC, they are supposed to be short-living, i.e. you get a reference, you do your thing with it and then you get rid of it asap. For actually long-living references Rc<> should work pretty fine?
> I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not.
What are you referring to here?
Just learn how to program without mutating things unnecessarily, it isn't that hard.
Looking at Rust from the outside, I see the borrow checker as something I might slam into all the time, but if it’s all static, then it’s strictness I can get used to; “if it compiles, it works,” right? But now I’m reading that there’s a dynamic borrow checker too, and I’m left wondering: does rust really crash at runtime if two scopes reference the same field at the same time? That sounds like the kind of infuriating footgun as NPEs in a non null-safe language. Does it really work like that?
The borrow checker is fully static.
There are types in the standard library that, if you use them, do runtime checks. If you run afoul of those checks, then yes, you’ll get a runtime failure. (The primary example being RefCell<T> linked in the article linked there, yes.)
These types are not super common in Rust code generally, but they do exist and are useful at times.
The "dynamic borrow checker" is called a RefCell, and it's a footgun you have to explicitly point at your foot and pull the trigger, not something you'd randomly stumble upon. It's something you'd use very situationally, after you really considered all your options and found out you couldn't do it by writing normal code instead, and this is a very rare situation.
Think of them like Python's metaclasses.
When the borrow checker doesn't let you compile, it's either because it can't understand your code (and that's unfortunate and infuriating and costs a lot of time to figure out), either because your code won't be absolutely safe (and so you'd better listen to the BC instead of complaining about it).
rust can be very frustrating because it forces you to think up front at a level of safety you may not be used to. That's the issue.
I do fairly simple things with rust (i.e. just some threads, no complex data structure (but complex program nonetheless)) and rust safety helps me a lot in reducing the number of bugs.
I think the jury is still out on the development time.
Sure, once you get your code to compile things may go faster. But getting there is not always easy.
>Development time is absurdly faster
That definitely sounds like you have never made/contributed to anything non trivial that's made in Rust.
Development time is significantly slower for any non toy project where the problem domain hasn't been solved/the person/s don't have experience with.
>"Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs,"
Utter BS. I mainly developing in C++ at the moment (not limited to this single language though) and I do not find myself debugging "language-design bugs". I do not design libraries hence my code and set of used language features is of course simpler. I tend to avoid esoteric code and do not have habit to shove everything into new templates.
Development time is my guess
This. I assume it's a similar argument as the one presented in https://loglog.games/blog/leaving-rust-gamedev/
Edit: I just noticed that this article is also writen in the archival reason. I'll leave it here anyway for those that miss it.
Yeah the Rust build time tradeoff for non-trivial programmes is acceptable iff the programme is going to be run at least 100x more than the compiler (or if the programme would be useless without the speed increase).
My Productivity tanked when using Rust but I have not written 20k Loc yet. Ownership gets messy when you have a complex mutable application model (worse: oop written according to SOLID principles). At that Point,Just give Up and use ref counting (which you would use in c++ anyway..).
I still like to believe that the upfront cost will be offset by the lower long term maintenance cost for some types of software. Except, that that is not always the case for gamedev where shitty code can still make good and successful games. You may miss a deadline, but if you are not going to maintain the code base for 20 years, so why spend the effort on quality code?
Every time someone on Reddit or someplace asks "What's the appeal of Ada anyway?" I say "Think of Ada as boomer Rust."
It turns out that when you need to get the details right and be safe in a systems level language, development can be slow. This is a good thing. Studies with Ada projects compared to C have shown that time and money is saved in the long run due to fewer bugs and less maintenance. You just have to embrace that particular suck because it pays off in the end.
I always thought Ada was super cool tbh
Isn't zig more or less the closest thing we have for this currently? I really ask naively, without proper insights to give a relevant answer myself.
Zig is safer than C, which is not a high bar to clear. It has safer defaults than C, and makes it a little easier to use test-driven debugging to find memory safety violations, but it has no answer to Rust’s Send and Sync traits or the mutable XOR aliasable reference model. In that sense it’s similar to dozens of other languages older than Rust.
I don't see zig being that simple. I think it looks more like rust without the borrow checker. Odin to me looks like a more simple language. Go too would fit that if you want some safety.
Nice, I wasn’t aware of Odin, thanks.
But Zig doesn't have a nice package manager like Cargo?
Some would say that would be Zig, although it is more like Modula-2 safety guarantees.
So...C#? Structs + managed references and spans instead of raw pointers for memory ranges.
I think most gamedevs will reamain in higher level languages. Gone are the days when game developers were wizards of esoteric programming knowledge and elite skill; most game developers I've met are creative types who came to programming as a tool for expressing themselves, and not programmers who use their obscure knowledge to make creative things. Artists, not engineers.
For people who want to use programming as a tool for expressing themselves, C#, python, and, above all, visual programming are going to remain the most popular choices. They don't care about memory management or type theory, they just want to easily describe the behavior of things in a language which more closely mimics human thought
Rust is blazingly fast, though.
The first time I saw a package described with "blazingly", I thought it was a joke! It seems to have caught on now, but it still sounds ironic when I read it.
I think they meant slow as in development cycle slow, not runtime slow.
Author switched to C++ and OpenGL.
> Comfy is now archived until further notice... After abandoning Rust for gamedev [1] ... I just don't have the energy to constantly play catchup to the Rust ecosystem
[1] (April 2024) https://loglog.games/blog/leaving-rust-gamedev/
OpenGL is a questionable choice given that it is deprecated technology.
I don't get why somebody would start a new project based on OpenGL these days.
There's a good amount of different compatibility layers that you can use. There are a few vulkan implementations, there is Angle, and Webgl is still working... Depending on what you are doing you can still do a lot with OpenGL, you don't have to rely on the implementation in Nvidia drivers or whatever. I think most people using it are just really comfortable with it's shader language.
Probably because doing it in Vulkan requires you to slice your brain open.
"given that it is deprecated technology"
Depreciated by 'who'?
It's a standard, not a feature from some company that is ending support. There is a governing body.
"The Khronos Group, Inc. is an open, non-profit, member-driven consortium of 170 organizations developing, publishing and maintaining royalty-free interoperability standards for 3D graphics, virtual reality, augmented reality, parallel computation, vision acceleration and machine learning.[1][2] "
Deprecated by the evolution of the industry. Graphics hardware of the present day does not work anything like graphics hardware of the 1990s. OpenGL requires so much compatibility baggage and is so built around the wrong model of graphics programming that, even if you try to write it to work on modern hardware well, it has too many bottlenecks and wastes too much time and power to be competitive. It is unsalvageable even as a starting point for something better. Vulkan is Kronos's own replacement (based on AMD's earlier work with Mantle), DirectX 12 is Microsoft's, and Metal is Apple's.
OpenGL will continue to be supported for the foreseeable future but it will not gain any major new features, and it will likely lose direct support (requiring emulation or shims to actually work) on many platforms that still do support it now within a decade. For many games, this actually isn't a big issue, as they're not pushing the envelope anyway. But for those that do (or potentially will), OpenGL is the wrong choice.
Khronos doesn't work on GL anymore. The last OpenGL spec update (for GL 4.6) was in 2017.
>Depreciated by 'who'?
By the very Khronos Group you mentioned. They are developing Vulkan now, which they consider the successor to OpenGL. There will be no new OpenGL versions, again it is deprecated technology. Deprecated by its creators just like Python 2.
And just like Python 2, you can still use it, but again it would be a questionable choice for a new project in both cases, and for the same reason.
I don't think "deprecated" is the right terminology here. Nowhere on the Khronos Group website can I find a statement that OpenGL is considered deprecated. Not on the landing page for OpenGL (https://www.khronos.org/api/opengl) and not in the OpenGL FAQ (https://www.khronos.org/opengl/wiki/FAQ).
I think the term "deprecate" implies some level of actively discouraging use that is simply not happening with OpenGL (and that was/is for sure happening with Python 2). Specific platform vendors may deprecate OpenGL on their platform (as notably Apple has done), but that does not mean OpenGL is deprecated by Khronos Group.
But, Python is not gone. There is a new version, I can still use the next version of Python. Like you said, OpenGL does have an upgrade path to Vulkan.
It isn't like because Python 2 was depreciated, you have to switch to C#. It isn't gone. You can use the new version. Or older version until ready to migrate. Maybe it seems like it because of a name change, and you don't want to call Vulkan, OpenGL
So why give up on OpenGL altogether, when there is continuing development.
Vulkan is a totally different API from OpenGL. It's not hardly a mere name change and the initial work that became Vulkan originated outside of Kronos anyway. There is no "upgrade path" from OpenGL to Vulkan short of a total rewrite. This wasn't done maliciously or carelessly; the two APIs target fundamentally different abstract models of how graphics hardware works.
"totally different API"
Going from Python 2 to 3 wasn't a cake walk. Hence so many years to migrate.
But I get what you are saying. Some upgrade paths are easier/harder than others.
> Going from Python 2 to 3 wasn't a cake walk.
Yes, even despite of many similarities and shared stuff, which can't really be said about OpenGL and Vulkan.
Because it's much simpler that the alternatives and will remain supported forever in practice (either directly or through things like ANGLE or MoltenGL) even if it's deprecated.
If you don't need the features of the newer APIs it makes perfect sense to keep using it.
Then tell me what is a better alternative then: human-friendly API (which Vulkan isn't) but still low level enough to do some serious graphics programming?
I have noticed a trend for Rust game development to revolve around developing engines that are "high-performance," particularly with a focus on entity component systems. This is development for the sake of optimisation and premature is putting it lightly.
Let me say this loud and clear for anyone who dares to hear a fool: don't even think about performance until it becomes a problem and even then you could still probably stand to ignore it. Ergonomics are infinitely more important for an engine. If you can't develop and iterate quickly you can't prove your ideas and make something fun. These are two things Rust is very bad at.
Rust is good at many things, but game development is really not one of them. C++ is still okay. If you want to try something new, Odin[1] is shaping up nicely.
[1] https://odin-lang.org/
When will Odin get "real" async support? (Something more than plain old threads)
Probably never, or maybe much much farther in the future. Cooperative tasks aren't really a priority from what I've heard. It's still a low-level language like C with high level ergonomics.
Isn't the whole point of Rust is to be safely compiled to machine code, and not have built in garbage collection. So as was suggested in the article, if someone was open to using C#, then that would be the way to go. C# has all the features and safety and easier than C++. If C# is on the table as an option, then neither Rust nor C++ is also really needed.
This was the reason I stopped using Rust for hobby projects, there was always something breaking when going back to the project after a month. A library wouldn't compile or I had to fix things. So in the end, every time I had to spend 30min fixing things or forking libraries. Some things needed the latest stable, some the latest dev, some that version from 245 days ago. It was really a maintenance nightmare.
But you did decide actively to run cargo update each time right?
While I generally agree with most of what is here (and in the linked post on not using rust for gamedev), moving to C++ seems like it's a incomprehensible choice to me.
> At this point I've fully switched to developing games in C++, and I'm very happy with this choice.
Hm.
Well, I hope that works out for them, but if iterating speed and quick prototypes with hot reloading that doesn't crash is what people are looking for, I don't think anyone who hasn't spent 20 years programming in C++ is going to find it there (or possibly, anyone at all...).
I feel like as a small-moderate sized team, you really REALLY need a compelling reason not to pick UE / Unity / Godot.
The choice of language probably is less significant than the decision to use an existing engine rather than rolling your own.
For all the talk about prototyping and iteration speeds, and given they have:
> released a game on Steam in Unity, Unreal Engine 4, and Godot
I'm astonished that they haven't prioritized 'stick with one technology and ship more often' over 'try new things'.
I might be out of the loop, is there an actual 'anti-Rust' movement? or effort? even something organized and funded to push anti-Rust sentiment? Rust doesn't have a big backer with deep pockets, like GO does.
This is all valuable feedback.
But
Rust is new, so libraries are still in flux. That happens with being 'new'.
This seems more like single dev running out of time. Not a huge condemnation of Rust.
Rust has been releasing since 2006 (going off of Wikipedia). It's picking up in popularity as the ecosystem is reaching a form of maturity, but it's hardly new.
That in mind, the main reason why people tend to get frustrated with Rust to the point of condemning it is because Rust programmers tend to be rather zealous of how much they want to spread it's use, even in domains where it's more a disadvantage than a strength (game dev is the most obvious example, but Rust is a quagmire of constant rewrites if you have any form of rapid iteration or unstable specs). When those disadvantages subsequently pop up and become an issue, the response from Rust programmers often amounts to "you're holding it wrong", which just makes people curious about the language more annoyed since it comes across like their problems aren't being taken seriously.
It's perhaps no surprise that Rust communities oft find overlap with Wayland and Nix zealots because of this, where the shortcomings of their tools aren't an impediment to getting as many people as possible to use their tools.
I don't think it's any concerted movement, it's just that people tend to get annoyed when they're preached to even when what's being preached doesn't work for them, so they push back against it.
> Rust has been releasing since 2006 (going off of Wikipedia).
It was a personal project then. It wasn't until 2009 that it was shared more publicly, and the first stable release was in 2015.
That's still almost ten years ago, so your overall conclusion about it not being new is not incorrect, but it's not as old as you suggest here.
It's a condemnation of the library maintainers in the Rust ecosystem. Moreover it's endemic of the same mindset fueling "Rewrite it in Rust." A constant pursuit of correcting what seems not quite right with user experience being an afterthought. I am sympathetic to OSS being thankless and largely volunteer work, but for projects as big as wgpu and the like, the amount of instability given its popularity is unseemly.
> is there an actual 'anti-Rust' movement?
There have always been people who have been skeptical of, or dislike, Rust. Just like every technology.
> even something organized and funded to push anti-Rust sentiment?
Nah, anyone who believes this is engaging in conspiracy theory.
Funny
Ask innocent question about why there seems to be a lot of drama, negative feedback about Rust.
Get downvoted.
Isn't this part of the problem? Can't ask about it without inviting backlash?
Was only asking in this way, because a lot of the negative feedback in the entire thread, seemed counter to how things actually are in Rust. Kind of like FUD.
The “anti” movement is a result of a shift in the industry. At this point it’s pretty clear to all people watching that rust is winning the long term game to become the “standard language”. It’s pretty natural for such a shift to make people have feelings.
That said, if you actually look at the things the critics are saying, most of them are from a place of misunderstandings. Every time there is some Rust drama, tech influencers like primagen are doing back bends to be “fair”, even if it means given reasonable doubt to an unreasonable position, lest they turn off audience members who are too emotionally invested in seeing Rust be bad because it validates their choices.
> At this point it’s pretty clear to all people watching that rust is winning the long term game to become the “standard language”.
What a weird thing to say. There is no 'standard language', never has been and never will be (otherwise we'd all be programming in Java or Javascript, which during their heydays were 'obviously' becoming the 'future standard programming language').