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

Making a Game in Rust

michaelfairley.com

Post reply on HN
Print view View original

61–70 of 125 posts

Re: Making a Game in Rust

#61

Post by lohengramm »

felipemnoa wrote: post #34

This is probably not a popular opinion here in HN but why does it matter what language you use to make your game in? You can use virtually any language to make a game. From my point of view the best language for a game is that which makes you the most productive for cranking out that code. And we all have our own personal preferences about which language is best, which I think is fine, you should code with the one th…

You can use any language, but it's not like they are all equal and have the same tooling available. Rust has some distinct features and there is a natural lack of resources as the language is still new, so it's interesting from a developers perspective that someone went through the work of doing all that from scratch and made it to the end.

Also it's an alternative to C++ which is heavily used in gamedev. I personally believe Rust can shine in gamedev and every experiment is interesting.

Re: Making a Game in Rust

#62

Post by steveklabnik »

sqeaky wrote: post #47
ekimekim wrote: post #33

Earlier quoted context omitted.

They're commenting on the link in the GP about "Rust's recent inclusion in a AAA title" (some rust code is used as text in a generic 'computer code' image)

This tells me why I got downvotes, I replied to the wrong comment. The game wasn't written in rust, is was used in a texture and drawn on a wall.

The game that's the subject of the OP is written in Rust. The one in the Reddit thread linked elsewhere was only a texture.

Re: Making a Game in Rust

#63

Post by kbenson »

Manishearth wrote: post #20
alkonaut wrote: post #14

> I had two or three false-start attempts at learning Rust where I’d spend a few hours with it, not get anything done, and put it down until a few months later This sounds (sort of) encouraging. I was kind of expecting to learn it by putting in an hour here and there e.g. 2-4h/month. But I'm beginning to think that might not cut it...

Go is a language that you can absolutely learn like that, and it's pretty amazing. (Python, too) Rust ... isn't. I love Rust, but you do need to put some dedicated time into learning it. We're hoping to improve this!

It's unfortunate that our profession emphasizes ease of learning so much. There are things you can make better to make a language easier to learn that don't affect usefulness, but at some point those mostly run out and there is a trade-off between making something easier to learn and easier to use. One brings more new people into the community, the other retains them by continuing to provide good value for invested time.

Python is actually a good case for this, where choices to make the language simpler and more uniform led to knock-on effects that ultimately lead to aspects of it being quite cumbersome (IMO, obviously). For example, how anonymous functions are specified, how cumbersome and limited that makes map and grep, and how that leads to list comprehensions, which for all but the simplest cases are much more complicated to read and write than a simple chain of maps and greps (assuming something better than lambda).

At the other end of the spectrum you have APL and its relatives. Lots of work to learn and become proficient in, but then you can read and write terse, performant and versatile programs with it quickly. Of course, the pool of people that can understand what you wrote is orders of magnitude smaller than with some of the easier to learn languages.

I understand the urge to make Rust as accessible as possible, and I applaud that effort. I just hope that Rust continues to walk the line of accessibility without compromise on the core ideals.

Re: Making a Game in Rust

#64

Post by eridius »

vvanders wrote: post #2

Great stuff, lines up a lot with what I'd care about as an ex-gamedev and spending a bit of time with Rust. One minor point: > First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it re…

