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

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

501–510 of 799 posts

Re: Migrating away from Rust

#501

Post by yyyk »

neonsunset wrote: post #473
yyyk wrote: post #452

Earlier quoted context omitted.

>if you are a C# developer, honestly you don't care about low level code, or not having a garbage collector. You can go low level in C#**, just like Rust can avoid the borrow checker. It's just not a good tradeoff for most code in most games. ** value types/unsafe/pointers/stackalloc etc.

Structs in C# or F# are not low-level per se, they simply are a choice and used frequently in gamedev. So is stackalloc because using it is just 'var things = (stackalloc Thing[5])' where the type of `things` is Span . The keyword is a bit niche but it's very normal to see it in code that cares about avoiding allocations. Note that going more hands-on with these is not the same as violating memory safety - C# even ha…

Right, it depends on how far one wants to go to avoid allocations. structs and spans are safe. But one can go even deeper and pin pointers and do Unsafe.AsPointer and get a de-facto (unsafe) union out of it....

>https://em-tg.github.io/csborrow/

Oooh... I didn't know scoped refs existed.

Re: Migrating away from Rust

#502

Post by monkeyelite »

pornel wrote: post #413
fooker wrote: post #48

Earlier quoted context omitted.

Memory is sometimes faster today!

In absolute terms yes, but relative to the CPU speed memory is ridiculously slow. Quake struggled with the number of objects even in its days. What you've got in the game was already close to the maximum it could handle. Explosions spawning giblets could make it slow down to a crawl, and hit limits of the client server protocol. The hardware got faster, but users' expectations have increased too. Quake 1 updated the…

> Quake struggled with the number of objects even in its days.

Because of memory bandwidth of Iterating the entities? No way. Every other part - rendering, culling, network updates, etc is far worse.

Let’s restate. In 1998 this got you 1024 entities at 60 FPS. The entire array could no fit in L2 cache of a modern desktop.

And I already advised a simple change to improve memory layout.

> Quake 1 updated the world state at 10 ticks per secondo

That’s not a constraint in Quake 3 - which has the same architecture. So it’s not relevant.

> users' expectations have increased too

Your game is more complex than quake 3? In what regard?

Re: Migrating away from Rust

#503

Post by haberman »

jandrewrogers wrote: post #409
haberman wrote: post #328

Earlier quoted context omitted.

> C++ has been faster than C for a long time. What is your basis for this claim? C and C++ are both built on essentially the same memory and execution model. There is a significant set of programs that are valid C and C++ both -- surely you're not suggesting that merely compiling them as C++ will make them faster? There's basically no performance technique available in C++ that is not also available in C. I don't thi…

This is really an “in theory” versus “in practice” argument. Yes, you can write most things in modern C++ in roughly equivalent C with enough code, complexity, and effort. However, the disparate economics are so lopsided that almost no one ever writes the equivalent C in complex systems. At some point, the development cost is too high due to the limitations of the expressiveness and abstractions. Everyone has a finit…

None of this really supports your claim that "C++ has been faster than C for a long time."

You can argue that C takes more effort to write, but if you write equivalent programs in both (ie. that use comparable data structures and algorithms) they are going to have comparable performance.

In practice, many best-in-class projects are written in C (Lua, LuaJIT, SQLite, LMDB). To be fair, most of these projects inhabit a design space where it's worth spending years or decades refining the implementation, but the combination of performance and code size you can get from these C projects is something that few C++ projects I have seen can match.

For code size in particular, the use of templates makes typical C++ code many times larger than equivalent C. While a careful C++ programmer could avoid this (ie. by making templated types fall back to type-generic algorithms to save on code size), few programmers actually do this, and in practice you end up with N copies of std::vector, std::map, etc. in your program (even the slow fallback paths that get little benefit from type specialization).

Re: Migrating away from Rust

#504

Post by pjmlp »

josephg wrote: post #430
_bin_ wrote: post #297

Earlier quoted context omitted.

I saw a good talk, though I don't remember the name, that went over the array-index approach. It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide.

> It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

GC languages like C# don't need these tricks, because it is feature rich enough to do C++ style low level programming, and has value types.

Re: Migrating away from Rust

#505

Post by whstl »

christophilus wrote: post #332
janalsncm wrote: post #280

Earlier quoted context omitted.

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use. I’ve got a number of vanilla Bun projects that only depend on TypeScript (and that is only a dev dependency). It’s not always possible to be so minimal, but I view every dependency as lugging around a huge lurking liability, so the benefit it brings had better far outweigh that big liability. So far, I’ve only had one painful…

I'm finding most of the modern React ecosystem to be made of liabilities.

The constant update cycles of some libraries (hello Router) is problematic in itself, but there's too many fashionable things that sound very good in theory but end up being a huge problem when used in fast-moving projects, like headless UI libraries.

Re: Migrating away from Rust

#506

Post by mwcampbell »

tptacek wrote: post #440
mwcampbell wrote: post #399

Earlier quoted context omitted.

