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

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

851–860 of 996 posts

Re: Leaving Rust gamedev after 3 years

#851

Post by dragonwriter »

Capricorn2481 wrote: post #847
duped wrote: post #264

Earlier quoted context omitted.

But a type error isn't an edge case! It means you've written something the compiler can't understand. > This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code I think you've got it backwards - TS is popular because people want to use types up front, but it has to work with JS, which is so dynamic that i…

A type error means a type error, and nothing more. Type errors do not mean "incorrectness." Here is an example of something you can't do in rust, but can do in other statically typed languages. ```rust struct Type1 { id: u32 } struct Type2 { id: u32 } fn main() { let obj1 = Type1 { id: 1 }; let obj2: Type2 = obj1; // compile error, Type1 is not Type2 } ``` This code works perfectly fine. These two structs have the sa…

[text deleted because it was based on a incorrecf recollection of the details of Rust features.]

Re: Leaving Rust gamedev after 3 years

#853

Post by remram »

hot_gril wrote: post #579
remram wrote: post #566

Earlier quoted context omitted.

Sorry I got lost in that sentence. What is Rust's model?

Rust has traits on structs instead of using inheritance. Aka composition.

But that... wasn't in your comment at all...

If I say "I don't care about safety, I care about expressiveness. Which is Rust's model"... "which" has to refer to one of the other things I just mentioned (safety or expressiveness) not some other concept.

Re: Leaving Rust gamedev after 3 years

#854

Post by jandrewrogers »

IshKebab wrote: post #702
jandrewrogers wrote: post #421

Earlier quoted context omitted.

That assertion was specifically qualified in the context of database engines, for which it is true. I definitely write bugs but I haven't seen a segfault or memory corruption in years. That is more of a C thing than a C++ thing. It is kind of difficult to have a segfault or memory corruption with explicitly paged object memory, since there can't be any pointers and these complex objects are bound-checked at compile-t…

So you're saying if you write your database engine in C++ you're not going to see any segfaults? https://jira.mariadb.org/browse/MDEV-14248?jql=text%20~%20%2...

That is significantly dependent on the software architecture. MariaDB's design is not particularly modern (not a knock against MariaDB, it is an older system) and employs none of the software architecture required for high-scale and high-performance kernels that, as a side-effect, makes it difficult to accidentally create the conditions for a segfault regardless of the language. The design motivation is actually optimal dynamic resource scheduling under heavy unpredictable workloads, not memory safety. Rust's borrow checker doesn't work with these memory models, so you'll be in the same boat as C++ regardless.

I always found it theoretically interesting that schedule-based safety architectures, which are focused more on optimal resource allocation than safety per se (its all about extreme throughput traditionally), asymptotically converge on memory safety too as a practical matter for the same reason they also require almost no locking. By doing the safety analysis (many kinds, not just memory) at runtime, tiny dynamic modifications to the execution schedule are sufficient to provably (using TLA+ and similar) avoid many types of "unsafety" without the design compromises required to enable some of this analysis at compile-time. It requires a non-traditional software architecture, and it doesn't play nicely with a lot of existing code, due to the level of execution control required but I see more and more systems being designed this way at the high-end of the data infrastructure market.

Re: Leaving Rust gamedev after 3 years

#855

Post by Capricorn2481 »

Klonoar wrote: post #576
zac23or wrote: post #485

I also had the same bad experience with Rust outside of Gamedev. Probably a lot of other people too, but people don't talk about it much, because the Rust community is the most religious programming language community I've ever seen in my life. Before Rust, the Scala community was also pretty bizarre (Java too for a while), but nothing was on Rust's level. The worst part about Rust isn't technical, it's the crazy com…

I mean, your comment is actually contributing to the problem. You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that. It's fanning the flames and just doesn't really help.

> You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that

Like what? To criticize a community, you have to characterize it. And of course they didn't say everyone was like this.

> Of course, there are many people in the Rust community who are not religious and try to improve the language

Re: Leaving Rust gamedev after 3 years

#856

Post by [deleted] »

belinder wrote: post #541
110bpm wrote: post #509

Earlier quoted context omitted.

For me, the closest language currently is F#. The open-source ecosystem is not as massive as Go's or the JVM's, but it's not niche either. F# runs on .NET and works with all .NET packages (C#, F#, ...). If the .NET ecosystem can work out for you, I recommend taking a closer look at F#. F# allows for simple code, which is "functional" by default, but you're still free to write imperative, "side-effectful" code, too. I…

Do you know of or have any shareable (sample) projects implemented in your way of doing F#? It sounds very intriguing to me

[deleted]

Re: Leaving Rust gamedev after 3 years

#857

Post by estebank »

suby wrote: post #740
vacuity wrote: post #218

Earlier quoted context omitted.

Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization. * name intentionally made to make people angry

If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.

I would assume that it would opportunistically try to run the borrow checker, and if it fails on the access of a specific field, turn that access into an Arc/Rc everywhere, leaving any other access as references. This leaves you with invisible performance cliffs, where accessing a field in a new place suddenly increases the cost of accessing it everywhere else, but it does give you the "just do what I want, damn it!" development experience. I doubt Rust itself could do that without alienating its current userbase, but a RustScript could.

Re: Leaving Rust gamedev after 3 years

#858

Post by Capricorn2481 »

qweqwe14 wrote: post #746
yesuk wrote: post #554

Earlier quoted context omitted.

Some people "care about shipping a product" others "care about programming". That is why virtually no videogame is made with Rust.

In other words, "shipping a product" is incompatible with decent code. This is why virtually all proprietary codebases aimed at "shipping a product" are a clusterfuck.

This infantilizing "Everyone that cares about development speed is making shitty garbage" is so obnoxious. You're not omniscient. You don't know any of these codebases.

There's so much software out there, and lots of it works. Focusing on the small amount that could be messy and insisting you're not like the "sheeple" coding it is so lame.

Re: Leaving Rust gamedev after 3 years

#860

Post by Capricorn2481 »

andrepd wrote: post #87
klaussilveira wrote: post #54

&str vs String. Oh boy.

Yeah, if std::string vs std::string_view is "a major hurdle"... I don't know what so say

You are doing exactly what is being criticized in the Rust community. Bad faith reads of someone who spent significant time getting into the language.
Post reply on HN