9 ms·

Comfy, the 2D rust game engine, is now archived

87 points by ladyanita22 2y ago

daghamm 2y ago
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
- yu3zhou4 2y ago
  For what things Rust is painfully slow? You mean runtime or build time?
  - olivermuty 2y ago
    Development time is my guess
    - JD557 2y ago
      This. I assume it's a similar argument as the one presented in https://loglog.games/blog/leaving-rust-gamedev/ 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.
    - muglug 2y ago
      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).
  - desdenova 2y ago
    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.
    - fidotron 2y ago
      > 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.
      - wiz21c 2y ago
        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.
      - orphea 2y ago
        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?
      - chuckadams 2y ago
        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?
        steveklabnik 2y ago
        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.
- stroupwaffle 2y ago
  [flagged]
  - rizky05 2y ago
    [dead]
  - psychoslave 2y ago
    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.
    - Hemospectrum 2y ago
      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.
    - GardenLetter27 2y ago
      But Zig doesn't have a nice package manager like Cargo?
    - bobajeff 2y ago
      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.
      - psychoslave 2y ago
        Nice, I wasn’t aware of Odin, thanks.
  - pjmlp 2y ago
    Some would say that would be Zig, although it is more like Modula-2 safety guarantees.
- desdenova 2y ago
  Rust is blazingly fast, though.
  - danhau 2y ago
    I think they meant slow as in development cycle slow, not runtime slow.
  - jessekv 2y ago
    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.
- pjmlp 2y ago
  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.
- ljm 2y ago
  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.
  - pjmlp 2y ago
    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.
- bitwize 2y ago
  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.
- BaculumMeumEst 2y ago
  Watching people try to force Rust adoption everywhere over the last decade has been watching a car crash unfold at 0.00000001X speed.
- happyweasel 2y ago
  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..).
  - larschdk 2y ago
    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?
- pornel 2y ago
  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.
  - spoiler 2y ago
    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
    - pornel 2y ago
      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.
      - kaoD 2y ago
        > 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?
- binary132 2y ago
  I always thought Ada was super cool tbh
ndiddy 2y ago
> 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.
- desdenova 2y ago
  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.
  - littlestymaar 2y ago
    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).
    - mysterydip 2y ago
      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.
turtleyacht 2y ago
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/ https://loglog.games/blog/leaving-rust-gamedev/
- ndiddy 2y ago
  Previously discussed here: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033
- copx 2y ago
  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.
  - moffkalast 2y ago
    Probably because doing it in Vulkan requires you to slice your brain open.
  - a1o 2y ago
    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.
  - FrustratedMonky 2y ago
    "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] "
scandox 2y ago
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.
FrustratedMonky 2y ago
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.
- oguz-ismail 2y ago
  > Rust doesn't have a big backer with deep pockets https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/
- hresvelgr 2y ago
  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.
- steveklabnik 2y ago
  > 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.
- noirscape 2y ago
  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.
hresvelgr 2y ago
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/ https://odin-lang.org/
- lenkite 2y ago
  When will Odin get "real" async support? (Something more than plain old threads)
  - hresvelgr 2y ago
    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.
FrustratedMonky 2y ago
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.
wokwokwok 2y ago
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'.
deleted 2y ago
[deleted]
ta988 2y ago
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.
- atoav 2y ago
  But you did decide actively to run cargo update each time right?

87 points by ladyanita22 2y ago

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

yu3zhou4 2y ago
For what things Rust is painfully slow? You mean runtime or build time?
- olivermuty 2y ago
  Development time is my guess
  - JD557 2y ago
    This. I assume it's a similar argument as the one presented in https://loglog.games/blog/leaving-rust-gamedev/ 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.
  - muglug 2y ago
    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).
- desdenova 2y ago
  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.
  - fidotron 2y ago
    > 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.
    - wiz21c 2y ago
      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.
    - orphea 2y ago
      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?
    - chuckadams 2y ago
      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?
      - steveklabnik 2y ago
        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.
stroupwaffle 2y ago
[flagged]
- rizky05 2y ago
  [dead]
- psychoslave 2y ago
  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.
  - Hemospectrum 2y ago
    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.
  - GardenLetter27 2y ago
    But Zig doesn't have a nice package manager like Cargo?
  - bobajeff 2y ago
    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.
    - psychoslave 2y ago
      Nice, I wasn’t aware of Odin, thanks.
- pjmlp 2y ago
  Some would say that would be Zig, although it is more like Modula-2 safety guarantees.
desdenova 2y ago
Rust is blazingly fast, though.
- danhau 2y ago
  I think they meant slow as in development cycle slow, not runtime slow.
- jessekv 2y ago
  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.
pjmlp 2y ago
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.
ljm 2y ago
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.
- pjmlp 2y ago
  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.
bitwize 2y ago
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.
BaculumMeumEst 2y ago
Watching people try to force Rust adoption everywhere over the last decade has been watching a car crash unfold at 0.00000001X speed.
happyweasel 2y ago
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..).
- larschdk 2y ago
  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?
pornel 2y ago
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.
- spoiler 2y ago
  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
  - pornel 2y ago
    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.
    - kaoD 2y ago
      > 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?
binary132 2y ago
I always thought Ada was super cool tbh

ndiddy 2y ago

> 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.

desdenova 2y ago
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.
- littlestymaar 2y ago
  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).
  - mysterydip 2y ago
    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.

turtleyacht 2y ago

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/ https://loglog.games/blog/leaving-rust-gamedev/

ndiddy 2y ago
Previously discussed here: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033
copx 2y ago
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.
- moffkalast 2y ago
  Probably because doing it in Vulkan requires you to slice your brain open.
- a1o 2y ago
  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.
- FrustratedMonky 2y ago
  "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] "

scandox 2y ago

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.

FrustratedMonky 2y ago

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.

oguz-ismail 2y ago
> Rust doesn't have a big backer with deep pockets https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/
hresvelgr 2y ago
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.
steveklabnik 2y ago
> 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.
noirscape 2y ago
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.

hresvelgr 2y ago

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/ https://odin-lang.org/

lenkite 2y ago
When will Odin get "real" async support? (Something more than plain old threads)
- hresvelgr 2y ago
  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.

FrustratedMonky 2y ago

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.

wokwokwok 2y ago

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'.

deleted 2y ago

[deleted]

ta988 2y ago

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.

atoav 2y ago
But you did decide actively to run cargo update each time right?