> Why would I valorize discarding this kind of automation? Is this just a craft vs. production thing? The strongest reason I can think of to discard this kind of automation, and do so proudly, is that it's effectively plagiarizing from all of the experts whose code was used in the training data set without their permission.

No plausible advance in nanotechnology could produce a violin small enough to capture how badly I feel about out professional being "plagiarized" after decades of rationalizing about the importance of Star Wars to the culture justifying movie piracy. Artists can come at me with this concern all they want, and I feel bad for them. No software developer can. I disagree with you about the "plagiaristic" aspect of LLM co…

I'm not making an argument from grievance about my own code being plagiarized. I actually don't care if my own code is used without even the attribution required by the permissive licenses it's released under; I just want it to be used. I do also write proprietary code, but that's not in the training datasets, as far as I know. But the training datasets do include code under a variety of open-source licenses, both permissive and copyleft, and some of those developers do care how their code is used. We should respect that.

As for our tendency to disrespect the copyrights of art, clearly we've always been in the wrong about this, and we should respect the rights of artists. The fact that we've been in the wrong about this doesn't mean we should redouble the offense by also plagiarizing from other programmers.

And there is evidence that LLMs do plagiarize when generating code. I'll just list the most relevant citations from Baldur Bjarnason's book _The Intelligence Illusion_ (https://illusion.baldurbjarnason.com/), without quoting from that copyrighted work.

https://arxiv.org/abs/2202.07646

https://dl.acm.org/doi/10.1145/3447548.3467198

https://papers.nips.cc/paper/2020/hash/1e14bfe2714193e7af5ab...

Re: Migrating away from Rust

#507

Post by im3w1l »

rcxdude wrote: post #301
legobmw99 wrote: post #44

Earlier quoted context omitted.

I mean, we already have a sort-of answer, because the "Bedrock Edition" of Minecraft is written in C++, and it is indeed less popular on PC (on console, it's the only option, so _overall_ it might win out) and does lack any real modding scene

Indeed. Java is sufficiently dynamic/decompilable a game written in it can be heavily modded without adding specific support. C++ is much harder (depending on the game engine), though not impossible. If you do add modding support then everything is much better regardless of language, though (see Factorio, written in C++ and with a huge modding scene, because it was basically written with modding in mind. Lua is certa…

I actually disagree with that. Decompilation based mods can completely change anything and everything about the game. Scripting based mods can only change things within the boundaries allowed by the devs of the original game.

Re: Migrating away from Rust

#508

Post by goku12 »

palata wrote: post #262
echelon wrote: post #223

Earlier quoted context omitted.

Rust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.

To me, web dev really sounds like the one place where everything works and it's more a question of what is in fashion. Java, Ruby, Python, PHP, C, C++, Go, Rust, Scala, Kotlin, probably even Swift? And of course NodeJS was made for that, right? I am absolutely convinced I can find success story of web backends built with all those languages.

There are 3 cases. The first is that you are comfortable with Rust and you just choose it for that. The second is that you're not comfortable with Rust and you choose something else that works for you.

The third is the interesting one. When your service has a lot of traffic and every bit of inefficiency costs you money (node rents) and energy. Rust is an obvious improvement over the interpreted languages. There are also a few rare cases where Rust has enough advantages over Go to choose the former. In general though, I feel that a lot of energy consumption and emissions can be avoided by choosing an appropriate language like Rust and Go.

This would be a strong argument in favor of these languages in the current environmental conditions, if it weren't for 'AI'. Whether it be to train them or run them, they guzzle energy even for problems that could be solved with a search engine. I agree that LLMs can do much more. But I don't think they do enough for the energy they consume.

Re: Migrating away from Rust

#509

Post by izacus »

WD-42 wrote: post #250
VWWHFSfQ wrote: post #226

Earlier quoted context omitted.

Rust is very easy when you want to do easy things. You can actually just completely avoid the borrow-checker altogether if you want to. Just .clone(), or Arc/Mutex. It's what all the other languages (like Go or Java) are doing anyway. But if you want to do a difficult and complicated thing, then Rust is going to raise the guard rails. Your program won't even compile if it's unsafe. It won't let you make a buggy app.…

This argument goes only so far. Would you consider querying a database hard? Most developers would say no. But it’s actually a pretty hard problem, if you want to do it safely. In rust, that difficultly leaks into the crates. I have a project that uses diesel and to make even a single composable query is a tangle of uppercase Type soup. This just isn’t a problem in other languages I’ve used, which granted aren’t as s…

> This just isn’t a problem in other languages I’ve used, which granted aren’t as safe.

Most languages used with DBs are just as safe. This idea about Rust being more safe than languages with GC needs a rather big [Citation Needed] sign for the fans.

Re: Migrating away from Rust

#510

Post by xandrius »

doctorpangloss wrote: post #136
12_throw_away wrote: post #110

More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the inf…

And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.

Making an actual indie game can take from 6 months (tiny) to 4-5years. If you multiply that by 10x, the upper bound would be 40-50 years. Of course, that's not how it would be but one has to consider whether their goal is to build a game engine OR a game, doing both at the same is almost guaranteed failure (statistically speaking).
Post reply on HN