[HN Gopher] Leaving Rust gamedev after 3 years
___________________________________________________________________
Leaving Rust gamedev after 3 years
Author : darthdeus
Score : 744 points
Date : 2024-04-26 17:33 UTC (5 hours ago)
(HTM) web link (loglog.games)
(TXT) w3m dump (loglog.games)
| maximilianburke wrote:
| I would love to be able to bypass the orphan rule for internal
| crates.
| JoshTriplett wrote:
| I would love to make it possible to bypass the orphan rule _in
| general_ , including for crates published on crates.io. This is
| an important issue for ecosystem scaling, in many different
| ways.
|
| It means that if you have a library A providing a trait and a
| library B providing a type, either A has to add optional
| support for B or B has to add optional support for A, or
| someone has to hack around that with a newtype wrapper.
| Usually, whichever library is less popular ends up adding
| optional support for the more popular library. This is, for
| instance, one reason why it's _really really hard_ to write a
| replacement for serde: you 'd have to get every crate currently
| providing optional serde support to provide optional support
| for your library as well.
|
| In other ecosystems, you'd either add quick-and-dirty support
| in your application, or you'd write (and perhaps publish) an
| A-B crate that implements support for using A and B together.
| This should be possible in Rust.
| maximilianburke wrote:
| Oh, 100%, I'd be happy with that too.
|
| Is the orphan rule a result of some technical limitation? Or
| just the idea that it's "unclean" to implement someone elses
| traits for someone elses types?
| mrkeen wrote:
| Hi from Haskell land!
|
| Haskell went through this as well. Orphans used to be
| allowed and I certainly saw their appeal.
|
| The problem is that the compiler might see two different
| implementations of ToString for MyType in different source
| files. The compiler could probably make a check for that if
| it were compiling both files at once, but if you want to be
| able to compile source files separately and only recompile
| files which have changed, etc., I think it gets harder to
| spot.
|
| > someone has to hack around that with a newtype wrapper
|
| Don't think of it as hacking around it. It's the blessed
| approach. Newtype wrapping is giving a proper names to the
| behaviours, so that they don't get mixed up.
| HL33tibCe7 wrote:
| > The problem you're having is only a problem because you haven't
| tried hard enough.
|
| You just need to read another 50,000 word fasterthanlime essay.
| Then you'll not have problems any more.
|
| > That being said, there is an overwhelming force in the Rust
| community that when anyone mentions they're having problems with
| Rust the language on a fundamental level, the answer is "you just
| don't get it yet, I promise once you get good enough things will
| make sense".
|
| Not only this, but they openly mock other language communities
| for not drinking the koolaid.
|
| I like Rust, and the Rust community, and fasterthanlime, for what
| it's worth. But I think these points raised in the article are
| very much valid.
| Keyframe wrote:
| this reminds me of Lispen of ye olde.. wait untill it clicks,
| man!
| msla wrote:
| Lisp is pretty normal if you're accustomed to, like, Python:
| It's a GC'd procedural language.
| kleiba wrote:
| Haha, nice one! :-)
|
| (can only assume you're joking)
| Pxtl wrote:
| Since every other language now has higher order functions
| and lexical closures and things like that Lisp isn't as
| special as it used to be. Now it's mostly just a really
| _ugly_ version of those languages but with a weird
| emphasis on recursion and a very fancy macro facility.
|
| I find I can move between dynamic languages and Scheme
| pretty easily.
| cultofmetatron wrote:
| as someone who writes elixir all day, I really love what
| lisp is but I feel lisp's major weakness is that it makes
| everythign unergonomic in order to make macros very
| ergonomic. You will never find another language in which
| writing macros is easier. the problem is it comes at the
| cost of doing everything else a bit of a pain in the ass.
|
| I love elixir because it feels like the syntax clojure
| would have if it had a syntax imho.
| gorjusborg wrote:
| > it makes everythign unergonomic in order to make macros
| very ergonomic
|
| I think 'everything is unergonomic' is a too strong of a
| statement to be true.
|
| I'd argue that lisp is very ergonomic for those who work
| with it regularly (and are into using Emacs). It sounds
| like you are beefing with the syntax (or lack thereof)
| and homoiconicity of Lisp. I can understand that. It is a
| very different language than others currently in the
| mainstream for that reason.
|
| As far as overall ergonomics, I'd say the REPL/image-
| based development style and the macros that are enabled
| due to homoiconicity actually make it one of the most
| ergonomic languages in existence.
|
| The biggest thing that prevents Lisp-likes from going
| mainstream is that it is _too ergonomic_ , specifically,
| when you start reading a Lisp codebase, you essentially
| are signing up to learn a new project-specific dialect.
| Very ergonomic for writing code, but at the cost of
| understanding how that code operates.
| lispm wrote:
| > major weakness is that it makes everythign unergonomic
| in order to make macros very ergonomic.
|
| Generally Lisp has two main goals:
|
| * allow code to be data and data to be code
|
| * make coding and coding code (let code manipulate code)
| interactive
|
| The s-expression based syntax was found to be useful for
| both. For the latter it means that code can be
| manipulated interactively for example by structure
| editors or in read-eval-print-loops which work with data.
| That makes interactive code writing very ergonomic.
| satvikpendem wrote:
| Lisp is homoiconic which most other languages are not.
| This makes it useful for certain applications over
| others.
| citizen_friend wrote:
| Yep, but that and the closely related macro system are
| about the only unique features left. I'll add "has a
| spec" and "is reasonably fast" too.
| samatman wrote:
| Julia has convinced me that the value of this is limited.
| It turns out to be enough to have the AST as a first-
| class value in the language, which can be manipulated and
| emitted via macros at compile time, or fed to eval at run
| time.
|
| The more usual Lisps (I consider Julia, like Dylan before
| it, to be a Lisp) give up most of the advantages of
| syntax in exchange for an admittedly eloquent macro
| system. Julia gets the advantage of syntax, and a macro
| system which is of equal expressive power but less easy
| to use. Also, in Julia, a macro leads with `@`, the way a
| macro in Rust ends with `!`, meaning you can read the
| difference between a macro and a function at the call
| site. I consider that a good thing.
| wbl wrote:
| Some jokes are serious some serious statements are jokes.
| Perlis's epigrams are one example.
| quchen wrote:
| Inhad to look up what Perlins' (!) Epigrams are. Worth a
| read!
|
| https://iiif.library.cmu.edu/file/Simon_box00075_fld05959
| _bd...
| glonq wrote:
| Yeah, this hits hard. Despite being proficient in a bunch of
| languages in college, I could just never wrap my poor brain
| around Lisp.
| bee_rider wrote:
| That's sort of different, right? Rust is just another systems
| language. Lisp is the language that nobody knows but
| everybody secretly believes is better than their language of
| choice.
| gwern wrote:
| He mentions Common Lisp as something he did a game in, and
| you can see the link he praises
| https://www.youtube.com/watch?v=72y2EC5fkcE as basically a
| very well-developed Lisp image approach with timetravel
| debugging etc aimed at game dev. So the implicit comparison
| to Lisps is sort of a big undercurrent to this whole article.
| orthecreedence wrote:
| A lot of the stuff he mentions he wants I kept thinking
| "Oh, you want common lisp!"
|
| I dabbled in some game dev in CL and loved it. I think the
| ideal would be low level engine, lisp on top driving it. If
| you could do it without the FFI barrier slowing things down
| a crazy amount, it would be the killer combo.
| msla wrote:
| >> The problem you're having is only a problem because you
| haven't tried hard enough.
|
| And it actually does work that way with Haskell, in my
| experience. There's a big hill to get over where you flail
| against the type system, IO monad and all, and then you realize
| that, while Haskell's type system isn't perfect, being able to
| say Num t => (t -> b) -> [t] -> [b]
|
| is really pretty powerful, and being able to search for
| functions by type signature is just plain convenient.
|
| But Haskell isn't for every problem in the way Rust is
| apparently made out to be. For example, I've seen some posts
| about developing games in Haskell, but it isn't common, and
| nobody would try to push a game developer into using Haskell.
| usrusr wrote:
| > being able to search for functions by type signature is
| just plain convenient.
|
| It's certainly not all the way there, but now that we are
| over the mostly empty promises of encapsulation and (worse)
| trying to model the world with classes, but grouping by that
| implicit first argument type for discoverability is exactly
| what OOP is, in this age of post-OOP.
|
| The "you're not trying hard enough" position reminds me a lot
| of the Scala community's disdain for java-in-scala-syntax: if
| you don't use it like an almost-Haskell you're on your own
| (1). Here, I think Rust is actually more open: I don't read
| too much of the community, but most of what I saw seemed to
| be quite welcoming to the idea of placating the borrow
| checker with refcounting when "the rust way" fails to
| sufficiently click.
|
| ((1) but with Kotlin having taken over the entire not-almost-
| Haskell part of scala it's not an issue anymore: is has its
| niche and it fills it well, no more taking over the entire
| JVM while also magically converting everybody into an almost-
| Haskellian)
| FrustratedMonky wrote:
| Agree. Some languages like Haskell have a steep learning
| curve, until you grok it. Then you have a big productivity
| gain.
|
| But this article is seeming about someone that has put in the
| time, has written a lot of Rust, and now says, it wasn't
| really worth it.
| citizen_friend wrote:
| What does this after do with the topic?
| msla wrote:
| I'm comparing one unusual language (Rust) with another
| language (Haskell) and examining why the first gets push-
| back whereas the second gets more positive mentions.
|
| They both have a single odd idea that's hard to wrap your
| head around at first, Rust's borrow checker and Haskell's
| type system with its enforced immutability by default, and
| which intentionally drives program design, in that both
| languages demand you write your program such that the
| static analysis can prove it's valid, but Rust's borrow
| checker seems to get more people throwing their hands up
| and leaving the language than Haskell's type system does.
|
| Haskell's type system can be a bit inexpressive, sometimes,
| too, and there are language extensions which address some
| of this, but it seems to hit more of a sweet spot where, in
| most programs, if the type system is forbidding something,
| you really do have some kind of error in your thinking
| leading to inconsistent code. Plus, it enables design
| instead of just forbidding, because you know that any
| function which is valid in the type system is at least
| sensical to use in a given context.
| Aurornis wrote:
| Parts of the Rust community are toxic indeed, but I've been
| around long enough to recognize the same pattern in communities
| of other hot programming languages or frameworks in their up-
| and-coming phase.
|
| There's something about the new hot language/framework/paradigm
| that always attracts the type of people who wrap their identity
| up in the hot new thing. They take any criticisms of their new
| favorite thing as criticisms against themselves, and respond
| defensively.
|
| What I see now in certain Rust communities feels a lot like
| what I saw in Golang communities in the early days. I had
| similar experiences when React was the new kid on the block,
| too.
|
| Some of these communities/forums are just inhabited by people
| who thrive on dunking on noobs all day long. The good news is
| that they tend to get bored and move on when the next new thing
| comes out.
|
| I'm already seeing this in my local Rust community as the
| chronically online people are moving on to Zig now. They even
| use one of the Rust discords to advertise their Zig meetups and
| proselytize about Zig at every opportunity. Eventually they'll
| get bored and move on.
|
| > > That being said, there is an overwhelming force in the Rust
| community that when anyone mentions they're having problems
| with Rust the language on a fundamental level, the answer is
| "you just don't get it yet, I promise once you get good enough
| things will make sense".
|
| I don't fully agree with this assessment. In my experience,
| Rust community members who arrive with well thought out
| complaints or suggestions are welcomed by the people who like
| working on programming language fundamentals. You can nerd
| snipe a lot of Rust enthusiasts by showing up with a difficult
| problem involving tricky parts of Rust, which will often result
| in some creative solutions and discussions.
|
| On the other hand, Rust communities are inundated with people
| trying to write Rust as if it was their old favorite language.
| I've spent a lot of time trying to get people to unlearn habits
| from other languages and try to adopt the Rust way of doing
| things. Some people refuse to let go of paradigms once they've
| used them for years, so doing things the Rust way isn't going
| to work for them. I've worked with enough people who spent more
| time fighting against Rust than trying to adopt Rust ways of
| doing things that I've also reached the point where I don't
| engage once I see the conversation going that way. Can't please
| everyone.
| d0mine wrote:
| unrelated: the word "toxic" is meaningless nowadays e.g.,
| "dunking on noobs" is more specific.
| bmitc wrote:
| > Parts of the Rust community are toxic indeed, but I've been
| around long enough to recognize the same pattern in
| communities of other hot programming languages or frameworks
| in their up-and-coming phase.
|
| I would say that in general, this type of attitude permeates
| a lot of software engineering, and even engineering and
| science as a whole. When I speak with people in other fields,
| particularly more creative ones, the discussions are so much
| more improvisational and flowing. Discussions with software
| developers, engineers, and scientists have this very jerky,
| start and stop "flow" to them as you meet resistance at each
| step. I honest to god have had people telling me no or
| shaking their head no before I ever finished my question or
| statement, much less before they even understood it.
|
| > There's something about the new hot
| language/framework/paradigm that always attracts the type of
| people who wrap their identity up in the hot new thing. They
| take any criticisms of their new favorite thing as criticisms
| against themselves, and respond defensively.
|
| You're spot on about the coupling of someone's identity with
| it. Rust especially seems to also have this never-ending gold
| rush to be the next framework and library everyone uses,
| which creates a very competitive landscape. And it seems most
| frameworks and libraries get 80% of the way and then fizzle
| out once people realize Rust isn't a magical language that
| solves all your problems.
| sesm wrote:
| Conversations that people have in science and engineering
| are more analytical and pessimistic, where they try to
| clarify and set the boundaries.
|
| This is the opposite of creative and optimistic
| conversation, where you break boundaries between things to
| create something new.
|
| The attitude to be analytical in conversations comes from
| the fact, that software engineers usually do creative part
| of their work alone, and use communication for analytical
| part (code review, requirement clarification, etc). For
| some creative people it's natural to do creative work
| together, especially in music, so it's easier for them to
| adopt a creative attitude in conversations.
| candiddevmike wrote:
| > What I see now in certain Rust communities feels a lot like
| what I saw in Golang communities in the early days. I had
| similar experiences when React was the new kid on the block,
| too.
|
| Go was released in 2012, Rust in 2015. Are you saying we are
| still in the early days of Rust?
| shrimp_emoji wrote:
| Yes.
|
| C was invented in the '70s and only got standardized 20
| years later.
|
| And Rust's ~20 years is young in systems lang terms (the
| alternatives, C and C++, are 50 and 40 years old).
|
| And nobody had TikTok back then.
| sk11001 wrote:
| You're moving the goalposts though, the question was
| about Go. Which 3 years ago was nothing like Rust today.
| Because it's much more pragmatic "here's the trade-offs
| we had to make and why" language. Growing in and out of a
| cult isn't a natural part of a language's evolution like
| the GP comment suggested.
| carbotaniuman wrote:
| This is definitely untrue. I was bullied out of the
| golang community for asking about generics when I first
| started learning it. Obviously, I don't think my
| experience is indicative of the entire community, but the
| experience from the community left a bad taste in my
| mouth.
| Rican7 wrote:
| > And Rust's ~20 years
|
| huh? It's only been about 9
| layer8 wrote:
| It was started in 2006 and sponsored by Mozilla from 2009
| on.
| Aurornis wrote:
| > Go was released in 2012, Rust in 2015. Are you saying we
| are still in the early days of Rust?
|
| Release dates mean very little. Golang had rapid adoption
| early on. Rust only recently became one of the fastest
| growing languages. Golang stabilized a lot of things about
| the language and library early on. Rust still has a lot of
| common features gated behind nightly.
|
| There is a fun tool for comparing the number of PRs on
| Github by language that shows the difference:
| https://madnight.github.io/githut/#/pull_requests/2024/1
|
| So yes, I think we're in the early days of Rust.
| evilduck wrote:
| Ruby was released in 1995 and didn't really have its heyday
| of developer hype until Rails came along a decade later.
| Python didn't start gaining serious traction for about a
| decade after its 0.9.0 release either. Go's immediate
| uptake seems like an outlier in programming language
| lifecycles.
| Pannoniae wrote:
| "On the other hand, Rust communities are inundated with
| people trying to write Rust as if it was their old favorite
| language."
|
| This is perfectly understandable if you view languages as
| tools. If the new tool can't do something the old one did,
| then you'll have questions about using it. A great example is
| inheritance - if inheritance is missing, that's a negative
| for me. I don't care about the philosophy, I just want to use
| the tool to produce programs better and faster. If it's
| missing features, that's a negative point.
| klodolph wrote:
| > Parts of the Rust community are toxic indeed, but I've been
| around long enough to recognize the same pattern in
| communities of other hot programming languages or frameworks
| in their up-and-coming phase.
|
| Yeah. I think there's also a weird way that newcomers get
| treated when they join a community. When you're a newcomer to
| Rust, you probably have some preconceptions about how Rust
| should work based on the other languages you know, and you're
| probably running into a lot of the same problems with Rust
| that everyone else has (e.g. borrow checker).
|
| Most of the community is just kinda tired of the discussion
| and tired of answering the same questions, so they don't
| interact with the noobs at all. That means that the people
| who, as you say, "thrive on dunking on noobs all day long",
| are the primary point of contact for noobs.
|
| Finding a decent programming community these days is a pain
| in the ass. The cool people, i.e., the people working on cool
| projects and getting shit done, are mostly busy and not
| hanging out with anybody.
| p0w3n3d wrote:
| Sounds like a no-true-Scottsman fallacy
| ChubbyGlasses wrote:
| This was my biggest problem with rust, the community is, at a
| surface level friendly, but the moment you try to say something
| against the grain you get met with some of the most
| insufferable people ever. I tried to mention a problem with a
| lint on the official forms and the replies were so
| condescending (from regulars at that too). And at no point did
| they try to understand the issue, they just assumed I was
| dumb/new/doing something wrong.
| jonnycat wrote:
| The attitude is perhaps not surprising from a community whose
| unofficial tagline is "Rewrite it in Rust".
| Dalewyn wrote:
| >> The problem you're having is only a problem because you
| haven't tried hard enough.
|
| >You just need to read another 50,000 word fasterthanlime
| essay. Then you'll not have problems any more.
|
| I'm reminded of a line from Hachiman in Oregairu: "Something is
| only a problem when someone makes it a problem."
| cornholio wrote:
| Rust is a language with a very high mental cost to use
| effectively. It requires some fundamental paradigm shifts in
| the way you write software, hence it's a hard language to be
| productive in.
|
| For some tasks, the tradeoff is worth it. Some individuals are
| naturally very inclined to use it.
|
| But for most people, for most tasks, it's simply not the right
| tool. It's not a general purpose language by any stretch of the
| imagination.
| emporas wrote:
| If there were only two programming languages in the whole
| world, just two, no more; one better fitted for OS kernels
| and one better fitted for game programming, which one would
| be considered a general purpose language?
|
| I would argue, OS programming is definitely more general than
| game programming. Rust is great for OS related tasks, math,
| deep learning n other stuff, and maybe not so great at GUIs,
| or even bad at that, or just inconvenient as the article
| points out.
|
| That means, it should be used for general stuff, and for
| programming games should be used a niche language, like Lua,
| Python etc. Especially for fast iteration and
| experimentation, break things and move lightning fast, typed
| languages are in disadvantage for sure, compared to
| untyped/weakly typed.
| syndicatedjelly wrote:
| The thing that the Rust community thinks sets them apart (their
| community), is really the thing holding them back.
| hot_gril wrote:
| I don't think it holds them back. Rust is just not an amazing
| special tool for game dev it seems, doesn't matter how the
| community behaves. It's still a solid choice for systems.
| jsheard wrote:
| Has there been any progress towards shipping Rust on consoles? I
| know the specifics are all under NDA, but to my knowledge nobody
| has even hinted that they've done it yet, even among the studios
| which are openly using Rust for backend or tooling stuff (e.g.
| Embark and Treyarch).
|
| OP only appears to release their games on PC so it's not a
| concern for them, but for the majority of developers not being
| able to fit into console toolchains would be an immediate
| dealbreaker. I have no first hand information but what I've
| _heard_ from hanging around people who would know is that Sony
| insists that developers only use their official LLVM /Clang fork
| which is customised for their weird ABI.
| Klonoar wrote:
| Rust has had tier 3 support for the Switch since 1.64, I
| believe. Someone had actually done it even before that but IIRC
| NDAs mucked up any movement on making that public.
| jsheard wrote:
| Yeah, that Switch support was added by the homebrew side of
| the fence though so I don't know if it's something that
| developers would be able to use in an officially licensed
| game. Nintendo might not care so much as long as the game
| works, as mentioned it's Sony in particular that I've heard
| is picky about which compilers their developers use.
| api wrote:
| > Making a fun & interesting games is about rapid prototyping and
| iteration, Rust's values are everything but that
|
| I feel like this is the core of the author's frustration.
|
| Rust is a systems language. It's for writing tight fast C-like
| code but safely and with a much more powerful type system.
|
| The facilities you need to do this are somewhat at odds with what
| you want for rapid iteration.
|
| Seems like Rust was the wrong tool for the job.
| zooq_ai wrote:
| Exactly!
| amelius wrote:
| C/C++ -> move fast and break things
|
| Rust -> move slowly and don't break anything
| persnickety wrote:
| In my experience, Rust -> move faster than C/C++ because
| you don't have to keep fixing things.
| SleepyMyroslav wrote:
| If they tried to use C++ it would have ended absolutely the
| same way.
|
| As someone who works in gamedev I can assure you C++ is
| same bad choice for 2 man indie project. In search of fast
| iteration times games have moved away from writing code in
| low level languages. Hardware for casual games is much
| bigger and faster than anything small team is able to make.
| api wrote:
| Yes, and if you want move fast and don't break things you
| need a higher level language like Go, Java, C#, etc.
|
| I'm pretty fast in Rust but not as fast as Go, mostly
| because Rust's type system and borrow semantics come with a
| higher cognitive load.
|
| I find both to be faster than C++. Rust is faster because I
| have to worry less about blowing my feet off with memory
| errors. I can't think of anything to recommend C++ now that
| Rust exists.
| gaogao wrote:
| Yeah, I rather like the pattern of embedding a more rapid
| iteration scripting language on top for game stuff like Lua or
| stripped down Python variants, using Rust as the core and hot
| loop code. That said, there is a lot of folks wanting to do it
| all in Rust, and the article touches pretty well on that not
| being the pleasant case for a lot of valid gamedev approaches.
| Legion wrote:
| > Seems like Rust was the wrong tool for the job.
|
| Sure, but the problem is when you have a community around that
| tool that _insists_ otherwise.
| andrepd wrote:
| Can you please give an example of that? Rust is very much
| advertised as a _systems programming language_. Can 't really
| blame people for using it and going "oh it's harder than go
| and python"...
| alex_lav wrote:
| From the website:
|
| > From startups to large corporations, from embedded
| devices to scalable web services, Rust is a great fit.
|
| Are these "systems"? FWIW "systems" does not appear on the
| Rust home page.
|
| From wikipedia:
|
| > Rust is a multi-paradigm, general-purpose programming
| language that emphasizes performance, type safety, and
| concurrency.
| andrepd wrote:
| >performance, type safety, and concurrency
|
| So... a systems programming language? x)
| alex_lav wrote:
| If all software programs are _systems_, yes :)
| taylodl wrote:
| I would think a modern systems language such as Rust wouldn't
| require a systems development methodology from the 1970's.
| There's no inherent reason you _shouldn 't_ be able to rapidly
| prototype a system and then refactor the prototype into your
| actual implementation.
| chimen wrote:
| Rust is the "frontend wave" of the backends. All the woke kids
| gravitate towards it. A suffix of "Written in Rust" is a thing
| here so I'm throwing away my internet points now.
| cmrdporcupine wrote:
| ... complains about people using tropes and tired cliches in
| posts while using the worst of them, themself
| chimen wrote:
| I do not complain. I've seen this trend multiple times by
| now. First time was with Ruby on Rails I think [1], then the
| cancer that led us to write JS to output HTML and all the
| good stuff that came and still manages to pour from npm.
| Every now and then you can spot the "fashion" out of these
| things.
|
| Rust is good and has earned its place. I just despise cult-
| like followings for these languages and technologies.
|
| [1]
| https://www.youtube.com/watch?v=YZeZsZEEpno&themeRefresh=1
| cmrdporcupine wrote:
| There's no need for you to blather about "woke" and drag in
| US culture wars nonsense. It's distasteful, glib, and
| frankly not very intelligent, and just subtracts from
| whatever your point was.
| chimen wrote:
| As I said above, cult-like. They will swiftly call you
| names if you even dare to question their beliefs. Thank
| you for proving me right kind sir.
| obdev wrote:
| Your post is "flagged" to oblivion, just like my earlier
| post questioning the "inclusive" culture of the Rust
| community.
|
| What is it called when a person or group's actions don't
| match their words?
| amelius wrote:
| I think most people here understand that a language that is
| great for kernel development isn't necessarily great for
| everything else.
| cmrdporcupine wrote:
| I work fulltime in Rust (embedded stuff) but actually think
| the "everything else" influence into Rust is stronger than
| the systems stuff, and it's harming the ecosystem.
|
| Just try finding e.g. an MQTT or WebSocket or etc library
| that doesn't drag the whole mammoth tokio ecosystem (which is
| really geared for Web Scale! projects) in with it.
|
| Rust is becoming the language that tokio ate, and
| Cargo/Crates.io the new NPM.
|
| That is, Rust is the systems language that a wave of non-
| systems developers insist on using, leaving behind a trail of
| non-systems-appropriate crates and projects.
|
| Parent commenter's comment was crap by HN's commenting
| standards... but the underlying point about trendiness I
| think is in fact accurate.
| umanwizard wrote:
| I used Rust professionally up until this year (since before
| async landed) and IMO you've hit the nail on the head. The
| shoehorning of async into the language and ecosystem seemed
| to be driven by the belief that if Rust can't attract Go or
| Python developers then it will fail. In fact Rust was doing
| fine in its niche attracting C++ developers and trying to
| make it everything to everyone has diluted what was great
| about it.
|
| (That said, your example might be a bit exaggerated as I
| found mqtt libraries that don't require tokio).
| cmrdporcupine wrote:
| Just like C++, teams will end up having to carve out a
| sane subset comfortable for their domain.
|
| For myself that's looking more and more like:
|
| Ditch crates.io (and maybe even Cargo), carefully curate
| and vendor all dependencies.
|
| Probably avoid async, but definitely avoid tokio.
|
| Don't get excessively clever. (Here I think Rust does a
| better job of C++ of having good "community standards"
| already)
| chimen wrote:
| Oh the language is good, it's the people. Cult-like.
| glonq wrote:
| Would that make rust a _cargo cult_ ?
| lelanthran wrote:
| > Oh the language is good, it's the people. Cult-like.
|
| I used to read something similar all the time around 20
| years ago: I don't have anything against Jesus. It's his
| fan club that's a pain in the ass.
| jimbob45 wrote:
| It can be though. You should be able to express low-level
| details but also implement high-level constructs effortlessly
| should you so choose.
|
| Look at C++, which can both dick with move semantics but also
| offer multiple inheritance. Even better, look at C#, which
| has pointer fiddling but also offers the best reflection of
| any language today.
|
| You're right that Rust is only really good for kernel
| development but it didn't have to be that way.
| zooq_ai wrote:
| tl;dr -- Rust is not the language for startups who want fast
| iterations and are still finding it's pmf. It is perfect for
| rewrites of popular system software which already has millions of
| users and running in production because once a software becomes
| mature and at million user scale, safety and security becomes
| paramount
| swatcoder wrote:
| > for rewrites of popular system software which already has
| millions of users and running in production
|
| Hopefully, it's perfect for more than that.
|
| Rewriting a system that's already acheived that scale is a
| _contentious_ decision, to say the least. Many of our
| colleagues have been lost to and scarred by well-meaning
| attempts to rewrite those systems in the past, including many
| who were sure it was the right choice for "safety and
| security" themselves. For every conceptual safeguard new
| tooling might give you, you invite countless and sometimes
| catastrophic regressions in actual application logic in writing
| new implementations. It can work out, but no tool can expect to
| live only on that kind of work.
|
| I'm sure Rust has much broader applicability than that. Or I
| hope so at least.
| ykonstant wrote:
| At million user scale, feature parity and compatibility is
| truly paramount and, `rg` aside, Rust utils don't have a great
| story to tell there. Such software has evolved in the course of
| decades and its (usually despair-inducing) code is tailored for
| dealing with a tremendous number of edge cases, platforms and
| architectures. Rewrites in Rust tend to write "the cool parts"
| and indeed write them better and faster, but that is just not
| good enough for replacing the standard tools.
| adrianN wrote:
| > I'd argue as far as maintainability being the wrong value for
| indie games, as what we should strive for is iteration speed.
|
| That seems to be the crucial point. Rust is optimized for writing
| complex systems software in large teams. That's not a great fit
| for a small team hacking on something that is at least in part an
| art project. You wouldn't choose something like Ada for that
| either.
| elteto wrote:
| I copied this exact same snippet and was going to comment the
| exact same thing.
|
| Why choose Rust if you don't care about maintainability and
| long term stability? Those are core values of the language!
|
| The language choice was wrong from the start. C++ is king for
| games so if you care more about delivering features and fast
| prototyping why not go with that?
|
| Maybe Rust is not a good language for rapid iteration in the
| game industry. And that's ok I think.
| gfodor wrote:
| C++ is king for _game engines_ , but many games opt for
| languages like Lua or Unreal Blueprints because C++ is to
| those as Rust is to C++
|
| Personally I like Javascript
| elteto wrote:
| Right. Yes, you are correct. I assumed C++ was the language
| they replaced with Rust because they wanted to write lower
| level stuff, like their own engines (and they mention doing
| that).
|
| It makes even less sense to use Rust to replace one of the
| higher level languages like C#.
| zozbot234 wrote:
| Rust is not antithetical to iteration-based programming, it
| just makes you write a lot of heavy boilerplate to explicitly
| support that kind of style. The flip side of that is once the
| 'iteration'/'prototyping' phase is over, you can actually
| refactor the prototype into high-quality production code,
| instead of either throwing it away altogether and rewriting it
| from scratch (spoiler alert: this doesn't really happen most of
| the time, because it's viewed as pointless waste) or just
| putting it in production as-is (which is what people actually
| do, even though it's obviously a disaster in the longer run).
| stnmtn wrote:
| Surely there's better choices if the primary desire is
| iteration speed, and a secondary or maybe even tertiary
| desire is maintainability/refactorability
| hot_gril wrote:
| Rust gets in the way a lot, as it's supposed to for safety.
| Maybe it'd be a lot faster to iterate on if some AI could
| auto fix your code to make the compiler happy.
| jcranmer wrote:
| No, Rust is pretty antithetical to iteration-based
| programming. The language basically requires you to plan for
| the ownership model from the beginning, and it can be quite
| difficult to retrofit a changed ownership model into an
| existing program.
|
| I've run into this in a side project I'm working on, where my
| indecision over which ownership models are actually workable
| in the API to satisfy the needs I have means almost all of
| the coding is spent just proving I can get an ownership model
| working over having a skeleton code that can do _something_.
| And still, even as lacking as functionality as this codebase
| is, swapping to a new ownership model takes several minutes
| of coding. Trying to do this kind of exploration on a
| codebase that has real functionality would mean spending
| hours of change just to move some property from here to
| there.
| tetha wrote:
| I've ended up with similar thoughts about automated testing in
| games too.
|
| I really enjoy having automated tests and automated tests solve
| problems. Like, I absolutely love our molecule test suite for
| our infrastructure code and it gives us huge value. The smoke
| tests we have for the infrastructure running after deployments
| are amazing. It's liberating in an environment of rapid and
| chaotic changes everywhere, complex interdependencies, as well
| as pressure on top.
|
| However, if I try to transfer that kinda approach to a game it
| just... fails?
|
| But the realization is: In games, many behaviors and systems
| are actually far simpler and less intertwined in arcane ways,
| and code changes actually less frequently and dramatically than
| at work.
|
| I could see structured testing in e.g. turn based strategy
| games and such, so you can test that the culture per turn is
| correctly calculated based off of many different situations and
| such.
|
| But in many smaller projects I've had, you write some janky
| code, make sure the enemy behaves as expected... and never
| touch or change that piece of code ever again. And it just
| doesn't break, because no fundamental part below it ever
| changes, because then the entire house of card would fall
| apart.
|
| It feels dang weird, but it works very well for smaller
| projects.
| dmitrygr wrote:
| The Rust community is one of the top arguments against rust.
|
| I've never before been so condescended to as when attempting to
| ask questions there. Their lack of care for perf also drives me
| up a wall. Anytime they propose adding an extra layer of
| indirection to get around the borrow checker, I have to explain
| yet again that with the way modern CPUs work, extra layers of
| indirection have serious cache-related perf costs. Then I get
| told that I am yet again doing it wrong, computers are fast
| enough, and I am worrying about the wrong thing.
| JoshTriplett wrote:
| > when attempting to ask questions there
|
| Could you please give an indication of which venues you've
| encountered this kind of condescension in? I don't tend to see
| this in the spaces I frequent, but I know it _is_ happening,
| and I wish it weren 't. We try, sometimes, to provide some
| official messaging discouraging this kind of condescension, but
| perhaps there's something more we can do.
| mrkeen wrote:
| I think I found it:
|
| >> Their lack of care for perf
|
| >> I have to explain yet again
| hot_gril wrote:
| Many of us have probably heard that all the dumb programmers
| use Javascript, but even if that's true, that's a reason for me
| to use it. Even though I'm capable of using galaxy-brained
| language ecosystems, I don't need that mental overhead. And if
| it'll be cheaper to hire JS programmers onto the team, great.
| throwaway63467 wrote:
| Unity is so good and quite affordable, basically there's zero
| upfront risk of using it. Similar for Unreal Engine. And then
| there are tons of other open-source engines like Godot that are
| also quite good.
|
| Rust is great from lots of stuff but game development or building
| UIs isn't among that (yet).
| airstrike wrote:
| To be fair, building UIs with iced-rs is getting better by the
| minute. My favorite showcase for using that library is this IRC
| client called halloy: https://github.com/squidowl/halloy
| TulliusCicero wrote:
| > Unity is so good and quite affordable, basically there's zero
| upfront risk of using it.
|
| Other than the absurd license changing shenanigans they tried
| to shove through recently. Hopefully they learned their lesson.
| VS1999 wrote:
| Unity learned that they have to turn the temperature up
| slower. They kept the new license that everyone was mad about
| but just made it so you can keep your current license if it's
| cheaper for you. No doubt they'll be tweaking these values
| over time.
| TulliusCicero wrote:
| Yeah, that's definitely a concern I have. Well, projected
| concern I guess, I'm using Godot myself rather than Unity,
| mostly because I found Unity way more confusing when I
| tried to learn it. But not needing to worry about licensing
| with Godot is certainly a nice bonus.
| nu11ptr wrote:
| As much as I love Rust I sometimes wonder if I'd be more
| productive in a simpler language. If I wrote it every day I'm not
| sure that would be true, but as a hobbyist coming back to Rust
| sometimes takes me a bit to get back in the zone. Also, still not
| a fan of async, as it is woefully incomplete and fairly
| complicated in some use cases. That said, I just can't go back to
| Go with nil pointers and lack of decent enums/ADTs/pattern
| matching either. I long for the "in between" language, but with
| an amazing 3rd party ecosystem as both Rust/Go have.
|
| NOTE: I'm not a game dev
| BoorishBears wrote:
| Isn't that just Swift/Kotlin?
| nu11ptr wrote:
| The problem with languages is they don't compose. Iow, one
| missing feature needed automatically invalidates the language
| entirely. Swift is targeted at Apple platforms and cross
| platform is an after thought. Kotlin targets JVM and while it
| is cool in concept, I hate it as a user (and Kotlin native
| isn't near as mature). If were considering something else at
| this stage I'd probably put my time into F#, but even it has
| its cons.
|
| NOTE: By "compose" I mean that if I want feature A, B and C
| from lang X (has A and B), Y (has B and C) and Z (has A and
| C), but there is no way to get A, B and C in one language
| without creating a brand new one. I cannot mix and match
| features from different languages.
| BoorishBears wrote:
| They don't compose what? Is this one of those 'monad is an
| endofunctor' deals?
|
| (me not knowing might be the ignorant bliss that allows me
| to just do productive things in them regardless)
|
| Edit: I understand from the updated comment
|
| I've long accepted that no one language can offer all of
| the language features I'd want, but I also question if I'd
| even want that language if I got it
| akavi wrote:
| It's any of:
|
| Rust + (garbage collector)
|
| Swift + (cross platform support)
|
| Kotlin + (proper pattern matching)
|
| Unfortunately, none quite hit that central sweet spot, IMO
| tkz1312 wrote:
| Roc is looking very promising IMO
| melodyogonna wrote:
| Mojo soon
| MrBuddyCasino wrote:
| And Zig maybe?
| Scramblejams wrote:
| I've been hoping to see more languages that compile to Go, it
| might be the most practical way to arrive at what you want. For
| example, see Borgo:
| https://news.ycombinator.com/item?id=36847594
| nu11ptr wrote:
| I keep toying with the idea of creating one. :-)
|
| Borgo looks neat - hadn't seen it before.
| ReleaseCandidat wrote:
| > I've been hoping to see more languages that compile to Go
|
| One could also use Go-Assembler as a cross-platform assembly
| target: https://go.dev/doc/asm
| brabel wrote:
| Maybe people will make fun of me, but I've been very happy with
| Kotlin and Dart. Null-safe, good ergonomics, very fast.
|
| I've tried Rust, sometimes play with C, D, Deno/TS, Nim, Java
| (actually I still write lots of it) and even some more cutting-
| edge stuff, like Unison. While they're cool, what I want is a
| language with really good tooling that gets out of my way
| without letting me write patently dumb code (like Java lets me
| use any object without checking for null, when it can be null
| but the language just doesn't give a shit to help me).
|
| I use Dart when I want to compile to binary executable or use
| Flutter, and Kotlin for stuff I think the JVM has more to
| offer, like a server. The two languages are just a pleasure to
| use, pretty similar but having completely different ecosystems
| (which is great, you can use the best one for the job!).
| nu11ptr wrote:
| I'm glad you found tools/languages that work for you. Kotlin
| felt a little too much like Java to me. If I stuck with a JVM
| lang. I'd probably go back to Scala 3, but I just don't like
| the JVM as a user (just sucks too many resources).
| ImHereToVote wrote:
| Flutter sounds so awesome but really want something like
| OpenGL for it.
| YawningAngel wrote:
| I like Kotlin but I find the fact that it lacks a good way to
| detect and handle possible errors very frustrating. If some
| function can fail on sane-looking input I'd like to know
| about it
| andrepd wrote:
| Rust is in a separate class of go and swift and kotlin and etc.
| The class it competes on is pretty C, C++, and itself.
|
| Yes it's easier to write trivial code in python than Rust. Yes
| it's harder to manage memory manually than it is to let a gc
| handle it. I don't see the point.
|
| Rust is a systems programming language. It's hard to write a
| server in it than it is to hack something in node, but it will
| also be faster and more reliable. Conversely, it's easier than
| writing it in C++ or C, while still being more reliable. That's
| the whole value proposition.
| astrange wrote:
| Swift has a systems programming subset, and an even smaller
| embedded programming subset.
|
| Of course "smaller" is significant here; it has less features
| and you might not like using it anymore.
| margorczynski wrote:
| > I just can't go back to Go with nil pointers and lack of
| decent enums/ADTs/pattern matching either.
|
| Go is simply a badly designed language where the idea of
| "simplicity" has been maligned and proven bad ideas likes
| nil/null, exceptions and such have been introduced in a
| seemingly modern language. One would think that decades of
| Java, Javascript, etc. code blowing up because of this issues
| would teach someone something but seems that is not always the
| case.
| nahnahno wrote:
| And yet it is incredibly productive. The poster that
| contrasted engineers with artists got it right I think. Go is
| an engineer's language.
| grumpyprole wrote:
| > Go is an engineer's language.
|
| No, Ada/Spark is an example of a good engineers language.
| Go is a mediocre effort at best. Rob Pikes defence is that
| it was designed for junior Googlers who "aren't capable of
| understanding a brilliant language". Yes that's a real
| quote.
| lagichikool wrote:
| "code blowing up because of this issues"
|
| I ran into these issues all the time with Java, C++, and
| Python projects.
|
| But it's just not the experience of running Go in production,
| which I've been doing for over 10 years now, across many
| projects with many devs.
|
| In practice, nil checks are just not very difficult to
| include everywhere. And experienced Go programmers don't use
| exceptions (panic/recover) almost ever.
| kbolino wrote:
| Having worked with Go for about a decade now, I largely agree
| that nil is a pain in the ass to work with, and the language
| has largely done nothing to make it better. However, Go
| (mostly) doesn't have exceptions. Ordinary problems are
| represented by non-nil errors, which are values. Panics exist
| but really are reserved for exceptional situations (with the
| number 1 cause being, of course, dereferencing nil).
| sidkshatriya wrote:
| Nil in go is my biggest gripe with the language. Why keep
| repeating "the billion dollar mistake" in a relatively
| newly designed language??
| kbolino wrote:
| There are a lot of ways in which Go handles nil better
| than C handles NULL. At the very least, a panic is better
| than a segfault. And carefully written code can avoid
| most kinds of nil panics entirely. So I guess the
| language's authors thought this would be enough to
| overcome the mistake. But I don't think they went far
| enough. The very limited type system and the lack of nil-
| safe operators make it not very ergonomic to write and
| read such "carefully written" code; design decisions in
| some key parts of the standard library completely
| undermine the language's attempts to minimize nil; and
| then there's the "untyped nil" default value for
| interfaces, which panics if you just look at it funny.
| sgt wrote:
| I mean.. Java is there. Java 23 is really interesting.
| nu11ptr wrote:
| When is Java getting value types? It has been talked about
| forever now.
| sgt wrote:
| Good question. I think it must be this one:
| https://openjdk.org/jeps/401
|
| I can't see it in the feature list of JDK 22 or even 23.
| Maybe it'll come in JDK 24?
| msgilligan wrote:
| Java 23 is not final and I'm hoping this JEP makes it into
| 23:
|
| https://openjdk.org/jeps/401
|
| I don't follow the JEP process closely enough to know if it
| will be proposed for 23 or approved. But I think it's
| coming soon.
| fire_lake wrote:
| OCaml could be that language.
|
| I'm not convinced that ecosystem is so important for game dev.
| Once you have a simple graphics library, bindings to
| BulletPhyiscs etc most of the code is custom simulation code
| with no integrations needed.
| lawn wrote:
| It doesn't occupy the same space, but the simplicity of Gleam
| has been very enjoyable to me. It's still quite a young
| language though, but worth keeping an eye on.
| notnullorvoid wrote:
| As much as I dislike many of the legacy issues with JavaScript
| I find TypeScript to be the best language to iterate with. If
| Rust had GC without need for wrappers like RC though I think
| that would be my preferred iteration language. I mostly try to
| write my TS in a manner that would translate to Rust, but
| that's hard to do sometimes when it comes to memory management.
| bfors wrote:
| Like the author states, the "written in Rust" bonus many projects
| get does not apply to games. Most of the games I consider to be
| the most fun are built on an absolute rats nest dumpster fire of
| code (see: https://www.youtube.com/watch?v=k238XpMMn38).
| Sometimes bugs even expand game mechanics and make them more fun
| and expressive. That being said I'll definitely check out
| Unrelaxing Quacks, it looks great.
| bdw5204 wrote:
| My impression of Rust is that it's a very opinionated language
| that wants everybody to program in a specific way that emphasizes
| memory safety above everything. That's a good idea, I think, for
| the systems programming use cases that it was intended for. I
| don't see that as a particularly useful thing to value for game
| development. The part in the article about the Rust borrow
| checker constantly forcing refactors sounds extremely obnoxious
| to deal with.
|
| I'd think that an ideal game dev language would be programmer
| time efficient, reasonably performant and designed for skilled
| programmers who can handle a language filled with footguns.
| Basically a better version of C such as a selective subset of C++
| or a Golang without garbage collection. I just don't think the
| kinds of security bugs you get from C/C++ "unsafe" code are that
| big of a deal for games but they would be for a web site or an
| enterprise database.
| baby wrote:
| IMO it's not opinionated enough. Golang for example doesn't let
| you customize go fmt, while Rust does. Rust also has many ways
| to do things in general (mod.rs vs name_of_folder.rs for
| example) and seems to not want to provide a useful baseline for
| most projects via its standard library (unlike Golang).
|
| But to go back to our subject: Rust is a great language and
| that's all you need. I wish I could use it with unity.
| tick_tock_tick wrote:
| The mod vs folder rs stuff is just embarrassing for Rust. I
| have no idea why they support more then 1 method.
| masklinn wrote:
| > My impression of Rust is that it's a very opinionated
| language
|
| It's not though. There's only one thing Rust is opinionated
| about.
|
| > that wants everybody to program in a specific way that
| emphasizes memory safety above everything.
|
| Well yes, that is literally the core proposition and purpose of
| the language. That's like saying java is opinionated because it
| wants to manage the memory.
|
| > I just don't think the kinds of security bugs you get from
| C/C++ "unsafe" code are that big of a deal for games
|
| As soon as games are networked it starts being a problem, and
| these days non-networked games are pretty rare.
| bluGill wrote:
| Rust also is opinionated that you don't want to write shared
| libraries or plugins. You can do both, but only if you drop
| down to memory unsafe C interfaces. The default is statically
| compile all applications into one program. Rust also really
| wants you do to use their build system and package manager,
| you can avoid both but everything will fight you.
| masklinn wrote:
| > Rust also is opinionated that you don't want to write
| shared libraries or plugins.
|
| Not having a solution is not the same as having an opinion.
|
| If you have years to spend on plugging at ABI
| stabilisation, generics and proc macros in dynamic linking,
| and redistributable std, I'm sure the core devs would be
| happy for you to.
|
| > Rust also really wants you do to use their build system
| and package manager, you can avoid both but everything will
| fight you.
|
| What do you mean everything will fight you? It sounds like
| you're confusing rust and its ecosystem.
| jandrewrogers wrote:
| > I just don't think the kinds of security bugs you get from
| C/C++ "unsafe" code are that big of a deal for games but they
| would be for a web site or an enterprise database.
|
| Even for database engines specifically, modern C++ is
| essentially as safe as Rust and significantly more ergonomic.
| Rust's safety features can't reason about the case when all of
| your runtime objects live in explicitly paged memory with
| indefinite lifetimes and no fixed memory address, which is the
| norm in database kernels. You have to write the same code to
| make handling these objects safe and correct in Rust that you
| have to write in C++. You can't use normal pointers and
| allocators for this even if you wanted to.
|
| Rust's safety is designed more for normal dynamic memory
| applications.
| IshKebab wrote:
| > modern C++ is essentially as safe as Rust
|
| This isn't even close to being true. I think memory safety
| isn't as important for games as it is for most software
| (though it is still quite important for multiplayer games!).
| But even if you write the most modern C++ possible I
| guarantee you are going to spend some of your time debugging
| segfaults, memory corruption and heisenbugs. Don't try and
| claim "I don't write bugs". Everyone does.
| jandrewrogers wrote:
| 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-time. If you care about performance and
| scalability, you don't need to concern yourself with multi-
| threading as an issue either. The main way you'd expect to
| see memory corruption is if you try to read/write a page in
| the middle of a DMA operation to the same memory, and Rust
| doesn't help you with that either (though this would be
| just a normal logic bug in the scheduler).
|
| It is pretty easy to avoid segfaults and memory corruption
| in modern C++ if the software architecture doesn't allow
| you to create the conditions under which those are likely
| to occur.
| dario_od wrote:
| You more or less described Zig
| mr_00ff00 wrote:
| Sort of, although Zig certainly pushes itself towards the
| embedded world. I have tried Zig a bit and like it a lot, and
| I am sure it would be better for game dev than Rust, but I
| don't want to pass allocators around all day to all the
| objects in my game.
|
| Go without GC is more like a Go and Zig baby.
| mholub wrote:
| nothing really prevents you from defining global allocator
| in Zig
|
| and having explicit allocator in standard library is
| actually a good thing, cause it's quite a common case in
| game development to use arena allocators which are being
| freed once per frame - so you don't really need to reinvent
| your data structures in Zig
|
| I do have some concerns about Zig because it also
| introduces some friction for correctness sake like
| requiring to always use all variables, explicit casts
| everywhere - I want some compiler toggle to disable all of
| that and focus on problem but unfortunately it's not there
|
| I am playing with Zig now and haven't really formed my
| opinion about game development specifically but I like it a
| lot so far
| throwawaymaths wrote:
| To be fair though that sort of friction only affects
| things _in the small_. They can be annoying but you 'll
| never have to refactor outside the scope of the friction
| itself.
|
| In practice, it's only really a problem if you're doing
| codegen.
| alcover wrote:
| > I'd think that an ideal game dev language would be programmer
| time efficient, reasonably performant and designed for skilled
| programmers who can handle a language filled with footguns.
| Basically a better version of C such as a selective subset of
| C++ or a Golang without garbage collection.
|
| I agree so much that I've been working on this for a whole
| year.
|
| There is a sweet spot : non-GC, with pointers (but bounded),
| inference, basic OOP + tacking, and all the comforts of
| scripts. All in a _good_ looking syntax without semi-colons.
|
| So you can program fast and get a fast program.
| jpardy wrote:
| For me, this is Odin-Lang, it doesn't meet all the
| requirements you have listed, but it's ergonomic, fast, and
| comes with extensive core and vendor libraries. It's all just
| fun and reasonable.
|
| https://odin-lang.org/
| ninepoints wrote:
| This is a very brave post to write given how incendiary responses
| to rust criticism can be, but this matches my experience
| entirely.
| cogman10 wrote:
| > incendiary responses to rust criticism can be
|
| I've not experienced this. Do you have examples of the rust
| community flaming someone for having negative opinions about
| the language?
| chimen wrote:
| yes, keep reading this section
| cmrdporcupine wrote:
| You were flagged for no such thing.
|
| You were flagged for a pointless quip about "woke"ness.
| Other people repeated more civil and reasonably argued
| forms of your same point about the language and its
| community and received no such downvotes.
|
| No need to play martyr.
| tick_tock_tick wrote:
| 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.
| the_mitsuhiko wrote:
| That does not mirror my experience.
| gpm wrote:
| Rust hasn't had a mailing list for roughly a decade now...
| astrange wrote:
| If it helps, they can't possibly be as toxic as Lisp
| programmers used to be, where more or less any online
| conversation would start with someone new asking a question
| and Erik Naggum replying that they were a moron who should
| die.
| cogman10 wrote:
| Lol, I had a similar example with perl as a young teen
| programmer.
|
| They've gotten way nicer.
| cogman10 wrote:
| 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 the top comments are all really
| positive towards this article. That's what I've seen at
| typical in the rust community.
|
| https://www.reddit.com/r/rust/comments/1cdqdsi/lessons_lear
| n...
| sanderjd wrote:
| I think I just read about 10 versions of this comment on this
| page, and definitely not a single response to the criticism
| that could be described as incendiary. I don't think I even saw
| a single comment just now that fundamentally pushed back on the
| premise of this article, let alone in an incendiary way. It's
| early yet, and maybe this thread will look very different in a
| few hours though?
| thegrim33 wrote:
| The author maybe somewhat hit on the reason for this in the
| article, where they mentioned that they're already seeing
| some of the rabid, toxic, Rust proponents already moving onto
| the next "hot" thing and doing their thing there. So maybe
| after a few years of Rust we've arrived at the turning point
| now where enough of those types of people have finally moved
| on and the Rust community has significantly changed.
| ziddoap wrote:
| Perhaps because the article is about how Rust isn't the magic
| bullet to everything, and a few people have commented
| agreeing with the article, others feel more willing to
| comment their own Rust isn't perfect opinion as well.
|
| If you go into the comment section of a pro-Rust article,
| where the first few top-level comments are also pro-Rust, the
| responses to people expressing a negative attitude about Rust
| tend to (in my experience) be different.
|
| This phenomenon certainly isn't exclusive to Rust (or HN). It
| happens all the time, especially when a prolific commenter is
| among the first few comments. It can set the tone for the
| entire comment section.
| vacuity wrote:
| Sounds like a forum that scrambles comments could be
| interesting.
| martin-t wrote:
| I assure you it happens, but the people targetted this way
| usually quickly learn what is ok and what isn't to say,
| especially on rust's reddit. If you wanna see examples, look
| at my reddit profile (same username). I dared to say bevy was
| full of hype and false promises and tat the money they get
| would be better spent elsewhere. And look at the hate i
| received.
|
| One way i've seen to reduce this is prefixing any posts with
| "I am not criticizing any engine in particular" even if it's
| blatantly obvious because the criticism only applies to one.
| sanderjd wrote:
| I guess I interpreted the comment as meaning that the
| incendiary responses were going to be seen _here_. I would
| expect incendiary responses to _anything_ I post on
| reddit...
| SantalBlush wrote:
| This is a textbook example of poisoning the well. [0] We see it
| used in every discussion about pros and cons of a language on
| HN.
|
| It's some variation of "People who like this language can't
| handle criticism/are part of a cult/etc." The idea being that
| this will preclude anyone from responding to a criticism,
| because that would confirm the comment.
|
| [0]
| https://www.logicallyfallacious.com/logicalfallacies/Poisoni...
| telekid wrote:
| This article describes almost exactly why I think gradual typing
| is actually a good thing. Type checkers shouldn't get in the way
| of your code compiling. Yes, the language has to be designed with
| this property from the beginning. Yes, you should always enforce
| complete checking in CI. But you should also be able to try half-
| baked ideas.
| zogrodea wrote:
| There are at least a few nascent statically typed languages (as
| in, full static typing rather than gradual) which nevertheless
| let code with type errors compile for the sake of testing.
|
| The two that I know of are Darklang [0] and Roc [1] which aim
| to let you compile code with type errors for the same reason
| you suggest.
|
| [0] "Dark is designed for continuous delivery. As such, we
| don't like requiring you to make large scale changes across
| your program, like changing a type everywhere. Instead, we want
| you to quickly discover that bad ideas won't work, without
| first requiring you to propagate the type changes throughout
| your program."
|
| https://blog.darklang.com/real-problems-with-functional-lang...
|
| [1] "If you like, you can run a program that has compile-time
| errors like this. (If the program reaches the error at runtime,
| it will crash.)"
|
| https://www.roc-lang.org/friendly
| valcron1000 wrote:
| Let me introduce you to `-fdefer-type-errors` in GHC Haskell:
|
| https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe.
| ..
| duped wrote:
| > Type checkers shouldn't get in the way of your code
| compiling.
|
| I don't get it, what's the point of type checking if not to
| reject invalid programs? The point of a type system isn't
| simply to add annotations to a programmer (and some type
| systems can omit them entirely) but to define the subset of
| programs that are correct within the set of all the programs
| that can be expressed.
|
| I understand (and have used in production) optionally/gradually
| typed languages, and without fail codebases will opt for using
| types up front and not ignoring type check failure because they
| are always incorrect.
|
| A type error is the compiler/run time telling you "I don't
| understand what you told me" so why do you want to ignore that?
|
| And if the point is that you want to be able to change the type
| signature of something without having to refactor giant chunks
| of code, then that suggests your code is structured poorly to
| begin with. It should be easy to pull in what you need and play
| with it without affecting everything else if you haven't done a
| bad job of architecting the codebase.
| ativzzz wrote:
| 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
| and you don't care if it crashes on any edge case. 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
| dbrueck wrote:
| Exactly this. Typing in the final version is great. Typing
| up front is almost always getting in the way.
|
| Most interesting programs involve a lot of figuring things
| out as you go, and so any "tax" on that process is one you
| hope to avoid. The last thing you want is for the language
| itself to be the source of that tax any more than it has to
| be.
| whytevuhuni wrote:
| I agree with this, but I don't think dynamic types is the
| only solution. Something like Roc[0] strikes a better
| balance: it gives you a flag for development, and when
| enabled, all compilation errors become warnings. The
| compiler substitutes every function it couldn't compile
| with one that panics at runtime.
|
| [0] https://www.roc-lang.org/
| duped wrote:
| 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 it 's impossible to write a
| sound type system that can even touch it.
|
| I don't want to reply "git gud" but I really am struggling
| to understand how people are writing code that where it is
| so difficult to use type information or where changing it
| is so cumbersome that you think it's a barrier. And I don't
| see many games or performant GUIs written in dynamically
| typed languages, particularly outside the web. Even in very
| dynamic languages like Objective C, things are still well
| typed.
| ativzzz wrote:
| > But a type error isn't an edge case! It means you've
| written something the compiler can't understand.
|
| I get it! But the compiler here is getting in the way, so
| Rust is the wrong tool choice here, or for anything that
| requires quick prototyping (like the OP said)
|
| > writing code that where it is so difficult to use type
| information
|
| It's not difficult, it just takes longer. Typing up front
| works well when you know exactly what you're building.
| When you don't, or are doing experimental design, they
| just get in the way until you've settled on a direction.
| This direction is not due to technical constraints or
| language choice, it's simply that designing complex user
| interactions is hard and you don't know it's correct
| until you have users use it
|
| > dynamically typed languages
|
| Because the cost of prototyping in a dynamic lang and
| then fully rewriting in a performant language is higher
| than having slower iteration speeds in typed languages.
| But also, this is why a large number of new non-web GUIs
| use electron (or are mac exclusive, which offers other
| benefits for GUI development)
|
| > I think you've got it backwards - TS is popular because
| people want to use types up front,
|
| Personally, I mix it up. There are things I know what
| their types will be no matter what so i add them up
| front. Then there are other things which I do not know,
| and I add those types at the end once i'm performing the
| final cleanup before code review
|
| The nicest part is, TS runs regardless. I often refactor
| my types frequently since I get them wrong a lot
| (especially the up front ones) and have TS in a failing
| state while developing, but the TS compiler doesn't get
| in my way, and still works for the types that I expect to
| have working
| whoknowsidont wrote:
| >I don't get it, what's the point of type checking if not to
| reject invalid programs
|
| It can take longer to think about how to properly type
| instead of just writing some code, testing it out, and
| immediately seeing if something is wrong. You also often get
| into a situation where linters who like to act like type-
| systems give you arcane errors (looking at you TypeScript).
|
| In the moment I just want to move some data around and
| quickly try out an idea, I don't need it to be resilient or
| perfect.
| Xeamek wrote:
| >I don't get it, what's the point of type checking if not to
| reject invalid programs?
|
| Because not every program that doesn't compile is necessarily
| invalid.
| lelanthran wrote:
| > Because not every program that doesn't compile is
| necessarily invalid.
|
| I think that more programmers should be aware of this
| point. Rust doesn't reject code that will crash, it rejects
| code that it cannot prove _won 't_ crash.
|
| The code being rejected might be just fine (as numerous
| examples in the article showed).
| lelanthran wrote:
| >And if the point is that you want to be able to change the
| type signature of something without having to refactor giant
| chunks of code, then that suggests your code is structured
| poorly to begin with.
|
| The article addresses this, multiple times. In brief, the
| "poor structure" isn't the problem.
| hot_gril wrote:
| It's also pointless to care about types in fine-scoped code.
| Like if your language forces me to assert that i is an integer
| like this, something is wrong... for (int i =
| 0; i < n; i++)
|
| And when I'm writing backends, usually there will be no types
| anywhere except at the API layer, i.e. OpenAPI spec or protocol
| buffers. Not once have I encountered a bug related to
| accidental wrong types that wasn't caught at this outermost
| layer.
| pron wrote:
| All low-level languages (by which I mean languages that offer
| control over all/most memory allocation) inherently suffer from
| low abstraction, i.e. there are fewer implementations of a
| particular interface or, conversely, more changes to the
| implementation require changes to the interface itself or to its
| client [1]. This is why even though writing a program in many
| low-level languages can be not much more expensive than writing
| the program in a high-level language (one where memory management
| is entirely or largely automatic), costs accrue in maintenance.
|
| Now, a language like Rust makes some aspects better because it
| ensures that the maintenance (refactoring) is done correctly --
| reducing the risk of mistakes -- but it comes at a cost: you must
| explain your handling of memory (before and after the refactor)
| to the compiler (plus, the compiler doesn't understand all
| patterns). I think it's too soon to empirically compare this cost
| to the gain in reduced risk and determine when each option is
| more or less advantageous (and perhaps it is also a matter of
| personal programmer preference), the fact remains that
| maintenance of programs in all low-level languages is always more
| costly than maintenance of programs written in high-level
| languages because of the low abstraction inherent to all low-
| level languages.
|
| When writing in a low-level language some may prefer the Rust
| approach while others may prefer less restrictive ones [2], but
| people choosing any low-level language should be aware of the
| added maintenance cost they're invariably signing up for. Sadly,
| this cost only becomes apparent at later stages of the project.
|
| [1]: Some people claim that memory is just like any other
| resource (e.g. file descriptors), but this is incorrect. Memory
| and processing are fundamental to the very nature of abstract
| algorithms, and differences in how memory is handled change the
| available range of algorithms. E.g. finite state machines, queue
| automata, and Turing machines differ only in how memory is
| handled and accessed. In short -- memory and processing are
| special resources and are not the same as IO resources.
|
| [2]: I'm personally not a big fan of Rust's approach -- and I
| particularly dislike C++'s and Rust's "zero-cost abstraction",
| which is the attempt to make the low abstraction ability
| invisible in the final code without changing its fundamental
| aspects -- but I recognise that people's opinions differ on this
| matter. I also reject the claim that there's no middle ground
| between Rust and C that offers an intermediate tradeoff between
| them, i.e. that there is no safety premium to a language that
| offers some of Rust's safety guarantees but not all of them, such
| as Zig, or offers better and effective assurance of some
| properties without a sound guarantee.
| mtlynch wrote:
| Do they say what they replaced Rust with? I scanned through a few
| times and couldn't figure it out.
| tomku wrote:
| They mention that they're moving (back) to Unity/C#.
| mtlynch wrote:
| Ah, missed that. Thanks!
| kimixa wrote:
| I assume from comments like "This is actually the #1 reason
| we're moving back to Unity" they're back in C# using unity
| shmerl wrote:
| _> games are single threaded._
|
| Huh. Not games like Cyberpunk 2077 and it's good that they are
| not.
| kleiba wrote:
| Did you read the part where they said that they're a two-person
| indie game studio with a development cycle of 3-12 months max?
| shmerl wrote:
| That's not an argument against parallelism in game design in
| general.
| kleiba wrote:
| No, but in practice.
|
| Because the type of game you produce in that time frame
| isn't typically the one that needs to worry about
| parallelizing multiple compute units.
| dmitsuki wrote:
| Almost all parallelism in game engines is for very specific
| parts of the engine and almost none of the gameplay stuff
| is paralellizable. What people who haven't actually had to
| go through and solve the problems presented in game engines
| often times misunderstand is that when your game is running
| poorly because everything is happening on a single thread,
| almost all of this speed issue is because of rendering.
| Then physics. These are very hard problems to solve and
| it's more complicated than "use an ECS" to solve them.
| shmerl wrote:
| _> almost none of the gameplay stuff is paralellizable_
|
| Define gameplay. If you have some simulation happening as
| part of the gameplay, parallelizing it can be quite
| useful vs killing one CPU core on it. Physics is just one
| common example, but not everything is about physics. You
| can simulate whatever.
| brabel wrote:
| I had this same pain point though when using Rust that was
| meant to run in the browser (compiles to WASM), i.e. guaranteed
| to be single-threaded. Still had to pay the very high price of
| accessing global state in Rust. Ended up moving that code to JS
| instead just to avoid that!
| WalterBright wrote:
| > Making a fun & interesting games is about rapid prototyping and
| iteration, Rust's values are everything but that
|
| I found this to be true of C after many, many years coding in C.
| I noticed that the first selection of data layout stayed
| throughout the life of the code (with a lot of tweaks, additions,
| etc.). But didn't really think that much about it.
|
| Until I started writing code in D. It was easy to change the data
| layout, and I did for experimenting. For example, changing a
| reference type to a value type, and vice versa. This was easy in
| D. It's just too much work in C, so it didn't happen.
|
| The reason is simple: p->b v.b
|
| To switch between a ref and a value type, you've got to
| search/replace the -> into ., and the . into ->, and not disturb
| the dots and arrows of the other types. When dealing with 100,000
| lines of code, this is a non-starter.
|
| But with D, both reference and value types are used as:
| p.b v.b
|
| making it easy to switch between the two, and also switching
| function parameters from values back and forth with references.
| lylejantzi3rd wrote:
| You could hack the C compiler!
|
| https://github.com/tsoding/tic-tac-toe-auto-deref
|
| https://www.youtube.com/watch?v=yKI-VOBBFu8
| dist1ll wrote:
| That's a good example. I actually think dot syntax is really
| under-utilized sometimes. Although personally, I'd prefer that
| if v was a reference/pointer to a struct, that v.b simply
| performs a pointer offset, instead of auto-dereferencing like
| ->.
| p0nce wrote:
| I agree, and D with the GC lets me prototype quickly. Its type
| system gets progressively stricter with constraints, for code
| that survives. I wouldn't want all the type system to apply to
| prototype code or a nascent program.
| WalterBright wrote:
| I tend to add in the constraints only after the code works.
| Two different parts of my brain.
| renox wrote:
| In the same idea in Eiffel in a.b, b can be either a member or
| a function to allow easy replacement.
|
| On the opposite other languages want to have no hidden function
| call, no hidden pointer dereferencing..
| tormeh wrote:
| Gaming is C++ first and foremost. All other languages suck,
| except when used to script game engines (C# in Unity, etc.).
| There's no practical reason to choose Rust or anything else. I
| don't think Rust is particularly bad or good here. There's
| decades of work to catch up on. I don't see Rust becoming a truly
| great language for games unless it's blessed by Epic or Unity.
| qiine wrote:
| > * I don't see Rust becoming a truly great language for games
| unless it's blessed by Epic or Unity.
|
| Which will never happen
| mrkeen wrote:
| > There's decades of work to catch up on
|
| First you gotta get OpenGL going, with its horrible stateful
| API, give up on it and go to DirectX9. Do a complete rewrite
| when DirectX10 comes out. Get your real-time lighting happening
| with shadow volumes, run into patent issues and get strong-
| armed into putting Creative sound into your game. Cycle between
| GLSL, HLSL, and Cg. End up switching to shadow mapping anyway.
| Drop Linux and Mac support. Start over with Vulkan/Metal.
|
| I don't think Rust needs to relive most of that.
| pcwalton wrote:
| Exactly. Bevy has the advantage of being built using the
| "right way" from the start. This makes an enormous difference
| in the ease of hacking on rendering code.
|
| Ironically, the main thing holding Bevy back is the bickering
| at the W3C. WebGPU is _still_ not widely supported, so we
| have to support WebGL 2 (with reduced functionality in some
| cases), and that adds a lot of complexity.
| TheRoque wrote:
| > Bevy has the advantage of being built using the "right
| way" from the start
|
| I think the article is precisely criticizing this type of
| comment... You make people believe that Bevy is some kind
| of safe bet for the future, that it took inspiration from
| the greatest to build even better foundations for a game
| engine... And it seems common in the Rust community: make
| audacious unverifiable claims to enroll other "believers".
| But it's easy to claim when the tool itself has a fraction
| of the functionalities of Unreal, Unity or Even Godot.
| Heck, last time I used it (about 2 years ago) there wasn't
| even any built-in physics stuff. You have to install
| plugins from every corner, some require old Bevy versions,
| some other require newer versions... It's seriously
| unusable to just "get things done"
| Ygg2 wrote:
| Well, there are two types of game engines from what I've
| seen:
|
| - One where most things are done out of the box, and you
| can mostly GUI visual code to success - these are your
| Unreals, your Unitys and Godots.
|
| - Second, where most things need to be built piecemeal,
| and many things are missing, and need to be built - Bevy
| falls into this category, along with stuff like PyGame
| and what not.
|
| I mean, Bevy is a fine engine for small things, but I
| can't admit I've seen any indie game of more renown
| succeed with it. OTOH, doesn't mean you can't make it,
| but it's definitely more effort.
| TheRoque wrote:
| Well, I don't call the second ones "game engines", I call
| them game libraries, or game frameworks. RayLib also is a
| nice one. But they don't claim to be "engines" (or at
| least, they are mostly described with the aforementioned
| terms)
| popcar2 wrote:
| > Rust gamedev ecosystem lives on hype
|
| I've been saying this for years. I've tried to get into Rust
| multiple times the past few years and one of the things I've
| tried was gamedev with Rust (specifically the library ggez when
| it was still being worked on, and a little bit of Bevy). I
| admittedly never got far, but I gave it a solid shot.
|
| My experience was instantly terrible. Slow compile times and
| iterations, huge package downloads (my project folder was roughly
| 1gb for a simple 2D project), and of course Rust itself was
| difficult to get into with lifetimes and having to wrap and
| unwrap my variables constantly and getting into wrestling matches
| with the borrow checker.
|
| I kept telling myself that everyone loves Rust and the community
| loves to rave about anything Rust-related and maybe I just don't
| get it, but it took some time to realize that no... It's just a
| terrible choice for it. I even tried to make UI with eGUI and was
| still miserable. Rust is a systems programming language but the
| community is trying to convince everyone should be used for
| general purpose stuff.
|
| And my other biggest problem is that they keep painting other
| non-Rust things as being fundamentally flawed for not being Rust.
| "It's not memory safe" is the biggest one thrown around, but when
| was the last time memory safety was actually a big problem in
| games? Unity uses C# which is garbage collected, Godot uses its
| own scripting language which makes it nigh impossible to leak
| memory, Unreal AFAIK has its own tools that makes memory
| management trivial. Rust game development feels like a solution
| looking for a problem to fix.
|
| I am curious about Bevy when it becomes mature and has its own
| editor, but for now I'm just not convinced gamedev with Rust will
| ever take off.
| fleventynine wrote:
| I'm a Rust fan (mostly for embedded firmware with minimal
| deps), but even after 10 years of playing with the language
| it's not clear to me that advanced GUI or gamedev fits well
| with the borrow checker. It requires a significant paradigm
| shift in architecture, and I'm not convinced it's worth making
| that shift, especially if your application can tolerate a
| garbage collector (which many games and most UI apps can).
| iknowstuff wrote:
| https://dioxuslabs.com/blog/release-050
|
| Seems promising, very React-esque with little boilerplate
| vacuity wrote:
| I hope Rust does gain mature options for its GUI ecosystem,
| but the author of the article makes a very good point that
| in other languages, there would be mature options in use
| already. "Seems promising" is too little, too late.
| iknowstuff wrote:
| For sure! I would not write a game in Rust in 2024.
| hi-v-rocknroll wrote:
| Agreed. Multiple languages exist. They can be part of {your,
| your team's} toolbox for different specific purposes. Some
| languages are set by other tools or by team members'
| backgrounds. Popularity also lends itself to greater
| availability of tools and Q&A forums. In the end, it's a
| better decision-making process to select what is most likely
| to be long-term productive for a specific project and team.
| DarkNova6 wrote:
| Just a small addition: Godot also has great C# support. It is a
| real charm to work with.
| vacuity wrote:
| 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
| Quothling wrote:
| We're doing more and more of our back-end work with Rust. The
| main reason is the performance it provides. It's not just great
| for our end-users it's also so much cheaper in the modern world
| where we pay per mileage in the cloud. Part of what we really
| like about Rust, however, is actually exactly the variable
| ownership because it makes it very straight forward to enforce
| and control data-integrity and avoid race conditions. Even for
| programmers who would struggle to do so in C or C++.
|
| I'm not sure whether or not that's even useful in game
| development. I've never done any form of game development
| beyond some Chess game I programmed in my first year of CS 30
| years ago. But I'm actually really curious as to why you've
| struggled with variable ownership, because I'd frankly like to
| improve our on-boarding processes even more for new hires.
|
| > my other biggest problem is that they keep painting other
| non-Rust things as being fundamentally flawed for not being
| Rust
|
| Rust has a cult and it's best not to pay too much attention to
| it. Don't get me wrong, we're seeing great benefit in not just
| using Rust over C/C++ but also replacing more and more of our
| C# and Python services with it, but it's a very immature
| language and like any other programming language it's still
| just a tool. If it works for you, use it, if not... Well, use
| something that does.
| hi-v-rocknroll wrote:
| Rust ain't Go but anything Go has can be used as an argument
| that Rust should try to do better in certain areas. ;)
|
| Perhaps learn another language like Haskell, Swift, or Kotlin
| before Rust.
|
| Get cargo-bloat, cargo-cache, and cargo-outdated.
|
| Setup a memcache server and use sccache to accelerate Rust, C,
| and C++ compilations. It's not 100% but it's pretty awesome for
| things compiled at a stable build location.
|
| Just like any platform, avoid dependencies wherever possible
| and use minimal crate features. Some Rust crates have an npm-
| like problem of dragging in zillions of dependencies.
| pcwalton wrote:
| > And my other biggest problem is that they keep painting other
| non-Rust things as being fundamentally flawed for not being
| Rust. "It's not memory safe" is the biggest one thrown around,
| but when was the last time memory safety was actually a big
| problem in games? Unity uses C# which is garbage collected,
| Godot uses its own scripting language which makes it nigh
| impossible to leak memory, Unreal AFAIK has its own tools that
| makes memory management trivial. Rust game development feels
| like a solution looking for a problem to fix.
|
| Memory safety may or may not be important in games, but the
| ability of engines like Bevy to analyze system dependencies and
| automatically scale to multiple CPUs is a big deal. Job queuing
| systems have been popular in gamedev for a very long time, and
| Rust's insistence on explicit declaration of mutability is a
| big part of the reason that "just works" in Bevy.
| jvanderbot wrote:
| This might be controversial, but "Safety" and "Speed", in the
| same ecosystem, are not free. The cost is heavy syntax and
| heavy cognitive climbs. Why Rust was ever sold as a language
| for the masses is beyond me. A safe, fast, hard language is
| something you use for operating systems, aircraft, etc.
|
| I adore Rust because it does all the things I remember being
| told to do in C, but without me remembering to do them: Error
| codes from all functions, Ownership models, etc. But those are
| not good reasons for me to use it for anything I wouldn't use C
| for.
| colund wrote:
| I find that Jonathan Blow ranting about Rust game development
| here https://www.youtube.com/watch?v=4t1K66dMhWk. He adds
| interesting perspectives to the discussio, how the language makes
| the Rust game developer resort to arrays and their so called Rust
| point of views.
| littlestymaar wrote:
| Well the problem with Jonathan's argument here is that he's
| spent the past decade mostly ranting about Rust and working to
| make a perfect game programming language, instead of making
| games.
|
| So it turn out that even if he's opinion on Rust is correct, he
| would still have been much more productive using it than trying
| to build his own language for a decade...
|
| (But he already shipped his masterpiece and he's a millionaire
| so he gets to chose his full time hobby as he wishes)
| Xeamek wrote:
| He is actively developing his new game in parallel to
| creating the language.
|
| Not to mention smaller projects like 'Braid- anniversary
| edition'.
| astrange wrote:
| Isn't the traditional advice that if you try to write both
| a game engine and a game that you'll get neither?
| Xeamek wrote:
| I mean, it's not like there are no games in existence
| that shipped with a custom engine.
|
| Even in hindsight it's hard to judge whether building
| your own engine was good or bad decision, and we are
| nowhere near "the hindsight" level of knowledge.
| BaculumMeumEst wrote:
| Then it's a good thing not everyone listens to
| traditional advice.
| ekms wrote:
| I mean, he does like a good rant lol. But this seems like a
| bad take. The witness came out ~8 years ago, and Braid came
| out ~8 years before that. Braid Anniversary is launching next
| week, he's actively developing his language and next game
| (occasionally streams). "he's just resting on his laurels
| now" I think is clearly wrong
| BaculumMeumEst wrote:
| This is a pretty weird perspective IMO, it's like you're
| trying really hard to take an uncharitable view of things.
| Writing games in C++ is horrible, that's literally why he
| wrote the language.
| klaussilveira wrote:
| &str vs String. Oh boy.
| brabel wrote:
| https://raw.githubusercontent.com/lesterli/blockchain/master...
| whytevuhuni wrote:
| This is missing a few useful ones, like Box<str>, Arc<str>,
| Cow<'a, str>, SmallVec<u8>, transmuted newtype references
| like &UserId, and of course the string type you implemented
| yourself because the previous ones were not good enough.
| andrepd wrote:
| Yeah, if std::string vs std::string_view is "a major hurdle"...
| I don't know what so say
| ziddoap wrote:
| Where did you see "a major hurdle" written?
| Ygg2 wrote:
| > Orphan rule should be optional
|
| That has got to be the most "I didn't think this through" take
| ever.
|
| While it's a known pain in the ass. Not having it is a bigger
| pain.
|
| The moment you allow this, you have to find a way to pick between
| several implementation - and they don't always have sane names.
|
| Orphan rules prevent this from happening.
| JoshTriplett wrote:
| Someone who has experienced _real problems_ as a result of a
| specific mechanism is not required to solve every single
| problem with alternatives to that mechanism before saying
| "this mechanism has caused me real problems and it'd be nice if
| there were a better alternative that didn't cause those
| problems".
|
| > The moment you allow this, you have to find a way to pick
| between several implementation - and they don't always have
| sane names.
|
| There are other possible solutions that don't involve that.
|
| For instance, many applications would be quite happy with
| "There can be only one implementation", giving a compiler error
| if there's more than one.
|
| A slightly more sophisticated rule would be "Identical
| implementations are allowed and treated as a single
| implementation". This would be really convenient in combination
| with some kind of "standalone deriving" mechanism, which would
| generate identical implementations wherever it was used.
| Ygg2 wrote:
| Disclaimer: I'm aware you guys are working on relaxing orphan
| rules, and I wish you the best of luck. But as an outsider,
| orphan rule doesn't seem to be going anywhere soon.
|
| And if the original poster had said that I would be ok.
| Instead what they said is:
|
| > It's a great example of something I'd call "muh safety",
| desire for perfection and complete avoidance of all problems
| at all costs, even if it means significantly worse developer
| ergonomics.
|
| This implies the writer didn't assume what happens if you
| "turn-off" orphan rules. I.e. you don't trade perfection for
| developer ergonomics, you trade one set of developer (ability
| to write any trait for any type) ergonomics for another
| (having to battle two incompatible trait implementations from
| crates you don't own).
|
| Either you have to manually specify how nearly every
| implementation is pulled (horrible developer ergonomics) or,
| even worse, you go into monkey patching territory.
|
| > For instance, many applications would be quite happy with
| "There can be only one implementation", giving a compiler
| error if there's more than one.
|
| Ok. But you still need a resolution mechanism to fix the
| error. Which implies manually solving ambiguity. And how do
| you solve it for blanket implementations?
| JoshTriplett wrote:
| > But you still need a resolution mechanism to fix the
| error
|
| At least initially, the resolution mechanism could be
| "don't include more than one implementation".
| Ygg2 wrote:
| Assuming you have no control over trait implementation,
| how would that work?
|
| To reuse the canonic example: // crate
| "types" pub struct Thing; //
| crate "traits" pub trait Action {}
| // crate "alpha_v0" impl traits::Action for
| types::Thing {} // crate "beta_v1"
| impl traits::Action for types::Thing {} // Doesn't exist
| for beta_v0
|
| Say by transitive dependencies, alpha_v0 and beta_v0 are
| imported, and due to vulnerability, you upgrade beta_v0
| -> beta_v1 (let's assume that trait is essential for the
| vulnerability resolution).
|
| Now what? You either have to skip future updates, or keep
| the vulnerable beta_v0 crate.
| desiderantes wrote:
| That logo is huge on mobile so I can't read the first few bullet
| points.
| darthdeus wrote:
| Author here, sorry about that, I just deployed a fix, should be
| readable now. If it's not, here's the first few points
|
| - Once you get good at Rust all of these problems will go away
| - Rust being great at big refactorings solves a largely self-
| inflicted issues with the borrow checker - Indirection only
| solves some problems, and always at the cost of dev ergonomics
| - ECS solves the wrong kind problem - Generalized systems don't
| lead to fun gameplay - Making a fun & interesting games is
| about rapid prototyping and iteration, Rust's values are
| everything but that - Procedural macros are not even "we have
| reflection at home" - ...
|
| the list corresponds to the titles of sections in the article.
| fidotron wrote:
| Starting by saying I fundamentally agree wrt iteration speed.
| This is ultimately why [C/C++]/Lua was such a thing for a while,
| and it seems quite plausible that you could benefit from a core
| engine in rust bound to a scripting language.
|
| But ultimately I sense the subtext here is much the same as with
| other Rust problems: the object oriented baby has been thrown out
| with the bathwater, often in the name of premature optimisation,
| but also with a sense of misplaced religious purity regarding the
| evils of state and the merits of functional programming. There
| never was any OOP law that your inheritance hierarchy had to be
| insane, or that you had to create classes for absolutely every
| last thing. Now we have people hitting the opposite extreme where
| everything has to go through the same function switched on a
| pattern matched enum. One of the core problems with Rust is it
| lacks the mechanisms to allow moving adequately out of this
| tarpit.
|
| I still think Rust might have a place at the lowest level core
| where it is all about shuffling arrays of things through compute
| units, but for the higher level pieces it is clearly the wrong
| thing to be using.
| fire_lake wrote:
| Isn't the trait system exactly the way out of this tar pit?
| fidotron wrote:
| Obviously that is the intention, but the absence of libraries
| that manage to replicate what people manage fairly easily in
| other paradigms does show it's not sufficient.
|
| golang is similar in this regard - it has interfaces and you
| can compose type structs, but the results become an unwieldy
| mess unless the developers are staggeringly disciplined, in
| which case they'll have a better time in something else
| anyway.
| kibwen wrote:
| _> but also with a sense of misplaced religious purity
| regarding the evils of state_
|
| To clarify, Rust isn't against state at all. Rust bends over
| backwards to make mutation possible, when it would have been
| far easier (and slower, and less usable) to have a fully-
| immutable language. What Rust is against is global mutable
| state, and an aversion to global mutable state isn't a
| religious position, it's a pragmatic position, because global
| mutable state makes concurrency (and reasoning about your code
| in general) completely intractable.
| hughesjj wrote:
| 1000%, and this is something gamedevs (and, for quite some
| time, webdevs) are guilty of in the name of speed for quite
| some time. In both web and game dev, it's come back to bite
| when it's time to debug.
|
| Concurrency is hard, and anything with a ton of user
| interaction or communication across multiple parties induces
| concurrency (never block the main thread and all).
| tormeh wrote:
| This makes a lot of sense. Wonder if Bevy will add support for
| GDScript or C# or something. I think it's generally opposed in
| the interest of ensuring the Rust devex is as good as possible,
| but it's coming eventually, I think.
| CharlieDigital wrote:
| YMMV, but I find C# and TypeScript to have a "Goldilocks" mix
| of OOP and FP that you can take advantage of the strengths of
| each where it makes sense.
| d13 wrote:
| You're absolutely right, they are incredibly pragmatic.
| MerrimanInd wrote:
| I've been playing around with an idea about OOP for awhile, not
| sure if it'll ring true or not but I'll run it up the flagpole
| for feedback.
|
| I think FP is a great way to program actions and agency but OOP
| is a great way to model the world. I like Rust's trait system
| because the polymorphism is based on what you want an object to
| _do_ not what it _is_. But when you 're creating models of the
| world it's usually really convenient and even accurate to use
| nested inheritance models. Maybe the original system for this
| is the flora/fauna taxonomy but it applies to a lot of things;
| like GUI elements or game models.
|
| If this is correct, it might explain why the discourse is so
| polarized. Whether OOP is a blessing or a curse probably
| depends on whether you're using a programming language as a
| modelling language or as a logic/execution language.
| fidotron wrote:
| It's not hard/fast but I would tend to agree with an
| approximation of this.
|
| Back when I worked properly on big games the UI libs would
| often be trees of widgets with injectable functions for
| modifying the rendering, which is actually one of the points
| in this blog the writer would like. (The UI lib of classic
| Sims was exactly like that). These days the stuff I've done,
| although entirely in JS, at https://luduxia.com/ follows that
| pattern for the 3D components at least. The world is defined
| in an almost classic scene graph and then behaviour is added
| by attaching functions to pieces, which can be composed
| functionally.
|
| Much of the anti-OOP noise is the result of people that have
| suffered from others creating hierarchies of the world too
| literally. Quite why it proves so difficult for developers to
| slow down and think about the right course of action is
| beyond me. They're also staggeringly resistant to changing
| afterwards.
| tomtheelder wrote:
| Absolutely agree. I think people saw that a lot of games are
| written in C++ and got confused into thinking that the right
| thing to do is to build your entire game in a systems language.
| The fact that we have games written entirely in C++ is mostly
| just due to the enormous amount of inertia that game engines
| have, and the fact that many of them have origins that go back
| decades to a time when the programming language landscape and
| broader development ecosystem were completely different.
|
| And now, the most popular generally available game engines
| right now are: Unity - C++ in the engine, C# for game code
| Godot - C++ in the engine code, GDScript or C# for game code
| Unreal - C++ in the engine code, somewhat mangled C++ for game
| code BUT with also one of the most capable and widely used
| visual programming setups I have ever seen
|
| I wouldn't be surprised if the "next great game engine" had a
| Rust core and some other language- I mean why not C# at this
| point?- for game code.
| blowski wrote:
| Oh we're at that point of the hype cycle are we?
| mjr00 wrote:
| In my experience, fundamentally when you're starting a software
| project, you need to make a strong up-front decision between two
| things:
|
| 1. I am using technology in order to build this thing.
|
| 2. I am building this thing in order to use this technology.
|
| Developers often fall in the (2) camp but don't admit it. There's
| an allure to using the new, sexy tech that will solve all their
| problems, whether that's Rust, Kubernetes, LLMs, etc.
|
| If you're in the (1) camp, you should stick with what you know;
| and if you know that what you know isn't enough to build the
| thing, you should use whatever is most common and
| straightforward, not something off the beaten path.
|
| Games seem to be the biggest trap, because solo devs often end up
| building a game _engine_ when they set out to build a game. If
| you really want to build a game, just use Unity /Unreal/Godot, I
| promise it'll go better for you.
| gpm wrote:
| I know rust, I don't know game development (I've dabbled
| slightly). If I choose to build a game I either need to make it
| work in rust* or I need to learn a new language (Unity -> C#,
| Unreal -> blueprints, Godot -> gdscript).
|
| So your advice to "just use Unity/Unreal/Godot" is the opposite
| of your advice "you should stick with what you know" in my
| case. I suspect the former is good advice, and the latter is
| therefore wrong.
|
| * For the sake of argument, we can pretend I only know rust. In
| reality I know a fair number of other languages as well, but
| the list doesn't happen to include C# or "random game engine
| specific scripting language", which seems to be the options if
| we're going with an established engine for big 3d games.
| mjr00 wrote:
| This falls in the "you know that what you know isn't enough
| to build the thing" bucket, presumably. Even if you're a Rust
| expert, do you know how to manage game asset content
| pipelines? Sound and music? Have you done graphics
| programming at all in Rust? How are you going to store levels
| in your game, and how are you going to make them? How are you
| doing multiplayer? etc...
|
| You're going to have to learn something new, and it's a bit
| of a judgment call, but picking up C# or gdscript given that
| you already know programming should be straightforward
| compared to re-implementing all of those things yourself in
| Rust.
|
| Unless, of course, you _do_ know a bunch of great Rust game
| development libraries that solve all those problems--in which
| case yeah, building a game in Rust might be the best choice.
| It 's not impossible!
| gpm wrote:
| > but picking up C# or gdscript given that you already know
| programming should be straightforward compared to re-
| implementing all of those things yourself in Rust.
|
| Right, this is practically my point. I suspect that the
| tools available from those languages mean that learning one
| of them would more than pay for itself in the course of
| developing a (single) game. Many many times over really.
|
| Like, yes, I've dealt with both sound, basic graphics
| programming (though I'd need to learn a bit more to make a
| modern looking 3d game), networking, ... in rust. If I had
| to program my sound system and graphics engine from scratch
| myself I'd do it in rust (and I believe I'd be more
| productive in rust than I'd be in <other language> while
| doing so). But I don't have to do everything from scratch,
| and the best not-from-scratch versions aren't in rust, and
| the cost of switching _to something I don 't know_ just
| isn't that high.
|
| Also OP is definitely right that rust has some anti-
| features that would be pain points for game development.
| fooker wrote:
| Perhaps the more appropriate advice is : Use the right tool
| for the job.
|
| Use C++ for writing a high performance library or a database
| engine.
|
| Use Go or Java for writing a server.
|
| Use C for writing a kernel module.
|
| Use shell scripts for automation.
|
| Use python for trying out ML ideas or heavier duty scripts.
|
| Use Rust for ... I'm not quite sure what it's the right tool
| for yet. I suspect it's trying to become the right tool for
| all of the above and not succeeding much in practice.
| Wazako wrote:
| Use Rust if crashes or memory bugs are not an option. For
| everything wasm, Rust is much more pleasant with good
| libraries than the competition.
| fooker wrote:
| Wasm seems more convincing to me than the magical 'no
| crashes or bugs' promise.
|
| Here's my wasm use case: tell me how I can use Rust.
|
| I have a command line tool written in C that ..say..
| takes strings and outputs strings.
|
| How would I go about making a usable REPL out of this in
| Rust and wasm without rewriting the tool?
| tkubacki wrote:
| It's C++ replacement just not yet there for game dev (maybe
| never for game dev)
| fooker wrote:
| A C++ replacement must have really strong and seamless
| C++ interop to be considered by anyone currently using
| C++. You can't have a C++ replacement by ignoring
| existing C++ users and libraries, no matter how good the
| the language is.
|
| Swift from Apple and Carbon from Google are stronger
| contenders at this point.
| danbolt wrote:
| When all you have is a hammer, everything looks like a nail.
| When all you have is programming expertise, all your game
| production obstacles look like programming problems.
|
| I think everyone in games has met an "engine person" who spends
| a lot of time iterating on tech, but never quite getting to the
| creative expression that got them in the game. I think part of
| it comes a bit from mythologizing breakthrough games like
| _DOOM_ , where cool technology made something completely fresh.
| We begin to think that emulating id Software is how you make
| compelling art, ignoring the latter half of Kushner's novel.
| djmips wrote:
| Well said, I am weary of all the 'game' programmers that just
| fetishize working on the tech and particularly rendering.
| georgeecollins wrote:
| People like to program on tasks that aren't given to them,
| to practice their craft in a less restricted form than
| professional life usually allows. So they make things for
| themselves and its natural that those things are what they
| are familiar with and enjoy. So you often meet the
| programmer, almost never from the game industry, who wants
| to make his or her own game engine. It's about as likely to
| be a productive endeavor as making your own spreadsheet
| program.
| eddd-ddde wrote:
| This is what I like to call the artist vs engineer dilemma.
|
| 1. An engineer solves problems, learning and using tools. 2.
| And artist learns and uses tools, for the sake of it.
|
| Neither is wrong, and some times they benefit each other. I
| believe much of academia and research is heavy on the artist
| side. You just have to be clear on which one you are at any
| given point.
|
| I'm not gonna use assembly for my $JOB where we need some basic
| web backend. That's not gonna stop me from trying on my free
| time tho.
| drdaeman wrote:
| > you need to make a strong up-front decision
|
| Can one always realistically do so? I suspect the underlying
| unspoken assumption is that one must be ideally informed about
| all the possible potential pitfalls and gotchas they may face
| when using any given technology. Aka having a very good
| (ideally, perfect) knowledge of the technology and its
| surrounding ecosystem.
|
| It wasn't just once or twice when I've picked some very
| promising library or tool only to learn something isn't exactly
| as I hoped (or as it was advertised - docs can lie, too) after
| I've already spent some non-negligible time implementing
| something with it. Save for some teenage keyboard mashing some
| decades ago I'm not a game developer, but I suspect this is
| universal experience no matter the niche.
|
| > Developers often fall in the (2) camp but don't admit it.
|
| There's also a mixed approach, where people admit "I want to
| build this thing and use this technology, and I suspect they're
| a potential good match so I'm gonna try both at the same time".
| Any even slightly creative person must have an urge to learn
| and explore new things, even if they aren't exactly _necessary_
| for a task at hand. Checking on the promise, if it holds true -
| sometimes it does and you get a new tech you love, quite
| frequently it doesn 't and you have a bad day.
| bluGill wrote:
| > Can one always realistically do so? I suspect the
| underlying unspoken assumption is that one must be ideally
| informed about all the possible potential pitfalls and
| gotchas they may face when using any given technology. Aka
| having a very good (ideally, perfect) knowledge of the
| technology and its surrounding ecosystem.
|
| Exactly. You need to make some choices up front about program
| design despite rarely having enough information to make the
| correct decision, nor enough time to evaluate alternatives in
| detail. If we had known 15 years ago what we know now our
| then green field project wouldn't have been done this way -
| but we are still discovering things that the decisions we
| made 15 years ago are making hard to do today. That is on top
| of all the existing things we know are wrong that we often
| cannot feasibly correct.
|
| You have to make choices. Some of those choices will be
| impossible to undo without starting over after a while. Some
| of the negatives will take a decade to figure out. There is
| no way anyone sane will give you enough time to figure out
| what those negatives are for each choice - even if the did
| you will be dead before you finish.
| mirekrusin wrote:
| Advice should be - you should do what you like and try to align
| it with your client (employer) - otherwise you'll burnout
| rather quickly.
| hot_gril wrote:
| It's not easy to find an employer that'll agree with your
| preferences. I chose to find fun and value in the way I
| collaborate and reach end goals, not the tools. If the
| tooling in my dept sucks, I just treat it like a challenge
| and deal with it.
| mirekrusin wrote:
| Healthy.
| usrusr wrote:
| How about "I'm building this thing and I want it to enjoy the
| unique combination of performance and memory safety offered by
| this technology"?
|
| It's certainly close to (1), but also a perfectly rational way
| to be a The Rust Way fundamentalist avoiding refcounting and
| unsafe who appears suspiciously (2).
|
| The "rewrite in Rust" meme surely does not come from thin air
| and there is certainly some skill honing and challenge seeking
| involved. But perhaps a rewrite ever couple of decades isn't
| all that bad? And if it isn't, could there be a better time for
| it than "in Rust"?
| bluGill wrote:
| I'm in the 1 camp. After several decades of C++ I know it very
| well. Well enough to find some of the things that those Rust
| and Ada people are saying about their respective languages
| intriguing. I'm at the point where I need to spend some time
| with each to see how/if they work with my problems in the real
| world. Because eventually you have to admit that while you can
| drive a screw with a hammer there are other ways and maybe it
| is time to learn how to use a screwdriver.
| nielsbot wrote:
| Interesting to me to have [iteration speed] <-->
| [maintainability] spelled out as opposite ends of a spectrum...
| and that sometimes [iteration speed] is the right thing to
| optimize for.
| masklinn wrote:
| It's not news though? Favoring iteration speed at the cost of
| future maintainability is a common argument for dynamically
| typed languages.
| nielsbot wrote:
| Certainly--just having it spelled out like this was new to
| me?
| WhereIsTheTruth wrote:
| OP should give D a try, my game fully recompile in less than
| 1sec, and i can consume most of the C gamedev ecosystem without
| effort and seamlessly
| LarsDu88 wrote:
| I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#.
|
| It's honestly somewhat baffling to me that folks will choose Rust
| for gamedev right now. The state of the open sourced tools are
| just not there yet, especially when compared to Godot, and at the
| same time these games are running on PC hardware which tends to
| get faster every year.
|
| Also for ECS... one thing I tended to realize is that when
| developing a game, pigeonholing everything into an ECS can
| seriously tend to get in the way. A lot of (efficiently written)
| game code is best handled in an infrequent event-driven way.
|
| An ECS backed game engine like Bevy can make big mobs more
| efficient, but few games will actually leverage this effectively
| for fun gameplay and at the same time modern PCs are fast as
| hell.
|
| I think about Starcraft from 1998, created when virtually all PCs
| only had one core, and its 200 unit per faction cap. Blizzard
| hasn't increased this cap because it doesn't necessarily make the
| game more fun. Now should a gamedev today, 26 years later, making
| a 2d isometric game for the PC be worried about performant
| multithreading????
| TillE wrote:
| CPUs are way way faster, but RAM latency has barely improved in
| the past couple decades. That's why cache-optimized systems
| like ECS can still be a dramatic improvement when you're
| simulating a _lot_ of stuff. Like, thousands of active objects.
| pixelesque wrote:
| They _can_ be improvements, but you can do Data-Oriented
| Programming without ECS systems, i.e. Structure Of Arrays,
| which is what we often using in Rendering /Simulation for VFX
| for SIMD/GPU compute...
|
| But similarly, ECSs _can_ be slower, if they don 't have some
| optimisations, i.e. spatial data structure lookups: just
| using a generic ECS "database" system without any first-class
| spatial knowledge / acceleration structure lookup ability, is
| likely going to be slower.
| pixelesque wrote:
| Likewise - I've been learning Rust for four years now
| (significant C/C++/Python/Lua experience), and have written
| some reasonably complex apps in it, but I really just didn't
| get the Bevy / ECS "hype"...
|
| I've tried to write several different types of games using it
| (with Bevy) in the past three years, and it just feels like
| shoe-horning something in.
|
| But the biggest complaint I have with Bevy is that with all the
| refactoring that's been needed with the Bevy version upgrades:
| getting the code to compile again after the version upgrades
| has normally been fairly easy - but it then often didn't work
| correctly, and I'd have to spend time debugging the ECS system
| to work out what was wrong.
|
| i.e. the "if it compiles, it'll almost certainly work" bonus of
| generic Rust code totally seems to fall down within Bevy.
|
| I obviously understand that it's an in-development framework,
| in its early days, so some of that's on me for choosing it, but
| still, it's been a very painful experience, and I feel I've
| wasted a fairly significant amount of time over the past few
| years attempting it.
| Nuzzerino wrote:
| > I think about Starcraft from 1998, created when virtually all
| PCs only had one core, and its 200 unit per faction cap.
| Blizzard hasn't increased this cap because it doesn't
| necessarily make the game more fun.
|
| Ah... Starcraft. It's 200 supply per player (hero units take 0
| supply, zerglings are 0.5, and the supply cost goes up to 8 for
| battlecruisers for example). The limit is enforced when
| building a unit from a building. Map triggers can grant units
| and you can exceed the 200 supply limit.
|
| The technical unit limit for the map was 1700, and was later in
| fact extended to 3400 by Blizzard. The EUD emulator (part of
| the official SC Remastered) allows for online custom games to
| be played without any third party tools on the player's part.
| Certain limits like sprites can be bypassed with this tool (for
| map makers)
| https://github.com/phu54321/euddraft/blob/master/plugins/unl...
|
| EUD started out as a buffer overflow exploit which allowed
| custom maps to patch the game client's code. It was later fixed
| by blizzard but re-implemented as an emulator (with some
| restrictions).
|
| These are definitely things that enhance gameplay for custom
| scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a
| battlecruiser shooting nukes)
| Aerroon wrote:
| > _but few games will actually leverage this effectively for
| fun gameplay_
|
| In my opinion this is a result of big mobs having poor
| performance. When players get to choose they seem to like
| having more mobs thrown at them.
|
| This can also be limiting for interactable objects.
| mrkeen wrote:
| > As far as a game is concerned, there is only one audio system,
| one input system, one physics world, one deltaTime, one renderer,
| one asset loader.
|
| I thought this way when I was doing Java dev around 10 years ago.
| I thought it excused the singleton pattern. I was wrong!
|
| You should always be able to construct an object by explicitly
| passing dependencies to it. Especially for testing.
|
| It really is no fun if your renderer starts talking to your asset
| loader and timer directly.
| DarkNova6 wrote:
| All praise our almighty lord that is dependency injection
| Xeamek wrote:
| No. You don't need ability to DI every single functionality.
| And you can still do DI with global state, just with less
| granularity.
| astrange wrote:
| People should get more into integration tests. If you start out
| thinking you need to separate everything for unit testability,
| you instantly get architecture astronaut-ism, where your
| architecture is entirely based on fake testability instead of
| the thing it's actually meant to do in production.
| rendaw wrote:
| I agree with a lot here, but I think the author is overplaying
| "get things done fast" or underplaying "stable, performant code".
| I like indie games, but I've played enough games that crashed if
| I look at them wrong or chug despite being low poly early 2000s
| things that I now hesitate to buy indie games. Some of the
| examples seemed like maybe rust was preventing a weird unexpected
| feedback or clobbering iteration state or whatever.
|
| I don't think the author disagrees here and is mostly talking
| about awful runtime alternatives (refcell, etc) but I just wanted
| to say it for balance.
| fbn79 wrote:
| Honestly I have not read all the article. What language they are
| going to use instead of Rust?
| karolist wrote:
| C# with Unity.
| imiric wrote:
| This is a sobering read. Thank you for sharing.
|
| This sums it up for me:
|
| > Rust as both language and community is so preoccupied with
| avoiding problems at all cost that it completely loses sight of
| what matters, delivering an experience that is so good that
| whatever problems are there aren't really important. This doesn't
| mean "ship crap games", it means focusing on the game being a
| good game, not on the code being good code.
|
| I think this can be easily extrapolated to projects outside of
| game development as well.
|
| User experience is ultimately all that matters. If you're in
| prototyping stages of whatever it is you're building, and games
| spend a lot of time in this phase, then your focus should always
| be on testing what the user experience will be like, rather than
| absolute code correctness, maintainability, and everything else
| that makes a long-term project successful.
|
| The fact Rust seemingly can't deliver this rapid prototyping
| workflow should be a large factor when deciding which language to
| use.
|
| I've been using Go as my main language for the better part of a
| decade now, and I think it strikes the perfect balance of code
| quality and rapid prototyping. It's far from the side of absolute
| freedom of a language like Python, which becomes a nightmare to
| work with after the prototyping phase is over (though this might
| have improved in the past few years), but it's also far from
| languages like Rust, and allows me to be very productive, very
| quickly, while also being easy to pick up for newcomers. I
| probably wouldn't pick it for GUI or game development either,
| though, but for things like CLI, network and web tooling, it's
| perfect.
| timeon wrote:
| > User experience is ultimately all that matters.
|
| It should be but current state of web will show you that it is
| often not.
| attheicearcade wrote:
| Absolutely agree with the comments on ECS and Bevy in particular.
| I tried getting to grips with it for some time, doing things the
| Bevy way, and it just felt like a big step backwards because it's
| not suitable for most things. The renderer was really slow at the
| time too, although I imagine that has improved. Switched to plain
| rust + vulkan (via ash) + dear imgui and haven't looked back.
| vacuity wrote:
| Some of those issues with Bevy might have more to do with its
| immaturity. It still needs at least a few years to be a solid
| choice for all sorts of games, in my opinion. I do think the
| hype should be toned down; people shouldn't feel pressured to
| worship Bevy or Rust or whatever is the hot new thing.
| npalli wrote:
| By the time the Rust developer is finished with their
| refactoring, the C++/C#/Java/JavaScript developer has implemented
| many different gameplay features, played the game a bunch and
| tried them all out, and has a better understanding of which
| direction should their game be taking.
|
| Man, slower than C++, that's pretty damning.
| martin-t wrote:
| As someone in a similar position (also ~3 years doing gamedev in
| Rust but only free time + open source), I feel very similarly.
|
| There's low hanging fruit i've been complaining about for years
| where Rust is protecting us from ourselves - orphan rules, global
| state, ... Look, we're adults, we can make decisions with
| tredeoffs.
|
| Compile times are a tougher one, I understand that Rust does
| analysis that is more complex than many langs and i feel
| ungrateful to people who spend their free time improving Rust.
| But also i don't think the complexity justifies all of it. Make
| dynamic linking easier, reduce how much needs to be recompiled,
| compile generics to dynamic dispatch in debug builds, etc. -
| there's gotta be a ton of stuff that can investigated.
|
| ECS just plain sucks. People use it because what they want at
| first is some way to have relationships between entities.
| References/pointers are the obvious solution in most langs but in
| rust, they're obviously out. The second option is Vec and indices
| but that falls apart as soon as you start removing entities. The
| next step up the ladder of complexity should be generational
| arenas but for some reason people immediately reach for the big
| guns - ECS. And it infests their game with two things that make
| gamedev a slog - dynamic typing and boilerplate.
|
| Boilerplate is obvious to anyone who has done gamedev the
| "obvious" way before. What could be projectile.shooter.score += 1
| is multiple lines which (depending on your particular choice of
| ECS) usually involve generics. You shift your focus from tweaking
| your game logic and tuning the experience to typing out
| boiletplate.
|
| Dynamic typing means entities are no longer structs with fields
| where you can understand how they relate to each other at a
| glance but instead any component can be anywhere, entities are no
| longer real, refactoring always causes silent bugs.
|
| However, by far the biggest issue is the community's handling of
| criticism.
|
| There are practically no experienced gamedevs coming to Rust from
| other langs so there's nobody to give Rustaceans a reality check.
| Rust gamedevs are almost always writing their first game (or,
| yes, engine). And there's nothing wrong with that, i was writing
| my first game at one point too. But their attitude is that they
| chose Rust because they heard it's the best and they got invested
| in the language because it's hard(er) to learn and now with all
| this investment if they hear rust or their particular favorite
| engine might not be that great, it feels like wasted effort so
| they get emotional and defensive.
|
| I've personally chatted with over half a dozen other gamedevs who
| came to rust with years of experience under their belt and a
| common pattern is that they avoid the rust (gamedev) community
| because they're beat down by the negativity heaped upon them
| every time they try to discuss the negatives. It doesn't matter
| they take every effort to offer constructive criticism, it
| becomes a social instead of technical topic.
|
| I came to Rust because i care about code correctness and, well,
| quality (of tooling, docs, testing). And Rust delivers there on a
| lot of that. But i also wanted to write games of a larger scale
| than can be done in one person. My hope was that there'd be other
| people with the same values who wanna build cool games together.
| Instead there's a low single digit number of serious open source
| projects and a bunch of small one man games and a a whole lot of
| loud people who seem to think gamedev is about hyping up an
| engine like it's a sports team.
|
| Myself, I apparently chose the wrong engines for my games in both
| cases. Not because they're bad technically. In fact, having 5
| years of gamedev experience before Rust, i think my choices are
| better from a technical perspective but there's just not the
| critical mass to build a serious open source game around them.
| Animats wrote:
| That's a good article. He's right about many things.
|
| I've been writing a metaverse client in Rust for several years
| now. Works with Second Life and Open Simulator servers. Here's
| some video.[1] It's about 45,000 lines of safe Rust.
|
| Notes:
|
| * There are very few people doing serious 3D game work in Rust.
| There's Veloren, and my stuff, and maybe a few others. No big,
| popular titles. I'd expected some AAA title to be written in Rust
| by now. That hasn't happened, and it's probably not going to
| happen, for the reasons the author gives.
|
| * He's right about the pain of refactoring and the difficulties
| of interconnecting different parts of the program. It's quite
| common for some change to require extensive plumbing work. If the
| client that talks to the servers needs to talk to the 2D GUI, it
| has to queue an event.
|
| * The rendering situation is almost adequate, but the stack isn't
| finished and reliable yet. The 2D GUI systems are weak and
| require too much code per dialog box.
|
| * I tend to agree about the "async contamination" problem. The
| "async" system is optimized for someone who needs to run a very
| large web server, with a huge number of clients sending in
| requests. I've been pushing back against it creeping into areas
| that don't really need it.
|
| * I have less trouble with compile times than he does, because
| the metaverse client has no built-in "gameplay". A metaverse
| client is more like a 3D web browser than a game. All the objects
| and their behaviors come from the server. I can edit my part of
| the world from inside the live world. If the color or behavior or
| model of something needs to be changed, that's not something that
| requires a client recompile.
|
| The people using C# and Unity on the same problem are making much
| faster progress.
|
| [1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ
| int0x29 wrote:
| > * There are very few people doing serious 3D game work in
| Rust. There's Veloren, and my stuff, and maybe a few others. No
| big, popular titles. I'd expected some AAA title to be written
| in Rust by now. That hasn't happened, and it's probably not
| going to happen, for the reasons the author gives.
|
| At one point the studio behind the Finals was writing game
| server code in Rust with an Unreal engine client. Not sure if
| that's true still
| droopyEyelids wrote:
| Backend 3d code?
| ReleaseCandidat wrote:
| Server side rendering for games.
| internetter wrote:
| That's a thing?
| chris37879 wrote:
| Absolutely! Any sort of multiplayer game needs a source
| of authority if you want to prevent cheats like a hacked
| client lying about its position, and a really good way to
| do that is load the geometry of your level and run
| physics checks server side at a lower frequency than once
| per frame. Godot and Unity both support headless builds
| for exactly this reason, it's basically the whole game
| engine, minus the renderer, audio, and UI systems,
| usually.
| dj_mc_merlin wrote:
| That is not server side rendering. Per your own comment:
|
| > minus the renderer
|
| (Otherwise you are completely correct.)
|
| Closest I can think of is server side ragdolls that are
| rendered the same on all screens and similar stuff.
| xboxnolifes wrote:
| I'm not familiar with the domain, but wouldn't 3D collision
| checking be considered backend 3D code? Even if it's not
| rendered, it still needs to be calculated.
| TheRoque wrote:
| The studio you're talking about is Embark studios, and is
| openly pretty big on Rust [1] I think it was rumored that
| their next project will use a Rust game engine, but I am not
| sure how it's going now.
|
| [1] https://github.com/EmbarkStudios/rust-ecosystem
| jsheard wrote:
| Their creative sandbox project is full Rust from client to
| server I believe. I haven't kept up with it after trying
| the closed alpha a while ago but it looks like it's still
| going, and has a name now: https://wim.live
|
| It's still only listed as coming to PC, Mac, Linux and
| Android so I guess they haven't broken through the barrier
| of shipping Rust on consoles.
| kibwen wrote:
| _> I 'd expected some AAA title to be written in Rust by now._
|
| I'm disinclined to believe that any AAA game will be written in
| Rust (one is free to insert "because Rust's gamedev ecosystem
| is immature" or "because AAA game development is increasingly
| conservative and risk-averse" at their discretion), yet I'm
| curious what led you to believe this. C++ became available in
| 1985, and didn't become popular for gamedev until the turn of
| the millenium, in the wake of Quake 3 (buoyed by the new
| features of C++98).
| hot_gril wrote:
| Exactly, it's all about the ecosystem and very little about
| the language features
| meheleventyone wrote:
| Disagree the adoption of C++ was more about Moore's law
| than ecosystem, although having compilers that were
| beginning to not be completely rubbish also helped.
| pavlov wrote:
| Also C++ could be adopted incrementally by C developers.
| You could use it as "C with classes", or just use
| operator overloading to make vector math more tolerable,
| or whatever subset that you happened to like.
|
| So there's really three forces at play in making C++ the
| standard:
|
| 1) The Microsoft ecosystem. They literally stopped
| supporting C by not adopting the C99 standard in their
| compiler. If you wanted any modern convenience, you had
| to compile in C++ mode. New APIs like Direct3D were
| theoretically accessible from C (via COM) but in practice
| designed for C++.
|
| 2) Better compilers and more CPU cycles to spare. You
| could actually count on the compiler to do the right
| thing often enough.
|
| 3) Seamless gradual adoption for C developers.
|
| Rust has a good compiler, but it lacks that big ticket
| ecosystem push and is not entirely trivial for C++
| developers to adopt.
| pcwalton wrote:
| 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
| zozbot234 wrote:
| Yes, the Google folks are also funding efforts to improve
| Rust/C++ interop, per
| https://security.googleblog.com/2024/02/improving-
| interopera...
| meheleventyone wrote:
| I'd say the inertia is far more social than codebase size
| related. Right now whilst there are pockets of interest
| there is no broader reason to switch. Bevy as the leading
| contender isn't going to magic it's way to being capable
| of shipping AAA titles unless a studio actually adopts
| it. I don't think it's actually shipped a commercially
| successful indie game yet.
|
| Also game engines emphatically don't have to be huge.
| Look at Balatro shipping on Love2d.
| pcwalton wrote:
| There are a few successful games like Tunnet [1] written
| in Bevy.
|
| [1]: https://store.steampowered.com/app/2286390/Tunnet/
| meheleventyone wrote:
| Looks cool and well received but at ~300ish reviews
| hardly a shining beacon if we extrapolate sales from
| that. But I'll say that's a good start.
| TillE wrote:
| Speaking as a Godot supporter, I don't think sales
| numbers of shipped games are relevant to anyone except
| the game's developer.
|
| When evaluating a newer technology, the key question is:
| are there any major non-obvious roadblocks? A finished
| game (with presumably decent performance) tells you that
| if there are problems, they're solvable. That's the data.
| withinrafael wrote:
| Repo contributor here, just to curb some expectations a
| bit: it's one very smart guy (Kenny), his unpaid
| volunteer sidekick (me), and a few unpaid external
| contributors. (I'm trying to draw a line between those
| with and without commit access, hence all the edits.)
|
| There's no other internal or external Microsoft /support/
| that I'm aware of. I wouldn't necessarily use it as a
| signal of the company's intentions at this time.
|
| That said, there are Microsoft folks working on the Rust
| compiler, toolchain, etc. side of things too. Maybe those
| are better indicators!
| heavyset_go wrote:
| That's disappointing on Microsoft's part, because their
| docs make it seem like windows-rs is the way of the
| future.
|
| Thanks for your work, though!
| jacobgorm wrote:
| 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.
| synergy20 wrote:
| not true anymore, c11 and c17 are either supported or
| coming
|
| https://devblogs.microsoft.com/cppblog/c11-and-c17-standa
| rd-...
| meheleventyone wrote:
| Not really relevant to 30 years ago though.
| IggleSniggle wrote:
| That description of problems bodes well for Zig
| georgeecollins wrote:
| I worked on many of Activision's games 1995-2000 and C++
| was the overwhelming choice of programming language for
| PC games. C was more common for console. In 1996 the
| quality of MSFT IDE/ Compiler, plus the CPUs available at
| the time was such that it could take an hour to compile a
| big game. By 1998 it was a few minutes. As I recall I
| think MSFT purchased another companies compiler and that
| really changed Visual Studio.
| delfinom wrote:
| Kind of both in my opinion. But rust is bringing nothing to
| the table that games need.
|
| At best rust fixes crash bugs and not the usual logic and
| rendering bugs that are far more involved and plague users
| more often.
| pcwalton wrote:
| The ability of engines like Bevy to automatically
| schedule dependencies and multithread systems, which
| relies on Rust's strictness around mutability, is a big
| advantage. Speaking as someone who's spent a long time
| looking at Bevy profiles, the increased parallelism
| really helps.
|
| Of course, you can do job queuing systems in C++ too. But
| Rust naturally pushes you toward the more parallel path
| with all your logic. In C++ the temptation is to start
| sequential to avoid data races; in systems like Bevy, you
| start parallel to begin with.
| NBJack wrote:
| Aside from a physics simulation, I'm curious as to what
| you think would be a positive cost benefit from that
| level of multithreading for the majority of game engines.
| Graphical pipelines take advantage of the concept but
| offload as much work as possible to the GPU.
| Animats wrote:
| In big-world high-detail games, the rendering operation
| wants so much time that the main thread has time for
| little else. There's physics, there's networking, there's
| game movement, there's NPC AI - those all need some time.
| If you can get that time from another CPU, rendering
| tends to go faster.
|
| I tend to overdo parallelism. Load this file into a Tracy
| profile, version 0.10.0, and you can see what all the
| threads in my program are doing.[1] Currently I'm dealing
| with locking stalls at the WGPU level. If you have
| application/Rend3/WGPU/Vulkan/GPU parallism, every layer
| has to get it right.
|
| Why? Because the C++ clients hit a framerate wall, with
| the main thread at 100% and no way to get faster.
|
| [1] https://animats.com/sl/misc/traces/clockhavenspeed02.
| tracy
| pcwalton wrote:
| Animations are an example. I landed code in Bevy 0.13 to
| evaluate all AnimationTargets (in Unity speak, animators)
| for all objects in parallel. (This can't be done on GPU
| because animations can affect the transforms of entities,
| which can cause collisions, etc. triggering arbitrary
| game logic.) For my test workload with 10,000 skinned
| meshes, it bumped up the FPS by quite a bit.
| jacobgorm wrote:
| C++ classes with inheritance are a pretty good match for
| objects in a 3D (or 2D) world, which is why C++ became
| popular with 3D game programmers.
| hot_gril wrote:
| Yeah, OOP makes sense for games. The language will matter
| a bit for which one takes off, but anything will work
| given enough support. Like, Python doesn't inherently
| make a lot of sense for data processing or AI, but it's
| the big one for that.
| kagakuninja wrote:
| OOP kind of goes out the window when people start using
| entity component systems. Of course, like the author, I'm
| not sure I'll need ECS since I'm not building a AAA game.
| hamilyon2 wrote:
| I really hope that C++ evolves with gamedev and they become
| more and more symbiotic.
|
| Maybe adoption of rust by gamedev community isn't the best
| thing to wish to happen to language. Maybe it is better to
| let other crowd to steer evolution of rust, letting system
| programming and gamedev drift apart
| holoduke wrote:
| Many tried c++ in early 90s, but wasnt it too slow/memory
| intensive? You had to implement lots of inline c/assembly to
| have a bit of performance. Nowadays everything is heavily
| optimized, but back then not.
| ovao wrote:
| If you're referring to game dev specifically, there have
| been (and continue to be) concerns around the weight of C++
| exception handling, which is deeply-embedded in the STL.
| This proliferated in libraries like the EASTL. C++ itself
| however is intended to have as many zero-cost abstractions
| as possible/reasonable.
|
| The cost of exception handling is less of a concern these
| days though.
| summerlight wrote:
| Yeah, gaming industry has become mature enough to build up
| its own inertia so it will take some time for new
| technologies to take off. C# has become a mainstream gamedev
| language thanks to Unity, but this also took more than a
| decade.
| duped wrote:
| > The "async" system is optimized for someone who needs to run
| a very large web server,
|
| Even there it's very problematic at scale unless you know what
| you're doing. async/await isn't zero cost, regardless of what
| people will tell you.
| zamalek wrote:
| Absolutely. Async/await typically improves headroom
| (scalability) at the cost of latency and throughput. It may
| also make code easier to reason about.
| littlestymaar wrote:
| > at the cost of latency and throughput.
|
| Compared to what?
|
| Doing epoll manually?
| jvanderbot wrote:
| Threading, probably.
| eddd-ddde wrote:
| Threading is compatible with async
| jvanderbot wrote:
| "threading alone" as in a thread per request.
| littlestymaar wrote:
| I don't think so, because there isn't a performance
| drawback compared to threads when using async. In fact
| there's literally nothing preventing you from using a
| thread per task as your future runtime and just blocking
| on `.await` (and implementing something like that is a
| common introduction to how async executors run under the
| hood so it's not particularly convoluted).
|
| Sure there's no reason to do _that_ , because non-
| blocking syscalls are just better, but you can...
| astrange wrote:
| Async/await isn't related to threading (although many
| users and implementations confuse them); it's a way of
| transforming a function into a suspendable state machine.
| jvanderbot wrote:
| I know. But threading, and earlier processes, were less
| scalable but potentially faster ways of handling
| concurrent requests.
| otterley wrote:
| It's also much easier to reason about, since scheduling
| is no longer your problem and you can just write
| sequential code.
| cmrdporcupine wrote:
| If I'm not doing slow blocking I/O, I'm not doing epoll
| anyways.
|
| But the moment somebody drops async into my codebase,
| yay, now I get to pay the cost.
| zamalek wrote:
| A reactor has to move the pending task to some type of
| work queue. The task has to pulled off the work queue.
| The work queue is oblivious as to the priority of your
| tasks. Tasks aren't as expensive as context switching,
| but they aren't free either: e.g. likely to ruin CPU
| caches. Less code is fewer instructions is less time.
|
| If you care enough, you generally should be able to outdo
| the reactor and state machines. Whether you should care
| enough is debatable.
| duped wrote:
| I disagree with this, you're probably not paying much (if
| at all) in latency or throughput for better scaling.
|
| What you're paying for with async/await is a state machine
| that describes the concurrent task, but that state machine
| can be incredibly wasteful in size due to the design of
| futures and the desugaring pass that converts async/await
| into the state machine.
|
| That's why I said it's not "zero cost" in the loosest
| definition of the phrase - you can write a better
| implementation by hand.
| pcwalton wrote:
| > I'd expected some AAA title to be written in Rust by now.
|
| Why? Those kinds of game engines are enormous amounts of code,
| and there's little incentive to rewrite.
|
| I do strongly disagree that we aren't ever going to see large-
| scale game development in Rust; it just takes time. Whether
| games adopt an engine is largely about that engine's maturity
| rather than anything about the language. Bevy is quite young;
| 0.13 doesn't even have support for animation blending yet (I
| landed that for 0.14).
| VelesDude wrote:
| It was a few years back that the question came up to the
| developers of a Call of Duty title. "Is there still code from
| Quake 3 in COD?". They dodge around it by saying something
| like "we cannot deny this but e use the most appropriate tech
| where needed".
|
| While not confirmation, I wouldn't be surprised if there is a
| few nuggets of Q3 in that code base still doing some of the
| basics. That would be really cool if it is true.
|
| It seems like unless you are someone like John Carmack or
| most of Nintendo, game dev tools are about what can get the
| best results quickest rather than any sort of technical
| specifics. It is a business after all.
| scruple wrote:
| If that's the question... Let me assure you that there are
| decades-old pieces of code inside of, and used to assemble,
| many modern AAA games coming out of mature studios. The
| systems and tooling is typically carried forward. I don't
| think this is some big secret and you've intuited exactly
| the reason why:
|
| > game dev tools are about what can get the best results
| quickest rather than any sort of technical specifics. It is
| a business after all.
| meheleventyone wrote:
| A lot of big projects have amazing longevity to their older
| architectural decisions. Unreal still has a lot of stuff in
| it people that used UE1 would recognize, I did most of my
| professional development on UE3 and a bunch of that is
| still pretty recognizable. Similarly Chrome is a product of
| the time it was first created. And looking into the Windows
| source is probably like staring into the stygian abyss.
|
| There is a lot of legacy and tech debt out there!
| jsheard wrote:
| A neat real-world example of ancient Quake code surviving
| to this day is visible in Valves games - the hardcoded
| patterns for flickering lights in Quake 1 survived into
| GoldSrc and then into Source and then into Source 2, most
| recently showing up in Half Life Alyx, 24 years on from
| their original appearance in Quake 1.
|
| https://www.alanzucconi.com/2021/06/15/valve-flickering-
| ligh...
|
| Basically all of the bigger systems will have been Ship-of-
| Theseus'd several times over by now, but little things like
| that can slip through the cracks.
| matheusmoreira wrote:
| > The "async" system is optimized for someone who needs to run
| a very large web server, with a huge number of clients sending
| in requests.
|
| Can you please elaborate on this? I see a lot of similar
| concerns in other contexts too. Linux kernel's scheduler for
| example. Is it a throughput/latency tradeoff?
| cmrdporcupine wrote:
| The current popularity of the async stuff has its roots in
| the classic "c10k" problem.
| (https://en.wikipedia.org/wiki/C10k_problem)
|
| A perception among some that threads are expensive,
| especially when "wasted" on blocking I/O. And that using them
| in that domain "won't scale."
|
| Putting aside that not all of use are building web
| applications (heterodox here in HN, I know)...
|
| Most people in the real world with real applications will not
| hit the limits of what is possible and efficient and totally
| fine with thread-based architectures.
|
| Plus the kernel has gotten more efficient with threads over
| the years.
|
| Plus hardware has gotten way better, and better at handling
| concurrent access.
|
| Plus async involves other trade-offs -- running a state
| machine behind the scenes that's doing the kinds of context
| switching the kernel & hardware already potentially does for
| threads, but in user space. If you ever pull up a debugger
| and step through an async Rust/tokio codebase, you'll get a
| good sense for what the overhead here we're talking about is.
|
| That overhead is fine if you're sitting there blocking on
| your database server, or some HTTP socket, or some
| filesystem.
|
| It's ... probably... not what you want if you're building a
| game or an operating system or an embedded device of some
| kind.
|
| An additional problem with async in Rust _right now_ is that
| it involves bringing in an async runtime, and giving it
| control over execution of async functions... but various
| things like thread spawning, channels, async locks, etc. are
| not standardized, and are specific per runtime. Which in the
| real world is always tokio.
|
| So some piece of code you bring in in a crate, uses async,
| now you're having to fire up a tokio runtime. Even though you
| were potentially not building something that has anything to
| do with the kinds of things that tokio is targeted for
| ("scalable" network services.)
|
| So even if you find an async runtime that's optimized in some
| other domain, etc (like glommio or smol or whatever) --
| you're unlikely to even be able to use it with whatever
| famous upstream crate you want, which will have explicit
| dependencies into tokio.
| cmrdporcupine wrote:
| _" I tend to agree about the "async contamination" problem. The
| "async" system is optimized for someone who needs to run a very
| large web server, with a huge number of clients sending in
| requests. I've been pushing back against it creeping into areas
| that don't really need it."_
|
| 100% this. As I say elsewhere in these threads: Rust is the
| language that Tokio ate. It isn't even just async viral-chain-
| effect, it's that on the whole crates for one async runtime are
| not even compatible with those of another, and so it's all
| really just about tokio.
|
| Which sucks, if you're doing, y'know, systems programming or
| embedded (or games). Because tokio has no business in those
| domains.
| andersa wrote:
| > I'd expected some AAA title to be written in Rust by now.
| That hasn't happened, and it's probably not going to happen,
| for the reasons the author gives.
|
| The main reason is that you can't ship that Rust code on PS5 in
| a sensible manner. People have tried, got useless toys to
| compile, but in the end even Embark gave up. I remember seeing
| something from them that they had moved Rust to server-only.
| overflyer wrote:
| Zig zig zig zig zig :D
| melodyogonna wrote:
| Rust being the best alternative to C++ is why I'm wildly rooting
| for Mojo. This language sacrifices a lot in ergonomics and UX to
| the alter of safety. And the Rust community never fails to
| interject with "Well, Akshually..." whenever you complain.
| FrustratedMonky wrote:
| I've been thinking of embarking on a Rust/GUI/Game. Guess, this
| will save some grief. Is Rust the future? Will this situation
| improve? I've been wanting to like Rust, but this seems to be
| indictment.
| layer8 wrote:
| It's unlikely to improve anytime soon, and there are no
| indications that Rust will be the future of game programming.
| lelanthran wrote:
| > Is Rust the future? Will this situation improve?
|
| I don't follow this too closely, but I have not seen any
| indications that _any_ of the frustrations expressed in the
| article are on a Rust roadmap.
|
| IOW, just about everything in that article is a `WONTFIX` or
| `NOTABUG` for the Rust maintainers.
| fwsgonzo wrote:
| I see some of those things could perhaps be solved by
| implementing parts of the game in a sandbox. I know that's work:
| I'm doing it myself. But all the work with the host-guest
| boundary (let's not call it bindings, please), is worth it in the
| end.
|
| I have a C++ game client, a C++ game server, and a shared C++
| game script that is transferred to all clients, running in a
| RISC-V emulator. That means the script will fundamentally execute
| the same way on all clients, and the server. I have no idea what
| everyone else is doing. This is what I'm doing now, and the more
| fleshed out it's becoming, the more I actually like it this way.
| I don't think I could easily "go back" to other solutions.
| erikbye wrote:
| Rust... what is it good for? "Systems programming" ...
|
| Rust is not good for raw performance. Neither for prototyping and
| iteration.
|
| Personally I think operating systems (kernels) should be as
| performant as possible, and C/C++ has been good enough for
| decades.
|
| Anyone really unhappy with Linux/BSD/Windows/macOS performance?
|
| What systems are we talking about that benefits from Rust?
| Advanced weapon systems that should absolutely not fail?
| Controllers for air planes? Traffic controllers? Radar? Power
| grid?
|
| Google, fb, amazon, etc. use C/C++ to squeeze the most
| performance out of anything I/O heavy, and security is not an
| issue that deep in the stack, that's not the exploitation layer.
| Karellen wrote:
| > Personally I think operating systems (kernels) should be as
| performant as possible, and C/C++ has been good enough for
| decades.
|
| If that how you want your OS, that's fair enough. But I think a
| lot of people are happy to trade (to some degree, at least)
| performance for security, and would prefer that their OSs are
| as secure as possible first, and as performant as they can be
| second.
| dgellow wrote:
| Rust is already in Windows:
| https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rew...
|
| Linux added Rust support: https://docs.kernel.org/rust/
| erikbye wrote:
| Well aware, and it affects none of my points.
| lsllc wrote:
| No, I'm not concerned with Linux/BSD/macOS performance, it's
| pretty good (I took Windows out because it does have
| performance issues [0]!). What I _am_ concerned about is
| security bugs, memory errors, buffer overflows etc, all of the
| things Rust attempts to solve [1].
|
| I think for weapons & flight control, ATC systems, we already
| have Ada that's designed for "can't fail systems".
|
| [0] https://www.blobstreaming.org/former-microsoft-developer-
| say...
|
| [1] https://www.zdnet.com/article/microsoft-70-percent-of-all-
| se...
| erikbye wrote:
| I agree, operating systems should have less out-of-bounds
| memory issues. Is that Rust's place? Replacing the parts of
| OS code where it's OK to sacrifice some performance?
|
| Ada has a foothold for sure, but there's a surprising amount
| of C++ in military planes and weapon systems.
|
| I didn't read [0], but the parts of Windows that's poorly
| performing is not the fault of the language.
| bantunes wrote:
| > Anyone really unhappy with Linux/BSD/Windows/macOS
| performance?
|
| I wasn't unhappy with Windows' performance in the 90s until I
| saw BeOS. This is the kind of thing we're in the dark about
| what could be because the faster, rewritten fron scratch, free
| from API baggage systems are nowhere to be found.
| erikbye wrote:
| Haven't used BeOS, but to clarify, I do have issues with
| Windows and performance, especially general input latency and
| responsiveness when compared to Linux, as I use both daily.
| But overall I think it's decent, and at the very least, not
| the fault of the language used, but more about legacy issues
| and technical debt. Anyone having worked with winapi and mfc
| knows the codebase is a mess.
| Yoric wrote:
| Well, as far as I can tell, in the big language shootout (which
| is still the only decent language benchmark I know, but if you
| have others, I'd be happy to read them), in all the individual
| benchmarks I've looked at Rust is either first or within 3%
| performance of being first. So, this suggests that Rust is
| actually pretty good for raw performance.
|
| In addition, I know that I'm way more productive for
| prototyping and iteration in Rust than in C, C++ (and I used to
| write C++ code professionally for a while), JavaScript, Go,
| Python (and I've been writing professionally in these three
| languages for a while now) etc. I _might_ be more productive in
| Java or OCaml. Yes, this is entirely anecdotal and it depends
| heavily on the kind of problems you're dealing with. I tend to
| focus on problems that have complicated invariants, and for
| which reproducing/pinpointing the issue in a debugger is a big
| annoyance.
|
| > Google, fb, amazon, etc. use C/C++ to squeeze the most
| performance out of anything I/O heavy, and security is not an
| issue that deep in the stack, that's not the exploitation
| layer.
|
| Interestingly, all these companies are migrating some of their
| systems to Rust. This suggests that they find the language
| convincing enough.
| erikbye wrote:
| > Interestingly, all these companies are migrating some of
| their systems to Rust. This suggests that they find the
| language convincing enough.
|
| I feel most large companies and some smaller ones are
| interested in trying out Rust, it's trendy. But time will
| show for which parts the switch was advantageous; and I'm
| very interested in the findings. The premise of the language
| is indeed convincing a lot of people. People do however,
| choose the wrong tool for the wrong job all the time, OP's
| article in point.
| Yoric wrote:
| Absolutely.
| indigoabstract wrote:
| I've become wary of commenting on articles that mention the pros
| and cons of various languages, but I still find it strange that
| so many people are so strongly focused on what their favourite
| language can do (usually better than others), instead of the
| project they're working on. When it should be the other way
| around.
|
| The joke he mentioned about having 50 engines written but only 5
| games certainly rings true and I don't think the language is the
| main problem preventing people from getting their projects done..
| avery17 wrote:
| The hardest part of a project is finishing it. I think the main
| issue is the fun problems to solve happen very early in the
| project and once those are done it becomes incredibly tedius
| and boring and I usually lose focus until the project dies. Its
| difficult to maintain motivation.
| indigoabstract wrote:
| Right. If someone could come up with a pill or something to
| maintain motivation and make all the bugs and hairy annoying
| details feel fresh again, just like the feeling of starting
| over, I would certainly part with my money. But there's no
| such thing unfortunately.
| TulliusCicero wrote:
| Interesting, I almost find it the opposite right now.
| Learning the engine is a pain in the ass -- it's not
| particularly hard, just tedious to learn all the APIs and
| quirks -- and then when you're initially building the thing,
| "it's not fun yet" for a quite a while. But then once you
| have the fundamentals down, you can add more abilities and
| characters and other features, that's the fun shit.
|
| I was working on the AI last night, and since I already had
| one functioning AI agent, it was pretty easy to spin up
| variations that behaved in moderately different ways, which
| was very fun!
|
| I've only been dabbling though, and still sort of in the
| prototype stage, not quite a full game yet but getting there.
| Maybe I'll feel more like you suggest deeper into
| development.
| fuzztester wrote:
| Yep.
|
| Bikeshedding, how many angels can dance on the head of a pin,
| and https://xkcd.com/927/ are some ways of loosely describing
| what you said.
|
| https://en.m.wikipedia.org/wiki/How_many_angels_can_dance_on...
|
| >but I still find it strange that so many people are so
| strongly focused on what their favourite language can do
| (usually better than others), instead of the project they're
| working on.
|
| Yes, if they are so convinced of that, why are they not back in
| the office or at home, working busy as a beaver on their
| project, using that great programming language, the benefits of
| which they extol?
|
| Smells fishy to me.
|
| Oops.
|
| Do people see what I did there? ;)
| meheleventyone wrote:
| IMO one language can sidetrack you more than another. It might
| not be the main problem but a language that gets in the way for
| your usecase causes you to focus on the wrong problem. Making a
| good game is really hard and really needs you to focus outside
| the tech.
| lastgeniusua wrote:
| > The most fundamental issue is that the borrow checker forces a
| refactor at the most inconvenient times. Rust users consider this
| to be a positive, because it makes them "write good code", but
| the more time I spend with the language the more I doubt how much
| of this is true. Good code is written by iterating on an idea and
| trying things out, and while the borrow checker can force more
| iterations, that does not mean that this is a desirable way to
| write code. I've often found that being unable to just move on
| for now and solve my problem and fix it later was what was truly
| hurting my ability to write good code.
|
| The latter part of this is true for any strongly statically typed
| language (with Rust expanding this to lifetimes), which negates
| the beginning of this paragraph -- once you get things compiled,
| you won't need to refactor, unless you are changing major parts
| of your interfaces. There are plenty of languages that do not
| have this problem because it is a design choice, hardly something
| Rust can "fix", it's what makes it Rust.
| modernerd wrote:
| Allan Blomquist's tooling demo they mention is incredible, go
| watch it:
|
| https://www.youtube.com/watch?v=72y2EC5fkcE
|
| Really sells the value of having a tight developer feedback loop:
| it shows hot reloading for code and graphics, a reversible
| debugger, live profiling with flame graphs, a data inspector with
| data breakpoints, time travel inspection with a scrub bar,
| session sharing and replay with the same scrub bar and direct
| links from the call stack to a breakpoint, and more.
|
| Above the many niggles they had with Rust itself, this greatly
| helps me understand why Rust left them wanting more from their
| working environment. They say they've switched back to Unity with
| https://hotreload.net/ to try to capture some of that, and now I
| see why. (It's a shame that hot reloading tooling in Rust wasn't
| ready for them yet, but I see why they've moved on instead of
| waiting/contributing.)
| mikhmha wrote:
| Interesting read! If I had not picked Elixir + Godot for the
| multiplayer game I'm making, then I would've gone with Rust for
| the whole thing. The old naive version of me would've tried doing
| it in C++ + Unreal but I knew better this time around.
|
| I think multiplayer game devs are sleeping on Elixir! It has made
| the network side of things so much easier and intuitive with fast
| prototyping and built in monitoring - so many lifetime issues are
| easily found and addressed. I'm pairing Elixir with Godot, Godot
| is used for the frontend game client. And its crazy because I
| thought the game client part would be the "hard" part as it would
| be a new skillset to learn, but Godot makes the actual game part
| very easy. GDScript is easy to learn, and the way Godot uses
| "signals" is very similar to the backend code in Elixir with
| message passing so its not a huge cognitive shift to switch
| between server/client code.
|
| I get that BEAM doesn't lend well to highly computational tasks,
| but I just don't see how thats an issue for many types of
| multiplayer games? If you aren't making some crazy simulation
| game, then most of the backend computation is more around
| managing client state and doing "accounting" every tick as inputs
| are processed. The most computational task I've had is server-
| side NPC Pathfinding, which I was able to quickly offload onto
| seperate processes that chug along at their own rhythm.
| stephc_int13 wrote:
| As a game developer for about two decades, I've never considered
| Rust to be a good programming language choice.
|
| My priorities are reasonable performances and the fastest
| iteration time possible.
|
| Gameplay code should be flexible, we have tons and tons of edge
| cases _by design_ because this is the best way to create
| interesting games.
|
| Compilation time is very important, but also a flexible enough
| programming structure, moving things around and changing your
| mind about the most desirable approach several times a day is
| common during heavy development phases.
|
| We almost never have specifications, almost nothing is set until
| the game is done.
|
| It is a different story for game engines, renderers, physics,
| audio, asset loaders etc. those are much closer to system
| programming but this is also not where we usually spend the most
| time, as a professional you're supposed to either use off-the-
| shelf engines or already made frameworks and libraries.
|
| Also, ECS is, IMHO, a useful pattern for some systems, but it is
| a pain in the butt to use with gameplay or UI code.
| mrkeen wrote:
| > My priorities are reasonable performances and the fastest
| iteration time possible.
|
| I bought Mount & Blade II Bannerlord in 2020-03-30. I love it
| to death, but come on... // 2024-02-01 $
| curl https://www.taleworlds.com/en/News/552 | grep "Fixed a
| crash that" | wc -l 29 // 2023-12-21 $
| curl https://www.taleworlds.com/en/News/549 | grep "Fixed a
| crash that" | wc -l 6 // 2023-12-14 $
| curl https://www.taleworlds.com/en/News/547 | grep "Fixed a
| crash that" | wc -l 101
|
| Maybe feeling like you're iterating fast isn't the same as
| getting to the destination faster.
|
| Edit: Lol guys calm down with the down-vote party. I was
| counting crashes, not bugs: $ curl
| https://www.taleworlds.com/en/News/547 | grep "Fixed a bug
| that" | wc -l 308
|
| Does your C++ not crash, just theirs?
| tedajax wrote:
| This comment is nonsense
| stephc_int13 wrote:
| Yeah this is a common problem in the industry, we rarely have
| enough time to refactor what should be considered prototype-
| level code into robust code.
| hi-v-rocknroll wrote:
| The game dev industry could form a consortium to launch its
| own dedicated general purpose language built from scratch
| to compile very fast like V or Go, run predictability, be
| much safer, be more reusable, and be extremely productive
| with the lessons learned from C, C++, C#, and more.
|
| Also, I think LLMs will be able to run against code bases
| to suggest mass codemods to clean things up rather than
| having humans make a zillion changes or refactoring fragile
| areas of tech debt. LLMs are already being applied to
| generate test cases.
| stephc_int13 wrote:
| I believe that better tooling can help, yes. With
| refactoring, debugging, creating performance and style
| reports, updating documentation and a ton of other stuff.
| jibe wrote:
| Jonathan Blow's Jai is an attempt at something like this.
| It's looking promising so far!
| lionkor wrote:
| With Rust and the exact time iteration times, management and
| deadlines, you end up with the same amount, just theyre
| panic!() instead. Thats an improvement, sure, but its
| fighting a symptom.
| mrkeen wrote:
| With modern languages that take safety more seriously, it's
| a _lot_ easier to spot places where the code 'goes wrong'.
|
| In an older language, you have nothing to tell you whether
| you're about to dereference null:
| foo.bar.baz = ...;
|
| Even if you've coded it 100% correctly, that line of code
| still _looks the same_ as code which will segfault. You
| need to look elsewhere in codebase to make sure the right
| instructions populated those fields at the right time. If I
| 'm scrolling past, I'll slow down everytime to think "Hey,
| will that crash?"
|
| Compare that with more safety focused languages where you
| can see the null-dereferences on the page. Unwrap() or
| whatever it is in Rust. Since they're visually present, you
| can code fast by using the unsafe variants, come back
| later, and know that they won't be missed in a code review.
| You can literally _grep_ for unsafe code to refactor.
| thom wrote:
| Hard to know what TaleWorlds are actually optimising for
| because half the features of Bannerlord feel like they've
| never been played by a dev let alone iterated on.
| bogwog wrote:
| That game (currently) has 88% positive reviews on steam and a
| 77 metacritic score with over 15.5k people playing the game
| right now (according to steamcharts.com)
|
| Thats a lot of happy customers.
| meinersbur wrote:
| My impression is that this is due to their non-robust
| programming style. They do not add fallback behavior when
| e.g. receiving a null object. It would still be a bug, but
| could be a log entry instead of crash.
| mrkeen wrote:
| > My impression is that this is due to their non-robust
| programming style.
|
| It's been 50+ years. I don't think that it's worthwhile
| just telling the programmer to do a better job.
|
| > They do not add fallback behavior when e.g. receiving a
| null object. It would still be a bug, but could be a log
| entry instead of crash.
|
| This is a pretty big feedback loop: * The
| programmer puts the null into the code * The code is
| released * The right conditions occur and the player
| triggers it * IF DONE SKILLFULLY AND CORRECTLY the
| game is able to recover from the null-dereference, write it
| out to a log, and get that log back to the developers.
| * The programmer takes the null out of the code.
|
| If you don't do the first step, you don't get stuck doing
| the others either.
| astrange wrote:
| Arbitrary recovery to null pointers isn't a good way to do
| robust programming. I recommend doing the exact opposite
| actually.
|
| https://en.wikipedia.org/wiki/Crash-only_software
|
| https://medium.com/@vamsimokari/erlang-let-it-crash-
| philosop...
| 0x457 wrote:
| A crash of an actor in BEAM is incomparable to a crash of
| a video game.
| hi-v-rocknroll wrote:
| As a non-game dev who uses Rust and Elixir, Rust wouldn't be my
| first pick for a large gamedev studio for multiple reasons. As
| for alternatives worth evaluating: Crystal, Cython (compiled
| Python), or Nim could result in increased gamedev productivity
| over C++ or C#. Maybe even Go because the iteration and compile
| times are very fast, and the learning curve is very low.
| Nuzzerino wrote:
| Does Crystal support Hot Reloading? The slow compilation
| speed is a non-starter for me.
| hi-v-rocknroll wrote:
| Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better
| choice for such a use-case.
|
| * So fast, they really don't need HCR.
| Nuzzerino wrote:
| I haven't tried it yet but I've wondered if Elixir might
| be a good choice for a game server with many concurrent
| players.
| prisenco wrote:
| | _Go because the iteration and compile times are very fast_
|
| Safety is important and for certain applications, Rust is
| unrivaled.
|
| But for games, like web apps, where time to market and
| innovation can be just as if not more important than being
| free of runtime errors, Go is more suited to rapid
| development than Rust on compile times alone.
|
| Of course, the libraries and support for both aren't quite
| there yet, so at this point neither is well suited to game
| dev.
| hi-v-rocknroll wrote:
| I agree. We almost have a paradox of choice nowadays
| because it's easier than ever to create new language
| platforms. Rust is something different because its thesis
| is safety and performance by default, more or less
| optimized for systems development primarily, but at the
| bargain of making dangerous things more complicated to
| accomplish somewhat intentionally. Unconventional languages
| are sometimes used as a conspicuous challenge to attract
| developers or to attempt to move some parts of an industry
| into new territory.
| nottorp wrote:
| Now they need to try blockchain :)
| SeanAnderson wrote:
| I've experienced a lot of these concerns while building
| https://github.com/MeoMix/symbiants
|
| I have a simple question that maybe someone smarter than me can
| answer confidently:
|
| If I want to build something akin to Dwarf Fortress (in terms of
| simulation complexity) as a browser-first experience - what stack
| should I choose?
|
| Originally, I prototyped something out using React, PixiJS, and
| ReactPixi (https://github.com/MeoMix/antfarm). The two main
| issues I ran into were the performance of React's reconciler
| processing tens of thousands of entities when most weren't
| changing (despite heavy memoization) and GC lurching due to
| excess object allocations. My takeaway was that if I wanted to
| continue writing in JS/TS that I would need to write non-
| idiomatic code to avoid excess allocations and abandon React.
| This approach would result in me effectively creating my own
| engine to manage state.
|
| I decided to not go that direction. I chose Rust because no GC is
| a language feature (especially good since GCs in WASM are heavy)
| and I chose Bevy because it seemed like a fairly structured way
| to mutate a large amount of code.
|
| Progress has been slow for a lot of the reasons listed in this
| article. I've written a lot of this off to WASM being a new
| frontier for game dev, and I'm new to Rust/Bevy/ECS/gamedev, and
| rationalized my effort by noting there's not a lot of complex
| simulation games running in browser (that I'm aware of).
|
| It's not clear to me that I've made the right decision, and just
| need to take the good with the bad, in order to develop the type
| of game I want in the type of environment I want.
| unclad5968 wrote:
| I personally would use C++ with SDL2, but I use c++ a lot
| already so I'm biased. Emscripten would allow you to target
| WASM.
| the__alchemist wrote:
| Excellent article. Rust is my favorite language for several uses,
| but I'm becoming less optimistic about it as a versatile language
| long-term. An important point regarding the article is that it
| mixes rust shortfalls, and shortfalls of _any language other than
| C++_ for games. I 've personally used Bevy for a 3D wave function
| renderer, but moved away from it in favor of a custom WGPU-engine
| due to Bevy's complicated ECS DSL.
|
| I am worried because: - Games seem like a no-go,
| as articulated in the article - Web usage has been
| dominated by Async, with no signs of reversing. I have no
| interest in this. And, there is no promising Django analog or
| ORM. - Emebedded support on Cortex-M, and to a lesser
| extend RISC-V is good at its core, but the supporting libraries
| have a mix of A: the game failures listed in the article (Driven
| by hype, mostly makers, serious companies are not using it), and
| B: Also being taken over by Async.
|
| This is disappointing to me, because IMO the syntax, tooling, and
| general language experience of Rust is far better than C and C++.
| hot_gril wrote:
| Why is async such a dealbreaker for this guy? Especially for
| web dev.
| vacuity wrote:
| I think the async Rust shortcomings are largely solvable, but I
| sympathize with everyone running into the numerous problems
| right now.
| pcwalton wrote:
| As someone who's become a core contributor to Bevy lately, while
| _also_ doing contract work in Unity on the side, I obviously
| disagree with the idea that Rust isn 't up to the task of game
| dev. The grass isn't greener on the Unity side, with a mountain
| of technical debt holding the engine back. (They're still using
| Boehm GC in 2024!) Bevy is a breath of fresh air just because
| it's relatively new and free of legacy. Using Rust instead of C++
| is just one part of that. Bevy has a more modern design
| throughout: for instance, it has a relatively straightforward
| path to GPU-driven rendering in an integrated system, without
| having to deal with three incompatible render pipelines (BiRP,
| HDRP, URP).
|
| What I find more interesting is the parts of the article that
| boil down to "Rust isn't the best language for rapid development
| and iteration speed". And that may well be true! I've long
| thought that the future of Bevy is an integrated Lua scripting
| layer [1]. You don't even need to get into arguments about the
| suitability of the borrow checker: it's clear that artists and
| designers aren't going to be learning Rust anytime soon. I'd like
| to see a world in which Rust is there for the low-to-mid-level
| parts that need performance and reliability, and Lua is there for
| the high-level logic that needs fast iteration, and it's all a
| nicely integrated whole.
|
| Long-term, I think this world would actually put Bevy in a better
| place than the existing engines. Unity forces you into C# for
| basically everything, which is both too low-level for non-
| programmers to use and too high-level for performance-critical
| code (unless you have a source license, which no indie developer
| has). Unreal requires C++, which is even more difficult than Rust
| (IMO), or Blueprints, which as a visual programming language is
| way too high-level for anything but the simplest logic. Godot
| favors GDScript, which is idiosyncratic for questionable gain. I
| think Rust and Lua (or something similar) would put Bevy in a
| Goldilocks spot of having two languages that cover all the low-,
| mid-, and high-level needs well.
|
| As for the other parts of the article, I disagree with the ECS
| criticism; ECS has some downsides, but the upsides outweigh the
| downsides in my view. I do agree that Bevy not having an official
| editor is an ongoing problem that desperately needs fixing.
| Personally, I would have prioritized the editor way higher
| earlier in Bevy's development. There is space_editor [2] now,
| which is something.
|
| [1]: https://github.com/makspll/bevy_mod_scripting
|
| [2]: https://github.com/rewin123/space_editor
| Xeamek wrote:
| I mean, if you agree that the ideal for bevy would be lua
| integration, you are kinda agree with the author that Rust
| itself is suboptimal (at least in layer of game scropting),
| don't You?
| pcwalton wrote:
| I think whether you prefer Rust or a scripting language like
| Lua for high-level game logic comes down to what your needs
| are and personal preference. There are reasonable arguments
| on both sides.
| lelanthran wrote:
| > There are reasonable arguments on both sides.
|
| What are the reasonable arguments for using Rust[1] for
| game logic instead of a scripting language like Lua?
|
| [1] Or C++, etc.
| pcwalton wrote:
| Rust, in my view, is easy to justify over C++: the Cargo
| ecosystem makes high-quality libraries accessible, you'll
| spend less time debugging crashes, the language is more
| modern so you don't have to deal with stuff like header
| files, etc.
|
| Compared to a scripting language like Lua, the benefits
| of Rust are more situational. Rust code runs a lot
| faster, and it takes better advantage of parallelism. It
| also has no garbage collection overhead. Does that
| outweigh the downsides? It's entirely dependent on your
| game and which logic in particular you're talking about.
| Xeamek wrote:
| As for ECS, it's not really about upsides or downsides. It's
| about the fact that Rust effectively forces You to use ECS
| everywhere, because 'normal' game objects interacting won't fly
| under borrow checker.
|
| And no matter how many upsides ECS can have, being forced to
| use it everywhere, rather when You want to, is the painfully
| part.
| 999900000999 wrote:
| When will an editor be added?
|
| That's what's holding me back from jumping into Bevy.
|
| I actually think Rust is really hard, but I also think it would
| be beneficial to my career.
| pcwalton wrote:
| Right now it's blocked on cart rewriting the scene format.
| npalli wrote:
| Just waiting for someone to write a 5000 word essay on why they
| are moving from Rust to do data science stuff. Totally puzzled by
| everyone trying to get on to the Rust bandwagon on DS/DE, when
| being able to iterate and make changes fast is why Python rules
| even though it is dog slow.
| ArkimPhiri wrote:
| Tried Rust for a very simple game, it didn't just feel right.
| It's like the language itself is begging you not to use it for
| game dev. Lol
| Nevermark wrote:
| The TLDR I got from that: Normal coding has two concerns:
|
| 1. What behavior do I want?
|
| 2. How am I implementing that behavior?
|
| Experimenting with #1 is slowed down by the current end point of
| #2. Sometimes not at all, sometimes a lot, depending on luck and
| how #2 anticipated the class of experiment I am trying.
|
| Rust adds:
|
| 3. How can the implementation code be organized so its stringent
| safety checks are validated?
|
| Now experimenting with #1 is complicated by two dimensions of
| design history instead of one. And the latter dimension being two
| steps of abstraction/design-dependency away from concern #1, is
| going to be very brittle.
|
| Never used Rust, but that sounds painful.
| _obviously wrote:
| Clearly he needs a framework for making games in Rust instead of
| iterating through rust primitives.
| Klonoar wrote:
| I've been writing Rust professionally (and predominantly) for ~5+
| years now, with brief detours in game dev. I'll defer to others
| who are _dedicated_ game devs, but overall I think this article
| is well written and a healthy thing for Rust overall. We need
| this kind of breakdown if things are going to continue to
| improve.
|
| I'd say I only have two somewhat arbitrary comments on this
| piece:
|
| _> Rust on the other hand often feels like when you talk to a
| teenager about their preference about anything. What comes out
| are often very strong opinions and not a lot of nuance._
|
| This is a rabbit hole of a topic so I don't want to go _too_ deep
| into it, but this isn 't a Rust-specific issue _(though it may be
| a current Rust issue)_. I 've seen this same pattern play out
| across so many languages over the years, from Lisp to Rust to
| everything in between.
|
| A very unscientific and definitely not charitable way I've
| thought about this over the years is that programming, by nature,
| is an OCD person's dream. We wind up with a pretty large chunk of
| people who seemingly move language to language in the hype cycles
| in search of some weird nirvana level that is likely just
| unobtainable. I feel like Rust has slowly started shedding this
| as the community has grown/matured and some people have moved on
| to the next hype cycle but I often find myself wishing it'd
| happen faster.
|
| I write Rust because when I sleep at night, I just don't get
| woken up by being paged for nearly as many weird edge cases. The
| Rust I write often has a litany of compromises because I want to
| just get shit done and move on with my life, and the remaining
| guarantees are still good enough. The number of times I've had to
| tell people to leave it be is definitely higher than it should
| be.
|
| _> I know that just by saying "global state" I'm immediately
| triggering many people who have strong opinions on this being
| wrong. I feel this is one of those things where the Rust
| community has created a really harmful and unpractical rules to
| put on projects/people._
|
| This isn't really a Rust-specific thing, though I can't fault the
| author for including it. People have been beating the drum of "no
| globals" for as long as I can remember... and simultaneously, as
| long as I can remember, game devs have come out of the woodwork
| to politely explain that the programming they do is often under
| very different constraints.
|
| I still periodically use global state for things because it's
| just faster at points, and no, I've never cared if people get
| annoyed by it.
|
| Anyway, here's to hoping this leads to positives for the
| community.
| chaosprint wrote:
| I've worked on Ambient Engine and now on the Bevy engine. I
| totally agree with these points, very valuable.
|
| I only make some comments from my professional (audio)
| perspective:
|
| We need the highlight author's affirmation of cli. Rust's tui
| (ratatui) is great. I used it to make Glicol-cli [1]. If you are
| a Linux user, you are welcome to test the music production of the
| code.
|
| Speaking of game audio, I actually think rust is perfect for
| audio. I have also continued to develop Glicol [2] recently, and
| my recent goal (starting tomorrow) is the bevy_glicol plug-in. I
| want to solve bevy's audio problem on the browser.
|
| All in all, even though I've had my share of pain with ecs, I
| still think rust is very valuable for game and app development,
| maybe not multiplayer AAA, maybe practical apps.
|
| [1] https://github.com/glicol/glicol-cli
|
| [2] https://github.com/chaosprint/glicol
| netbioserror wrote:
| I use Nim at work. It is a joy. I replaced a prototype Rust
| application which was confirmedly _not_ a joy. None of Rust 's
| highly opinionated safety semantics necessarily imply a better
| end product, and often make delivering an end product much more
| difficult. Rust has use cases, but it is a specialized hammer for
| a specific domain of nails. It is not the cure-all everyone wants
| it to be.
|
| If you're asking if you should use Rust and you don't have a
| highly specific embedded use case, you should probably just use a
| language with decent RC or GC. As an additional bonus, 99.9% of
| the code you write in a GC language never has to be about memory
| _at all_. Business logic, clean and bare.
| Nuzzerino wrote:
| > As an additional bonus, 99.9% of the code you write in a GC
| language never has to be about memory at all.
|
| This is a bit of an oversimplification. If you are sloppy with
| "memory management" (unnecessary object lifetimes, unnecessary
| duplication, etc) even in a GC language, it is possible to have
| noticeable performance impacts. I'm not saying these languages
| aren't the right tool for the job, but it is not a free pass to
| ignore hardware limitations.
| netbioserror wrote:
| Yes, but that's only true for long-running applications. Most
| gigantic monolithic web server applications, for example, do
| not need to be gigantic monolithic web server applications.
|
| My Nim CLI application does a subset of common tasks, outputs
| to stdout, and is invoked by our PHP server for each task. It
| (and the Rust and C programs it replaced) can barely blip a
| fraction of a percent amount of system memory in the worst
| case. Why did it need to be in C or Rust? It was never
| necessary, and I've been able to load it with features they
| never had but always wanted, in astoundingly short order.
|
| Architecting these sorts of services properly can assist in
| making tool choices that drastically boost maintainability
| and feature delivery, especially for small teams; meanwhile,
| entire classes of problems melt away.
| Nuzzerino wrote:
| > Architecting these sorts of services properly can assist
| in making tool choices that drastically boost
| maintainability and feature delivery, especially for small
| teams
|
| I hate hearing this argument, because it glosses over the
| hard realities of building products, even if it sounds good
| on paper. Companies don't often have the resources to hire
| people that can do this early on, or the time to do this
| early on even if they do have the talent. And it might not
| be correct to do so when you have uncertain future
| requirements.
|
| If that talent is you, you might not even be trusted to
| make those kinds of decisions until a year or two of
| tenure. And you might have junior (or even 'senior') devs
| on the side making changes that make this harder to do,
| without anyone realizing it.
|
| So the reality is that you can't expect systems to be
| "architected properly" and you get what you get. It's an
| incremental process.
| dj_mc_merlin wrote:
| > Secondly, procedural macros are incredibly difficult to write,
| and most people end up using very heavy helper crates
|
| lisp lisp lisp lisp lisp lisp lisp lisp
| cshenton wrote:
| My experience is that the ecosystem is a mess, have hit winit,
| wgpu, and countless bevy bugs, iteration times are abysmal,
| documentation is nonexistent. In the time it would take me to
| make a game in popular Rust tooling I could build the game and
| engine from scratch in C and also have something that would crash
| less.
| alkonaut wrote:
| > wait I can't add this new thing because things will no longer
| compile, and there's no workaround other than code restructuring
|
| I definitely think that's a great feature. I want to learn on day
| 2 that the design is a dead end, not on day 101 when I ship on
| day 100 and there was a race condition on day 2 I never noticed.
|
| But the thing about gamedev (I guess - I'm not a game developer)
| is that the code being great and doing what you _hope_ it will do
| isn 't 100% of the job as it is in other disciplines. In gamedev
| you may want to _run_ the code, and the way it runs (fun, feel,
| whatever) might be bad even though it compiles, works according
| to a spec and so on. So while I 'm usually happy to write code
| for a week and never run it - game development feels like it's
| all about the iteration.
|
| That said, game development is also game _engine_ development.
| And Rust seems absolutely perfect for engine development (you
| need "fearless" concurrency and performance and there are zero
| mainstream languages that will do that other than rust). For
| people who feel it's too rigid or hard to iterate with perhaps
| hybrid could work. Like Rust + Lua or something sounds like it
| could be worth trying.
| taeric wrote:
| I think the point is that there are few "code related" dead
| ends in game code with good game play that can't be dealt with
| using enough effort. There are plenty of "game play related"
| dead ends that no amount of clean code can help out.
|
| To that end, whatever can help you explore the game play the
| fastest is what you want.
| alkonaut wrote:
| Quick iteration perhaps isn't the biggest strength of C++
| either. Rust does have some friction when it comes to "I'll
| try this with a dirty impl and if it flies, then I cam make a
| clean one later". I guess if that friction is worth it will
| depend on how much faster you get on other things, e.g.
| refactoring without spending a lot of effort worrying about
| introducing hard-to-spot bugs like races, or - worse - having
| to spend valuable time _fixing_ those bugs instead of adding
| fun to the game.
| taeric wrote:
| This is fair. Always curious to see why so much effort is
| used to move a game's codebase into a single language
| codebase. Seems far more useful to move the core of a
| game's engine to an interpreter loop and build on top of
| that, with all of the affordances one usually gets from
| that.
| taeric wrote:
| Oh my, this has to be my favorite quote in a blog in a long long
| time.
|
| "... many if not most of the problems don't go away if one isn't
| willing to constantly refactor their code and treat programming
| as a puzzle solving process, rather than just a tool to get
| things done."
|
| I have thought it was just me for a long time, but many of the
| popular styles of programming that we push definitely seem to
| require constant refactors in the pursuit of a solution. And I
| definitely see more tire spinning for the sake of the build than
| I do for whatever it was folks were building.
|
| Great quote.
| the_af wrote:
| It is a great quote!
|
| I think multiple refactors in pursuit of a solution can be a
| good thing. As your thinking/design evolves, so does the shape
| of the solution.
|
| The main problem, I think, is that this goes against
| _specifically_ gamedev. In gamedev whether the solution is the
| best or more resilient is secondary to extremely fast iteration
| and delivering _something_. Like the author says, sometimes
| "clunky but good enough for now" is what you need to get it
| over with (for the moment) an iterate rapidly over the gameplay
| elements you should spend most of your time on. Gameplay, not
| correctness or reliability or maintainability, is the most
| important thing in a game.
| scotty79 wrote:
| > because the thing you might need to do is not available in the
| place where you're doing the thing
|
| I noticed this with Rust. That sometimes Rust forces you to pull
| some things up the call stack in order to access them. Even if
| the semantics of what you do is the same Rust doesn't let you
| have things in arbitrary places.
|
| It's super weird and possibly annoying when you hit it for the
| first time but if you stop and think about it, the place where
| Rust forces you to put it is a really good place from
| architectural standpoint.
|
| It basically prevents you from taking parts of a thing and
| delegating responsibility for them to some children, which seems
| restrictive, but it provides you with consistent structure of
| where to look for things that are responsible for something.
|
| Rust is restrictive in so many subtle ways (and some obvious
| ones) but I haven't seen one where it leads to worse outcomes.
| Maybe I have too little experience.
| Sleaker wrote:
| Great article, but on ECS I thought the primary point of using it
| was locality of memory so that you don't get cache misses during
| iteration of elements. Yes you are preferring composition over
| inheritance but I thought that was more of a side-benefit to the
| main thing ECS was trying to solve.
| qaq wrote:
| Wonder if Mojo will become a good option as it matures
| logicprog wrote:
| I only skimmed this article, but, despite it being very negative
| about Rust, I almost 100% _agree with it_ : Rust is a HORRIBLE
| choice for game dev.
|
| I know, because I've tried it. Once. I would #never* recommend
| Rust to game developers, especially not indie ones. In fact I'd
| recommend against it strenuously!
|
| And this is precisely because Rust is explicitly and knowingly
| focused on correctness, safety, perfectly clean code, etc at the
| cost of iteration speed and flexibility and dynamicism, and
| that's bad for designing game mechanics and even just _getting a
| game done_ -- games have an inherently short life span and
| development cycle, so safety and correctness and code quality don
| 't matter a whole lot. It's okay if they crash, etc, as long as
| they work enough to play. It's okay if the code is ugly, you
| probably won't be working on it for very long. This is even
| moreso the case, as the author says, because in writing a game
| you really want to be able to iterate quickly and just. Do shit
| as an experiment, even if it's temporary, to see how it feels.
|
| On the other hand, who I _would_ recommend Rust to is the people
| writing game _engines_ , where you really will probably be
| working on that code for years to come, where stability and
| correctness is pretty important, and so where Rust's strengths
| will really shine -- but crucially, even then, I'd tell them to
| make it a real engine, not a game framework like Bevy, by adding
| a highly flexible, dynamic scripting language like Lua or even
| C#, and a data format for specifying scenes and entities, and an
| editor. That way you don't write your game in Rust at all!
| golergka wrote:
| I've been working in gamedev since 2007 and toyed with Rust since
| 2014. I simply don't think that majority of games, especially
| indie games, have performance requirements high enough to justify
| using anything other than a high-level, garbage collected
| language.
|
| Of course, some titles like Factorio are outliers. But for
| majority of games time you would spend to work with manual memory
| management in C or borrow checker in Rust would better be spent
| on other things.
| bittwiddle wrote:
| I've found Rust very pleasant for building little games. I've
| mostly been using SDL + a my own little shim so I can target web
| through wasm & canvas.
|
| I had professionally worked with C++ for a long time so getting
| comfortable with Rust wasn't too bad.
|
| https://www.bittwiddlegames.com/ You can see a web build at
| https://www.bittwiddlegames.com/lambda-spellcrafting-academy...
| pornel wrote:
| I think these comments are fair. It's true that Rust is _rigid_.
|
| I've had great success with Rust, but on projects where I knew
| exactly what I needed to build. Rust's focus on code correctness
| is great for maintenance of projects, where the priority is in
| keeping them stable and not causing regressions.
|
| So while I'd say Rust is pretty quick for refactoring of
| something like a device driver, it's far away from the hot-
| reloaded time traveling live tinkering IDE.
| thefaux wrote:
| My favorite thing about rust is when rust devs say that the slow
| compile things aren't a big deal and then show how that just by
| dropping a few dependencies you can get hello world down from 90
| seconds to 30 seconds.
| 0xfedbee wrote:
| Rust is a terrible language for everything except a few niche
| tools.
| james4k wrote:
| I've been leaning into Rust almost purely to escape from the mess
| that is C/C++ tooling which always makes considering a new
| dependency a time sink.
|
| Can someone explain the obsession with combining ECS with
| generational arenas?
| epolanski wrote:
| You can feel the paranoia of the author stating 20000 times it's
| his opinion, giving context, etc just cause he knows the
| langstans reaction.
| eftychis wrote:
| I respectfully disagree with the author's title choice.
|
| My first impression is, of course, that the issue is there is no
| production Game or GUI framework around.
|
| The author seems to complain mainly about the choices of
| frameworks and how bad or opinionated they are. I agree. Even
| Egui is too opinionated, but it makes sense on some level.
|
| It is no problem to use bindings to some software written in C++.
| Rust was created to solve this exact problem: rewrite big
| projects that were written in C++, by slow mutation in Rust.
|
| Honestly, I would add further that until the Unreal Engine uses
| Rust, we should not expect widespread Rust adoption. It will
| likely start with a company creating its own really custom game
| engine, the game becoming a bestseller, and it will spread
| iteratively over the years from there. Or maybe there will be a
| better option beyond Rust at that point.
|
| This is the status quo:
| https://www.youtube.com/shorts/_zwKHgtQpc8 Let us be realistic.
|
| Beyond that: One should see Rust as writing C with someone
| watching over you to remind you that you need to know the writer
| for each memory value. It picks up work off you. Or it should. If
| it doesn't, yes that is a problem, and we/you are doing it wrong.
|
| But yes, if you are doing something that the borrow checker
| complains about, in other languages, either that semantic
| difference would have been hidden, or you would be paying for it
| later.
|
| There, the author makes a point that he wants the code to work
| now. That is possible, and you can hotwire bad code in Rust, too.
| But I am sure that code is why we end up with games like Jedi
| Survivor.
|
| There is no fundamental inability of Rust to do the things the
| author demands. If you want dynamic loading, use
| https://crates.io/crates/libloading (And you don't need to use
| the library). Do you want a global state? I will disagree with
| you, but take a look at, e.g., how the Dioxus project is doing
| it. Again I think that is always a terrible mistake, and people
| are thinking really of using an arena or a registry really.
| mgaunard wrote:
| Rust is not a practical language and fails at many of the things
| that were part of its original vision.
|
| The main point of Rust is to have an excuse to rewrite things
| from scratch unhindered by legacy, but that won't particularly
| improve their quality.
|
| I suppose you could also make some friends as part of joining the
| cult.
___________________________________________________________________
(page generated 2024-04-26 23:00 UTC)