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

Ask HN: Will Rust ever become a mainstream systems programming language?

news.ycombinator.com

Post reply on HN
Print view View original

251–260 of 291 posts

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#251

Post by lossolo »

burntsushi wrote: post #248
lossolo wrote: post #245

Earlier quoted context omitted.

> If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Purposely interpreting something differently while there is social majority consensus on interpreting it the other way looks like having an agenda, especially by someone that is heavily involved in topic in question like you are. >…

Emphasis mine: > Purposely interpreting something differently while there is social majority consensus on interpreting it the other way I did no such thing. > When more than one random person questions my behavior same way I do not find that "extraordinarily petty" You're the only person accusing me of purposefully misleading people. > that's why we have this discussion in the first place I'm in this discussion with…

> I'm in this discussion with you because you're assaulting my character

"Assaulting my character" - wow. Don't be so defensive, pride is talking through you, not reason.

> Now, please either show some evidence that I've purposefully tried to mislead others,

You provided all evidence that would point to that conclusion already in your comments and I already discussed those in my previous comments. You have any proofs that state otherwise? No.

> You're the only person accusing me of purposefully misleading people.

I am not the only one that challenged what you replied, I am just describing possible reason behind it after connecting dots. Read about defense mechanism, psychological repression, bias, denial and thought suppression and especially narcissistic defenses. Doing something purposely doesn't mean it was consciously.

> unsubstantiated bullshit about me personally go uncontested

"unsubstantiated bullshit" - This are conclusions I made analyzing your comments. I do not call what you wrote bullshit because I don't agree with it. Please be more civilized in this discussion.

> shut your trap

Clearly this one shows no one should contest your character. You are without any faults, I am sorry I dared to think otherwise.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#252

Post by dbaupp »

soulbadguy wrote: post #249
Rusky wrote: post #152

Earlier quoted context omitted.

> - Move semantics - we've had this since C++11. C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions. Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the progr…

> C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions. This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ? > Rust avoids the null state problem by statically omitting the constructor call You seems to be conflating move s…

The parent correct: C++ runs destructors on all local variables, even if they have been "moved from", so it must be valid to do so. This translates into a null/"valid invalid"/sentinel state that the destructor can check to avoid truly destroying the underlying resource (which could result in double-freeing memory, or double-closing a file, or some other undefined behaviour). For instance, moving out of a unique_ptr will swap in NULL, and the destructor checks for that.

Static omission of destructors in Rust is more than just an optimisation: locals (and other values) never have their destructors run once they've been moved-from, and thus no values need null states, and moving a value doesn't have to run arbitrary code (it can be, and is, just a memcpy).

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#253

Post by poopsicle »

soulbadguy wrote: post #243
dbaupp wrote: post #198

Earlier quoted context omitted.

> Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a…

> Allocating is definitely a big deal for a pervasive error handling! Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception. I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs…

And yet the bulk of this thread was in reference to python where exceptions are the pervasive scheme.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#254

Post by Rusky »

steveklabnik wrote: post #238
Rusky wrote: post #218

Earlier quoted context omitted.

Rust can totally compile on console platforms- it's been done, e.g. on PS4 ( https://twitter.com/wickerwaka/status/479842553831776257 ), as I'm sure you've seen, Steve :) The problem (speaking as someone working on a console game at a AAA studio) is more likely that it's not officially supported. Console SDKs include C++ toolchains and C++ libraries, and there's a lot to lose by trying to bypass that, especially on a…

Yeah, I knew it was possible for some definition of possible; I just didn't know that any game studios were using it in any capacity, let alone a studio like DICE. The support thing makes total sense. Do you think it's fundamentally insurmountable? I'm pretty sure this is an area where the team itself has a blind spot, or maybe rather, just doesn't have the necessary expertise to even know what we'd need to do to mak…

I honestly don't know how fundamental an issue it is. I suspect the console vendors and engine/library developers would all have to be on board at some level. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized.

