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

841–850 of 996 posts

Re: Leaving Rust gamedev after 3 years

#841

Post by Capricorn2481 »

cogman10 wrote: post #424
tick_tock_tick wrote: post #192

Earlier quoted context omitted.

I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community. Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.

I'm active on both and have not seen this behavior. In fact, my experience has been the polar opposite, the rust community has been very friendly and accepting of critique. So again, I'm going to ask for an example of rust language fanatics frothing at a criticism. If it's such a community problem this should be easy to find correct? Here's the OPs article on /r/rust and it's both got a fair number of up votes and th…

It may not be flaming, but the author brings up a particular quote repeatedly. "You just don't get it/have enough experience with it yet."

I've seen this everywhere. This is an obnoxious, lazy thing to say to someone. It's a go to for many "enlightened" languages that have small ecosystems and something to prove. The only response is to ignore it entirely or, like the author did, dedicate years of your life just to see if there's something to it. This is not okay. Life is short, and we lean on other developers experience to keep us from wasting our time.

If someone posts a topic wondering if X language is bad for something, it's an earnest question. Not a time to flex your dedication to the cause.

Re: Leaving Rust gamedev after 3 years

#842

Post by chromatin »

jacobgorm wrote: post #416
pcwalton wrote: post #326

Earlier quoted context omitted.

I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs

So far I am way less productive in rust than in any language I've ever used for actual work, so to rewrite an entire game engine would seem like commercial suicide.

"so far" is doing a lot of heavy lifting there =)

I was the same the first two times I tried to use rust (earnestly). However, one day it just "clicked" and my productivity exceeds that of almost anything else, for the specific type of work I'm doing (scientific computation)

Re: Leaving Rust gamedev after 3 years

#843

Post by flohofwoe »

pigpang wrote: post #828
germandiago wrote: post #805

Earlier quoted context omitted.

I really think the problem of Rust is the borrow checker. Seriously. It is good but it is overkill. You have to do and plan all things around it and discourages a lot of patterns or makes them really difficult to refactor. I would encourage people to understand Hylo's object model and mutable value semantics. I thinks something like that is far better, more ergonomic and very well-performing (in theory at least).

You can use unsafe code and pointers if you really want, but code will be unsafe, like C or C++.

TBF, unsafe Rust still enforces much more correctness than C or C++ (Rust's "unsafety" is more similar to Zig than C or C++).

Re: Leaving Rust gamedev after 3 years

#844

Post by chromatin »

Animats wrote: post #700
collinvandyck76 wrote: post #561

Earlier quoted context omitted.

>now you're having to fire up a tokio runtime I've been developing in (mostly async) Rust professionally for a about a year -- I haven't written much sync rust other than my learning projects and a raytracer I'm working on, but what are the kind of common dependencies that pose this problem? Like wanting to use reqwest or things like that?

> Like wanting to use reqwest or things like that? Yes. Reqwest cranks up Tokio. The amount of stuff it does for a single web request is rather large. It cranks up a thread pool, does the request, and if there's nothing else going on, shuts down the thread pool after a while. That whole reqwest/hyper/tokio stack is intended to "scale", and it's massive overkill for something that's not making large numbers of request…

reqwest also has a blocking version, which I use in projects not already using an async rt

https://docs.rs/reqwest/latest/reqwest/blocking/index.html

Re: Leaving Rust gamedev after 3 years

#845

Post by cmrdporcupine »

chromatin wrote: post #844
Animats wrote: post #700

Earlier quoted context omitted.

> Like wanting to use reqwest or things like that? Yes. Reqwest cranks up Tokio. The amount of stuff it does for a single web request is rather large. It cranks up a thread pool, does the request, and if there's nothing else going on, shuts down the thread pool after a while. That whole reqwest/hyper/tokio stack is intended to "scale", and it's massive overkill for something that's not making large numbers of request…

reqwest also has a blocking version, which I use in projects not already using an async rt https://docs.rs/reqwest/latest/reqwest/blocking/index.html

The blocking implementation still depends on and uses tokio, last I looked.

I've seen this with multiple Rust packages. "Yes, we offer a synchronous blocking version..." and then you look and it's calling rt.block_on behind the scenes.

Which is a pretty large facepalm IMHO

Re: Leaving Rust gamedev after 3 years

#846

Post by philiplu »

throwaway2037 wrote: post #718
philiplu wrote: post #506

Earlier quoted context omitted.

I was a developer on the Microsoft C++ compiler team from 1991 to 2006. We definitely didn't purchase someone else's compiler in that time. We looked at the EDG front end at various times but never moved over to it while I was there. Perhaps the speed-up you remember had something to do with the switch-over from 16 bits to 32, which would have been the early to mid 90s. Or you're thinking of Microsoft's C compiler st…

I heard that early versions of C++ IntelliSense from Visual Studio used Edison Design Group's (EDG) front end. Is that true? No trolling here -- honest question. If yes, are they still using it now?

Not true by the time I retired in 2007, but I've got a vague memory of talking to someone on the C++ front-end team some time after that and EDG for IntelliSense being mentioned. So no idea if that's really true or not, and if so, whether that's true today.

I was heavily involved in the first version of C++ IntelliSense, roughly 1997?, and it was all home-grown. It was also a miracle it worked at all. I've blocked out most of the ugly details from my memory, but parsing on the fly with a fast enough response time to be useful in the face of incomplete information about which #if branches to take and, especially, template definitions was a tower of heuristics and hacks that barely held together. Things are much better nowadays with more horsepower available to replace those heuristics.

Re: Leaving Rust gamedev after 3 years

#847

Post by Capricorn2481 »

duped wrote: post #264
ativzzz wrote: post #177

Earlier quoted context omitted.

Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good. Sometimes, it's useful to bypass these things for a prototype a…

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 same signature. The only thing that doesn't work is the names. There are dozens of things like this where your code works but the compiler is too strict. This is terrible for rapid iteration. It's good for other things like modeling your domain with types.

Re: Leaving Rust gamedev after 3 years

#848

Post by zozbot234 »

flohofwoe wrote: post #843
pigpang wrote: post #828

Earlier quoted context omitted.

You can use unsafe code and pointers if you really want, but code will be unsafe, like C or C++.

TBF, unsafe Rust still enforces much more correctness than C or C++ (Rust's "unsafety" is more similar to Zig than C or C++).

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

Re: Leaving Rust gamedev after 3 years

#850

Post by ragall »

iudqnolq wrote: post #815
jeremyjh wrote: post #650

Earlier quoted context omitted.

No, actually that was just javascript. Programming environments with threading models don't have to live that way. Separate threads can communicate through channels and do quite well for themselves. See how it works is, you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your lif…

Until you need cancellation

One rarely really needs that.
Post reply on HN