Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

791–799 of 799 posts

Re: Migrating away from Rust

#791

Post by Animats »

the__alchemist wrote: post #403
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit! I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

> I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

Yes.

Three months ago, when the Rust graphics stack achieved sync, I wrote a congratulatory note.[1]

    Everybody is in sync!

        wgpu 24
        egui 0.31
        winit 0.30

    all play well together using the crates.io versions. No patch overrides! Thanks, everybody.
Wgpu 25 is now out, but the others are not in sync yet. Maybe this summer.

[1] https://www.reddit.com/r/rust_gamedev/comments/1iiu3mr/every...

Re: Migrating away from Rust

#793

Post by sfink »

Ygg2 wrote: post #602
scott_w wrote: post #545

Earlier quoted context omitted.

> Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride. Given most languages since at least C have 0-based indexing... I would think most engineers picked it up early? I recall reading The C Programming Language 20 years ago, reading the reason and just following what it says. I don't think it's as complex as the descriptions people put forward of "fighting the borrow checke…

> Given most languages since at least C have 0-based indexing. As I mentioned I started Basic on C64, and schools curriculum was in Pascal. I didn't learn about C until I got to college. > One is "mentally add/subtract 1" and another is "gain a deep understanding of how memory management works in Rust." In practice they are, you start writing code. At first you trip on your feet, read stuff carefully, then try again…

I was Basic (on C64) -> assembly -> Pascal -> C, more or less. 0-based indexing wasn't too bad for me, except when it came to for loops.

    for (i=0; i
I eventually just memorized that pattern, but stumbled every time any part of it changed. I had to rethink the whole logic every time to figure out The borrow checks feels similar but different. It feels like it has more "levels" to it. Initially, it came naturally to me and I wondered what all the fuss was about. I was fighting iterators and into, not the borrow checker. I just had to mentally keep track of what owned my data and it all felt pretty obvious.

Then I started working on things that didn't fit into my naive mental model, and it became a constant fight.

So overall, a similar experience to 0-based indexing, yes. (Except I still don't "just know" the trickier bits of the borrow checker yet, so I don't know what comes next.)

Re: Migrating away from Rust

#794

Post by WhyNotHugo »

pclmulqdq wrote: post #618
WhyNotHugo wrote: post #606

Earlier quoted context omitted.

> > The lower levels are buggy and have a lot of churn > > The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan The same is true if you try to make GUI applications in Rust. All the toolkits have lots of quirky bugs and broken features. The barrier to contributing to toolkits is usually also pretty high too: most of them focus on supporting a variety of open source and proprietary platforms. If you want to improve on some…

Arc is a very slow and primitive tool compared to a GC. If you are writing Arc everywhere, you would probably have better performance switching to a JVM language, C#, or Go.

I warned that one extreme (being afraid to use Arc is necessary) is bad.

I agree with you: the other extreme (using Arc everywhere) is also bad.

There's a sweet middle spot of using it just when strictly necessary.

Re: Migrating away from Rust

#795

Post by baranul »

WhereIsTheTruth wrote: post #615
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

> I can also say confidently that the #1 method to combat memory safety errors is array bounds checking. The #2 method is guaranteed initialization of variables. The #3 is stop doing pointer arithmetic (use arrays and ref's instead). #4 safer union/enum, I do hope D gets tagged-union/pattern-matching sometimes in the future, I know about std.sumtype, but that's nowhere close to what Rust offer

Another language with such features, including sumtypes, is V (Vlang)[1].

[1] https://github.com/vlang/v/blob/master/doc/docs.md#sum-types

Re: Migrating away from Rust

#796

Post by baranul »

WalterBright wrote: post #470
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

> So I implemented a borrow checker for D...

D's implementation of a borrow checker, is very intriguing, in terms of possibilities and putting it back into the context of a tool and not the "be all, end all".

> I can also say confidently that the #1 method to combat memory safety errors is array bounds checking. The #2 method is guaranteed initialization of variables. The #3 is stop doing pointer arithmetic (use arrays and ref's instead).

This speaks volumes from such an experienced and accomplished programmer.

Re: Migrating away from Rust

#797

Post by baranul »

Ygg2 wrote: post #708
chubot wrote: post #563

Earlier quoted context omitted.

So in D, is it now natural to mix borrow checking and garbage collection? I think some kind of "gradual memory management" is the holy grail, but like gradual typing, there are technical problems The issue is the boundary between the 2 styles/idioms -- e.g. between typed code and untyped code, you have either expensive runtime checks, or you have unsoundness --- So I wonder if these styles of D are more like separate…

> "gradual memory management" is the holy grail I don't think gradual types are as holy grail as you make them out to be. In gradual typing, if I recall correctly, there was a large overhead when communicating between typed and untyped parts. But further But lets say gradual memory management is perfect, you have to keep in mind the costs of having GC + borrow checking. First thing, rather than focusing on perfecting…

Not all languages using a GC are designed that way, where libraries are dependent on it. For example, in V (Vlang), none of their libraries need the GC. They also can freely mix memory management methods. There is no ecosystem split, but rather preferences.

Re: Migrating away from Rust

#798

Post by littlestymaar »

ArthurStacks wrote: post #417
jokethrowaway wrote: post #357

Earlier quoted context omitted.

Given my experience with Bevy this doesn't happen very often, if ever. The only challenge is not having an ecosystem with ready made everything like you do in "batteries included" frameworks. You are basically building a game engine and a game at the same time. We need a commercial engine in Rust or a decade of OSS work. But what features will be considered standard in Unreal Engine 2035?

Nobody is going to be writing code in 2035

Long bet: people are going to write much more code in 2035 than today. It's just going to be very different.

(For the record software development has nothing to do now with how it looked when I started in 2003, plenty of things have revolutionized the way we write code (especially Github) and made us an order of magnitude more productive at least. Yet the number of developer has skyrocketed. I don't expect this trend to stop, AI is yet another productivity boost in an industry that already faced a lot of them in recent time.

Re: Migrating away from Rust

#799

Post by jwhitlark »

photonthug wrote: post #352
schneems wrote: post #329

Earlier quoted context omitted.

I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.

Yeah, not only is the structure of business workflows often resistant to mature software dev workflows, developers themselves increasingly lack the discipline, skills or interest in backwards compatibility or good initial designs anyway. Add to this the trend that fast changing software is actually a decent strategy to keep LLMs befuddled, and it’s probably going to become an unofficial standard to maintain support c…

https://github.com/clj-commons/rewrite-clj is an absolute superpower for this kind of thing, if you were using Clojure. It always saddened me it doesn't get more exposure.

As good as Rust is, I still feel there needs to be a "high-low" strategy for most biz/game code. You want to be able to depend on your low level abstractions, while constantly changing up how you fit them together.

Post reply on HN