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

761–770 of 799 posts

Re: Migrating away from Rust

#761

Post by ryao »

pjmlp wrote: post #757
ryao wrote: post #696

Earlier quoted context omitted.

C, unlike C++, does not really force new versions onto you, even if dependencies begin using them. That said, Linux switched to C11. Newer versions of C will gradually be adopted, despite the incompatibilities this causes for C++. As for WG 14, they incorporated numerous C++isms into C. While you claim that they did not go far enough, I am sure you will find many who would say that they went too far.

I very much doubt it, when someone decides to make full of use of recent ISO C on a C library header file. I claim they aren't focused on what matters, we don't need C++isms into C, we already have C++, and C should have been done as language back in C89. Anyone that wanted more has always been able to use C++ instead, or Objective-C on Apple/NeXT land. What we need is for WG14 to finally take security regarding stri…

> I very much doubt it, when someone decides to make full of use of recent ISO C on a C library header file.

I have tested this WRT _Generic as it was a concern. It turns out that GCC will accept it on older versions, which permits compatibility. You might feel that this is wrong, but that is how things are right now.

Re: Migrating away from Rust

#762

Post by agustechbro »

koakuma-chan wrote: post #60
Seattle3503 wrote: post #49

Earlier quoted context omitted.

What numeric types typically need conversions?

The fact you need a usize specifically to index an array (and most collections) is pretty annoying.

Thats a feature not an annoyance. We need to keep Rust like it is to preserve its core value delivey: Robust software quality in exchange for development & compile time/pain, in other words: "the pain is moved from production to development" you can not have joy in both at the same time.

Not sure if Rust should be promoted to build games, i prefer it being pushed to build mission critical software.

Re: Migrating away from Rust

#763

Post by nvlled »

oreally wrote: post #540
nvlled wrote: post #423

Earlier quoted context omitted.

I agree that the game is amazing from a technical point of view, but look at the reviews and the pace of development. The updates are sparse and slow, and if there's an update, it's barely an improvement. This is one the of disadvantages of creating a game engine from scratch: more time is spent on the engine than the game itself, which may or may not be bad depending on which perspective you look at it from.

The cause could be an art bottleneck and less to do with the game's code.

Maybe, it's using lowpoly models though which are relatively easier to create or outsource. This game is more on simulations and procedural generation, so I think game code is the likely the bottleneck.

Re: Migrating away from Rust

#764

Post by andrewflnr »

bmitc wrote: post #744
andrewflnr wrote: post #419

Earlier quoted context omitted.

Probably the intersection of people who (a) want an advanced ML-style language and (b) are interested in a CLR-based language is very small. But also, doesn't it do some weird thing where it matters in what order the files are included in the compilation? I remember being interested in F# but being turned off by that, and maybe some other weird details.

That ordering is generally considered a feature to keep dependencies and modules well-organized.

To be quite blunt, that sounds like a rationalization. To me "well-organized" would mean that the order conclusively does not matter. Otherwise I feel like I'm eventually going to end up randomly rejiggering the ordering until the compiler stops whining.

Re: Migrating away from Rust

#765

Post by hollerith »

pcwalton wrote: post #335
the_mitsuhiko wrote: post #36

Earlier quoted context omitted.

I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great. But outside of games the situation looks very different. “Almost everything” is just not at all accurate. There are tons of very stable and productive ecosystems in Rust.

> I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great. I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actu…

"ECS" == Entity-Component-System, "a software architectural pattern commonly used in game development and other simulations for organizing game objects and their data," according to Google Gemini.

Re: Migrating away from Rust

#766

Post by bombela »

WalterBright wrote: post #693
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…

> is it now natural to mix borrow checking and garbage collection? D is as memory safe as Rust is, when you use the garbage collector to allocate/free memory. If you don't use the GC in D, then there's a risk from: * double frees * memory leaks * not pairing the allocation with free'ing Those last 3 is what the borrow checker handles. In other words, with D, there is no point to using the borrow checker if one is usi…

> D is as memory safe as Rust is, when you use the garbage collector to allocate/free memory.

Does D also protects against data race?

(I couldn't find an obvious answer after a bit of research, but I might have overlooked something)

Re: Migrating away from Rust

#767

Post by sporkland »

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

> These crates also get "refactored" every few months, with breaking API changes, which breaks the stack for months at a time until everyone gets back in sync.

This was a problem with early versions of Scala as well, exacerbated by the language and core libs shifting all the time. It got so difficult to keep things up to date with all the cross compatibility issues that the services written in it ended up stuck on archaic versions of old libraries. It was a hard lesson in if you're doing a non-hobby project, avoid languages and communities that behave like this until they've finally stabilized.

Re: Migrating away from Rust

#768

Post by Ygg2 »

scott_w wrote: post #713
Ygg2 wrote: post #602

Earlier quoted context omitted.

> 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 literally just described my process, so I don’t get how you got to “you don’t know how you know” because… well… I just told you. Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features. I mean, Jesus Christ, we’re commenting on a thread here of experienced engineers commenting on how challenging…

> Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features

Keep in mind I wasn't new to programming at that point. I was programming in C64 basic for 3 years and Pascal for 3 as well. For hobby of course, and not fully.

Zero indexes aren't simple, they are intertwined everywhere but they are easy - as in familiar.

What experienced C++ devs in Rust are not much different than experienced Pascal devs in C. Lost. And having to rethread semi-familiar grounds.

---

And I described you my own. I don't fight the borrow checker. I just intuitively know how it works and what to avoid.

If you think just subtracting one or adding one is enough, there should be an easy enough way to test if it is. In Veritasium video they mention that having glasses that turn your vision upside down will cause confusion at first, but you will get used to them quickly.

What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes.

Re: Migrating away from Rust

#769

Post by aapoalas »

WalterBright wrote: post #695
aapoalas wrote: post #657

Earlier quoted context omitted.

Hey, thank you for spreading the joy of the borrow checker beyond Rust; awesome stuff, sounds very interesting, challenging, and useful! One question that came to mind as a single-track-Rust-mind kind of person: in D generally or in your experience specifically, when you find that the borrow checker doesn't work for a data structure, what is the alternative memory management strategy that you choose usually? Is it ga…

Personally, I frankly do not need the borrow checker. I have been writing manual memory management code for so long I have simply internalized how to avoid having problems with it. I've been called arrogant for saying this, but it's true. But I still like the borrow checker style of programming because it makes the code easier to understand. I find it convenient in the D compiler implementation to use the GC for the…

Alright, thank you for the answer. Cheers! <3

Re: Migrating away from Rust

#770

Post by ycombinatrix »

josephg wrote: post #492
ycombinatrix wrote: post #460

Earlier quoted context omitted.

Could std::rc::Weak solve the backreference problem?

I didn't consider that. Looking at how weak references work, that might work. It would reduce the need for raw pointers and unsafe code. But in exchange, it would add 16 bytes of overhead to every node in my data structure. That's pure overhead - since the reference count of all nodes should always be exactly 1. However, I'm not sure what the implications are around mutability. I use a Cursor struct which stores a re…

Consider copy-pasting the code from Rc/Weak, then tweaking it to suit your needs (reduce the overhead).

I have done this before with stdlib stuff like io::Cursor and was pretty happy with the result.

Post reply on HN