A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only trivially call C APIs but can also compile most C code without modification. To support Rust would require not only porting the toolchain (though this wouldn't be too bad on current-gen, since e.g. the PS4 even uses Clang), but really working well with the console SDKs, and third-party libraries and middleware, which are all written in C++.

It would probably also be a much tougher mindshare hill to climb- even C++ took a long time to be accepted, and its standard library still isn't. Vulnerabilities are not really an issue for games the way they are for, say, browsers, since games' inputs and environments are so constrained and there's often no real consequences worse than a player losing their save file.

So from my perspective (which to be fair is relatively new to the industry) these might be the most important features for getting Rust into games:

* Visual Studio integration, including code completion and debugging. Though console support would have to come from the console vendor, anyone could work on supporting things like variable name hovering and data display.

* C++ support- though maybe different from what application developers need. DirectX (Windows/Xbox One) is all COM-based, which is strongly related. If it's handled through bindgen, it still needs code completion support.

* SIMD, inline assembly, etc. This stuff gets used all the time for performance, and for a lot of it portability is not a concern, because things are handled differently per-platform anyway.

Similarly, Rust might just not be a good fit for games because of some tradeoffs it makes:

* Games can't get by with just malloc-style memory management- and while it's easy to mess up, C and C++ handle arenas/pools/etc with far less friction than Rust, where you'd want to package up every little pointer thing behind a safe API. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment.

* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.

* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#255

Post by Rusky »

soulbadguy wrote: post #249
Rusky wrote: post #152

Earlier quoted context omitted.

> - Move semantics - we've had this since C++11. C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions. Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the progr…

> C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions. This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ? > Rust avoids the null state problem by statically omitting the constructor call You seems to be conflating move s…

> > omitting the constructor call

Oops, too late to edit but that was meant to say "destructor."

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#256

Post by pingveno »

flukus wrote: post #143
burntsushi wrote: post #140

Earlier quoted context omitted.

"zero issues" is a bridge too far. Rocket, for example, only works on nightly Rust, and that might be a non-starter for a lot of people.

This has been my biggest issue trying to learn rust, there are too many projects that only support the bleeding edge.

This issue has been greatly reduce since Rust 1.0 came out as more language features are stabilized. Just in 2017, Diesel (ORM) and Serde (serialization) have started being fully functional on stable Rust. Rocket is one of a rapidly shrinking set of libraries that relies on unstable features. As long as Rocket doesn't add a dependency on more unstable features, it too will join the ranks of stable-compatible crates soon.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#257

Post by scythe »

Rusky wrote: post #254
steveklabnik wrote: post #238

Earlier quoted context omitted.

Yeah, I knew it was possible for some definition of possible; I just didn't know that any game studios were using it in any capacity, let alone a studio like DICE. The support thing makes total sense. Do you think it's fundamentally insurmountable? I'm pretty sure this is an area where the team itself has a blind spot, or maybe rather, just doesn't have the necessary expertise to even know what we'd need to do to mak…

I honestly don't know how fundamental an issue it is. I suspect the console vendors and engine/library developers would all have to be on board at some level. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized. A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only tr…

>* Games can't get by with just malloc-style memory management- and while it's easy to mess up, C and C++ handle arenas/pools/etc with far less friction than Rust, where you'd want to package up every little pointer thing behind a safe API. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment.

I don't see why this isn't fixable? It's just a lack of library support AFAICT.

>* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.

I don't know much about this in C++ but I know that error handling in Go is at least as bad. Rust's fancy type system should in theory make error handling easier if you use it correctly (that's supposed to be an advantage of type systems after all) but it requires not just understanding how the type system can be used for error correction but a way of integrating that knowledge into development methodologies. This has to be developed by the teams themselves although it also forms a part of the collective knowledge base of the programming community (most of us are familiar with unit tests in imperative languages at this point).

>* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.

Just guessing:

>The biggest is probably the fact that it's impossible to safely put a borrowee and a borrower in the same struct. This has very deep consequences on API design.

You should probably use `unsafe` for this. As noted, you're flying blind if you do this in C++ as well. It's possible that some partial solutions will be implemented but I doubt that the project will cover every possible use case. The reason that this isn't in safe Rust is that it's very hard to reason about when this is and isn't safe. An issue is that people have difficulty reasoning about the behavior of unsafe Rust because of its unfamiliar semantics.

>No decltype is really a deal breaker as well. The core team has recently added the -> impl Trait syntax because iterators and futures were too annoying to deal with. I'm manipulating types that are ten times worse than iterators, and I have to put them in my structs.

Holy pretty printer Batman! Let me see:

>When you write struct Foo it's the user of the struct that choose what T is. In my code I have a very precise type that I want to put in the struct, I just can't express it in the source code because it's too long. I don't want the user to choose this type for me, this is totally difference.

I think this could be fixed in exactly the way that tomaka wants it to be fixed, by allowing type aliasing which is limited to a particular lexical scope. Since this is basically equivalent to creating a trait which is only implemented by a single type (which he could in theory do but it's very awkward) it shouldn't introduce any new complexity to the type system.

Tomaka's other points are being fixed. Rust is a very large undertaking...

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#258

Post by steveklabnik »

Rusky wrote: post #254
steveklabnik wrote: post #238

Earlier quoted context omitted.

Yeah, I knew it was possible for some definition of possible; I just didn't know that any game studios were using it in any capacity, let alone a studio like DICE. The support thing makes total sense. Do you think it's fundamentally insurmountable? I'm pretty sure this is an area where the team itself has a blind spot, or maybe rather, just doesn't have the necessary expertise to even know what we'd need to do to mak…

I honestly don't know how fundamental an issue it is. I suspect the console vendors and engine/library developers would all have to be on board at some level. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized. A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only tr…

Thanks, this all makes a lot of sense.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#259

Post by Rusky »

scythe wrote: post #257
Rusky wrote: post #254

Earlier quoted context omitted.

I honestly don't know how fundamental an issue it is. I suspect the console vendors and engine/library developers would all have to be on board at some level. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized. A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only tr…

>* Games can't get by with just malloc-style memory management- and while it's easy to mess up, C and C++ handle arenas/pools/etc with far less friction than Rust, where you'd want to package up every little pointer thing behind a safe API. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment. I don't see why this isn't fixable? It's just a lack of libra…

> memory management > It's just a lack of library support AFAICT.

Libraries could help, but game often have a lot of one-off memory stuff too that you can't put in a library and you can't do in safe Rust. Maybe there are some more creative solutions that nobody's had to come up with yet because C makes it so frictionless.

> error handling in Go is at least as bad

The thing is that style lets you ignore errors in cases where the error isn't gonna happen. That's usually bad, but in games it's often fine because you control everything. The equivalent in Rust requires an `unwrap` of some kind which introduces performance and syntactic overhead.

I guess all I'm getting at is that beyond the implementation, there is still design work to be done if we want Rust to work well for games.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#260

Post by dbaupp »

soulbadguy wrote: post #243
dbaupp wrote: post #198

Earlier quoted context omitted.

> Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a…

> Allocating is definitely a big deal for a pervasive error handling! Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception. I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs…

As the sibling points out, this is in the context of the suggestion of using Python's approach, where exceptions are not just pervasive, they are so pervasive they're used for non-errors/control flow (e.g. StopIteration).
Post reply on HN