A long time ago I wrote bindings to Lua 5.1 (https://github.com/kballard/rust-lua), but there was a nasty problem where Lua uses longjmp() for errors (it can be configured to use C++ exceptions, but that doesn't work because you can't throw those past an extern C boundary without hitting undefined behavior). longjmp(), of course, will just skip right past the intervening stack frames, meaning if your Rust code calls into Lua and it throws an error, then unless you wrapped that call with a lua_pcall, any values that live on the stack of your Rust function will never call their destructors.

I admit I haven't bothered to research the current state of things, but how do more recent Lua bindings handle this? Does Lua 5.3 actually have a proper solution here, or do most bindings just wrap every single call with lua_pcall? I didn't do that in my bindings because I wanted to offer the full speed of Lua, but it's certainly an option.

Re: Making a Game in Rust

#65

Post by eridius »

kibwen wrote: post #3

I wasn't even aware that you were allowed to ship Rust code in iOS apps, I thought that Apple had a whitelist of allowed languages? EDIT: And for those interested, you might want to check out Rust's recent inclusion in a AAA title: https://www.reddit.com/r/rust/comments/69s225/rust_makes_it_... :P

For a brief time they had restrictions on the languages you could use. That was a reaction to Adobe shipping a tool to compile your Flash source into an iOS app. But that didn't last very long.

That said, if you're dynamically interpreting code at runtime that was downloaded from the internet, you're only allowed to do that using JavaScriptKit. You cannot, for example, embed the Lua interpreter and then interpret code downloaded (but code in your app bundle is fine).

Re: Making a Game in Rust

#66

Post by eridius »

nebabyte wrote: post #42
bluejekyll wrote: post #21

Earlier quoted context omitted.

The biggest problem I faced with Rust and macOS/iOS is related to Apple's requirement for bitcode on all submitted code to the App Store for Watch and appleTV applications. This internal Rust discussion focuses on it for more details: https://github.com/rust-lang/rust/issues/35968 This gist is that Apple is requiring bitcode, but isn't giving easy access to the LLVM version they use for their own tools. This means th…

I continue to be amazed that apple is not considered as having a monopoly on "stores for apple devices". These are exactly the kind of archaic requirements that would be a nonstarter or otherwise kill market support for a store given any actual competition. Instead, they are able to leverage it to try and push their 'approved' languages and developer environments - furthering anticompetitive lock-in. Apple making mon…

"products made by one brand" isn't a category of products. If they're the only brand that makes products for a particular category, then they're a monopoly, but you cannot simply define a category as "stuff made by that company", because by that logic, every company is a monopoly on stuff made by them.

Re: Making a Game in Rust

#67

Post by dragonwriter »

eridius wrote: post #66
nebabyte wrote: post #42

Earlier quoted context omitted.

I continue to be amazed that apple is not considered as having a monopoly on "stores for apple devices". These are exactly the kind of archaic requirements that would be a nonstarter or otherwise kill market support for a store given any actual competition. Instead, they are able to leverage it to try and push their 'approved' languages and developer environments - furthering anticompetitive lock-in. Apple making mon…

"products made by one brand" isn't a category of products. If they're the only brand that makes products for a particular category, then they're a monopoly, but you cannot simply define a category as "stuff made by that company", because by that logic, every company is a monopoly on stuff made by them.

Actually, a makers own products are a distinct market for antitrust purposes if people empirically don't substitute out of it, as shown by the producer having market (pricing) power.

I wouldn't be surprised if that's true for Apple for some of its offerings.

Re: Making a Game in Rust

#68

Post by Manishearth »

joncampbelldev wrote: post #25
Manishearth wrote: post #20

Earlier quoted context omitted.

Go is a language that you can absolutely learn like that, and it's pretty amazing. (Python, too) Rust ... isn't. I love Rust, but you do need to put some dedicated time into learning it. We're hoping to improve this!

Whilst an easy start is nice, any language that you can pick up with no effort just means you're learning the same language + paradigm that you already know with a few differing features (in go's case CSP). Nothing wrong with that, CSP is awesome etc I'm not a rust dev (definitely interested in picking it up though), but heavily into clojure and learning haskell slowly on the side. I hear this complaint a lot from pe…

I don't think this is necessarily true. Go did introduce some paradigm shifts, but they were gentle and easy to ease in to.

Also, I mean, sure, the language may not have new things, but ultimately the goal is to use the damn thing, not learn new concepts :) Go is amazing for that.

I totally agree that expecting to learn a random language in a weekend is unreasonable.

Re: Making a Game in Rust

#69

Post by wahern »

eridius wrote: post #64
vvanders wrote: post #2

Great stuff, lines up a lot with what I'd care about as an ex-gamedev and spending a bit of time with Rust. One minor point: > First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it re…

A long time ago I wrote bindings to Lua 5.1 ( https://github.com/kballard/rust-lua ), but there was a nasty problem where Lua uses longjmp() for errors (it can be configured to use C++ exceptions, but that doesn't work because you can't throw those past an extern C boundary without hitting undefined behavior). longjmp(), of course, will just skip right past the intervening stack frames, meaning if your Rust code call…

The typical solution in C is to wrap and anchor such objects in the Lua VM so that they'll be garbage collected if an error is thrown. There are various patterns for doing this--direct binding of individual objects, or indirectly anchoring through an opaque staging struct--but that's the general idea.

Because Lua supports coroutines with a stack independent from the system C (Rust) stack, you often want to be careful mixing your stack-allocated objects. Lua 5.2 added lua_callk which allows yielding and resuming coroutines across the C API (that is, "yielding" a coroutine with a nested C or Rust function invocation).

Leveraging Lua's awesome coroutine support is one of the biggest reasons to use Lua, IMO.

Also, Lua can safely recover from out-of-memory (OOM) scenarios. On OOM it will throw an error that can be safely caught. Any Lua API which might internally allocate memory can throw this error, not just the lua_call family of routines. Quality libraries are expected to also handle OOM, which usually can be accomplished the same way as handling any other error: wrapping and anchoring temporaries, directly or indirectly, in the Lua VM.

Re: Making a Game in Rust

#70

Post by Manishearth »

kbenson wrote: post #63
Manishearth wrote: post #20

Earlier quoted context omitted.

Go is a language that you can absolutely learn like that, and it's pretty amazing. (Python, too) Rust ... isn't. I love Rust, but you do need to put some dedicated time into learning it. We're hoping to improve this!

It's unfortunate that our profession emphasizes ease of learning so much. There are things you can make better to make a language easier to learn that don't affect usefulness, but at some point those mostly run out and there is a trade-off between making something easier to learn and easier to use . One brings more new people into the community, the other retains them by continuing to provide good value for invested…

I don't think the intent is to compromise on these :)

But lots of things can be made easier to learn via better tooling, better docs, or better diagnostics. Or just removing papercuts.

One such thing I've recently been thinking about is https://github.com/Manishearth/rust-clippy/issues/1737 , which would be cool if it got big.

Post reply on HN