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

361–370 of 799 posts

Re: Migrating away from Rust

#361

Post by aquariusDue »

echelon wrote: post #298
palata wrote: post #262

Earlier quoted context omitted.

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.

Perhaps. But a comparable Rust backend stack produces a single binary deployable that can absorb 50,000 QPS with no latency caused by garbage collection. You get all of that for free. The type system and package manager are a delight, and writing with sum types results in code that is measurably more defect free than languages with nulls.

Yep, that's precisely it! When dealing with other languages I miss the "match" keyword and being able to open a block anywhere. Sure, sometimes Rust allows you to write terse abominations if you don't exercise a dose of caution and empathy for future maintainers (you included).

Other than the great developer experience in tooling and language ergonomics (as in coherent features not necessarily ease of use) the reason I continue to put up with the difficulties of Rust's borrow checker is because I feel I can work towards mastering one language and then write code across multiple domains AND at the end I'll have an easy way to share it, no Docker and friends needed.

But I don't shy away from the downsides. Rust loads the cognitive burden at the ends. Hard as hell in the beginning when learning it and most people (me included) bounce from it for the first few times unless they have C++ experience (from what I can tell). At the middle it's a joy even when writing "throwaway" code with .expect("Lol oops!") and friends. But when you get to the complex stuff it becomes incredibly hard again because Rust forces you to either rethink your design to fit the borrow checker rules or deal with unsafe code blocks which seem to have their own flavor of C++ like eldritch horrors.

Anyway, would *I* recommend Rust to everyone? Nah, Go is a better proposition for a most bang for your buck language, tooling and ecosystem UNLESS you're the kind that likes to deal with complexity for the fulfilled promise of one language for almost anything. In even simpler terms Go is good for most things, Rust can be used for everything.

Also stuff like Maud and Minijinja for Rust are delights on the backend when making old fashioned MPA.

Thanks for coming to my TED talk.

Re: Migrating away from Rust

#362

Post by vips7L »

bluGill wrote: post #248
peterashford wrote: post #225

Earlier quoted context omitted.

You think the JVM is slow?

Depends. JVM is fast once hotspot figures things out - but that means the first level is slow and you lose your users.

You can always load JIT caches if you can’t wait for warm up.

Re: Migrating away from Rust

#364

Post by zxvkhkxvdvbdxz »

klabb3 wrote: post #325
bmitc wrote: post #213

Earlier quoted context omitted.

I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.

Huh? Usually languages that are ”ignored” turns out to be for reasons such as poor or proprietary tooling. As an ignorant bystander, how are things like Cross compilation, package manager and associated infrastructure, async io (epoll, io_uring etc), platform support, runtime requirements, FFI support, language server, etc. Are a majority of these things available with first party (or best in class) integrated toolin…

F# compiler is cross os and allows cross compilation (dotnet build --runtime xxx), its packaged in most Linux distros as dotnet.

Re: Migrating away from Rust

#365

Post by trealira »

loeg wrote: post #216
yyyk wrote: post #56

GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while its complexity remains. No surprise he prefers C# for this.

Not just GC -- performance in general is a total non-issue for a 2d tile-based game. You just don't need the low-level control that Rust or C++ gives you.

I wouldn't say it's a non-issue. I've played 2D tile-based, pixel art games where the framerate dropped noticeably with too many sprites on screen, even though it felt like a 3DS should have been able to run it, and my computer isn't super low-end, either. You have more leeway, but it's possible to badly make optimized 2D games to the point where performance becomes an issue again.

Re: Migrating away from Rust

#366

Post by jokethrowaway »

Congrats on the rewrite!

I think the worst issue was the lack of ready-made solution. Those 67k lines in Rust contains a good chunk of a game engine.

The second worst issue was that you targeted an unstable framework - I would have focused on a single version and shipped the entire game with it, no matter how good the goodies in the new version.

I know it's likely the last thing you want to do, but you might be in a great position to improve Bevy. I understand open sourcing it comes with IP challenges, but it would be good to find a champion with read access within Bevy to parse your code and come up with OSS packages (cleaned up with any specific game logic) based on the countless problems you must have solved in those extra 50k lines.

Re: Migrating away from Rust

#367

Post by fc417fc802 »

jimbokun wrote: post #206
zaptheimpaler wrote: post #181

Earlier quoted context omitted.

Yeah this is my absolute dream language. Something that lets you prototype as easily as Python but then compile as efficiently and safely as Rust. I thought Rust might actually fit the bill here and it is quite good but it's still far from easy to prototype in - lots of sharp edges with say modifying arrays while iterating, complex types, concurrency. Maybe Rust can be something like this with enough unsafe but I hav…

Some Common Lisp implementations like SBCL have supported this style of development for many years. Everything is dynamically typed by default but as you specify more and more types the compiler uses them to make the generated code more efficient.

I quite like common lisp but I don't believe any existing implementation gets you anywhere near the same level of compile time safety. Maybe something like typed racket but that's still only doing a fraction of what rust does.

Re: Migrating away from Rust

#368

Post by vips7L »

aquariusDue wrote: post #361
echelon wrote: post #298

Earlier quoted context omitted.

Perhaps. But a comparable Rust backend stack produces a single binary deployable that can absorb 50,000 QPS with no latency caused by garbage collection. You get all of that for free. The type system and package manager are a delight, and writing with sum types results in code that is measurably more defect free than languages with nulls.

Yep, that's precisely it! When dealing with other languages I miss the "match" keyword and being able to open a block anywhere. Sure, sometimes Rust allows you to write terse abominations if you don't exercise a dose of caution and empathy for future maintainers (you included). Other than the great developer experience in tooling and language ergonomics (as in coherent features not necessarily ease of use) the reason…

What language are you using that doesn’t have match? Even Java has the equivalent. The only ones I can think of that don’t are the scripting languages.. Python and JS.

Re: Migrating away from Rust

#369

Post by mawww »

haberman wrote: post #328
jandrewrogers wrote: post #295

Earlier quoted context omitted.

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

> 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…

C and C++ do have very different memory models, C essentially follows the "types are a way to decode memory" model while C++ has an actual object model where accessing memory using the wrong type is UB and objects have actual lifetimes. Not that this would necessarily lead to performance differences.

When people claim C++ to be faster than C, that is usually understood as C++ provides tools that makes writing fast code easier than C, not that the fastest possible implementation in C++ is faster than the fastest possible implementation in C, which is trivially false as in both cases the fastest possible implementation is the same unmaintainable soup of inline assembly.

The typical example used to claim C++ is faster than C is sorting, where C due to its lack of templates and overloading needs `qsort` to work with void pointers and a pointer to function, making it very hard on the optimiser, when C++'s `std::sort` gets the actual types it works on and can directly inline the comparator, making the optimiser work easier.

Re: Migrating away from Rust

#370

Post by trealira »

Rohansi wrote: post #363
DarkmSparks wrote: post #350

The best language for game logic is lua, switching to C# probably isnt going to help any.... IMHO.

What makes Lua the best for game logic? You don't even have types to help you out with Lua.

Yeah, I actually recently tried making a game in Lua using LOVE2D, and then making the same one in C with Raylib, and I didn't feel like Lua itself gave me all that much. I don't think Lua is best for game logic so much as it's the easiest language to embed in a game written in C or C++. That said, maybe some of its unique features, like its coroutines, or stuff relating to metatables, could be useful in defining game logic. I was writing very boring, procedural, occasionally somewhat object-oriented code either way.
Post reply on HN