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

631–640 of 799 posts

Re: Migrating away from Rust

#631

Post by gthompson512 »

chubot wrote: post #563
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

So in D, is it now natural to mix borrow checking and garbage collection? I think some kind of "gradual memory management" is the holy grail, but like gradual typing, there are technical problems The issue is the boundary between the 2 styles/idioms -- e.g. between typed code and untyped code, you have either expensive runtime checks, or you have unsoundness --- So I wonder if these styles of D are more like separate…

> So in D, is it now natural to mix borrow checking and garbage collection?

I think "natural" is a bit loaded, there is native support in the frontend for doing both. You have to go out of your way to annotate functions with @live and it is still experimental(https://dlang.org/spec/ob.html). The garbage collection is natural and happens if you do nothing, but you can turn it off with proper annotations like @nogc(https://dlang.org/spec/function.html#nogc-functions) or using betterC(https://dlang.org/spec/betterc.html). There is also @safe, @system and @trusted(https://dlang.org/spec/memory-safe-d.html).

So natural is a stretch at the moment, but you can use all kinds of different techniques, what is needed is more community and library standardization around some solutions.

Re: Migrating away from Rust

#632

Post by mabster »

pjmlp wrote: post #570
mabster wrote: post #544

Earlier quoted context omitted.

I think the choice of C++ vs JVM depends on your project. If you're not using the benefits of "unsafe" languages then it probably doesn't matter. But if you are after performance how do do the following in Java? - Build an AOS so that memory access is linear re cache. Prefetch. Use things like _mm_stream_ps() to tell the CPU the cache line you're writing to doesn't need to be fetched. Share a buffer of memory between…

While there are many technical reasons to use C++ over Java in game development, many commercial games could be easily done in Java, as they are A or AA level at most. Had Notch thought too much about which language to use, maybe he would still be trying to launch a game today.

Minecraft was Indie then. And anyway, it's now in C++.

Re: Migrating away from Rust

#633

Post by stefanka »

N_Lens wrote: post #568
stefanka wrote: post #528

Earlier quoted context omitted.

It is indeed great for creating a prototype. After that, one can gradually migrate to Rust go benefit from faster execution times. The Rust bindings are in a pretty decent shape by now https://godot-rust.github.io/

Nowadays we have the luxury of LLMs to help migrate projects/code from one language to another. I would imagine a pipeline with Rust as an intermediate “compiled” step might be possible. LLM accuracy isn’t there yet, but I can dream.

It is not that complicated or time-consuming to do the transformation manually. On the contrary, it's even fun and a good practice (but admittedly, I do have a rather conservative view on the matter)

Re: Migrating away from Rust

#634

Post by klabb3 »

cyclotron3k wrote: post #583
klabb3 wrote: post #204

The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead. Conversely and…

Can you speak more of this best in class tooling?

The official `go` command does dep management, (cross) compilation, testing (including benchmarks and coverage reports), race detection, profiling reports, code generation (metaprogramming alternative), doc generation etc. Build times are insanely fast too.

The only tooling I use personally outside of the main CLI is building iOS/Android static libraries (gomobile). It’s still first party, but not in the go command.

Re: Migrating away from Rust

#635

Post by mtndew4brkfst »

pjmlp wrote: post #579
mtndew4brkfst wrote: post #385

Earlier quoted context omitted.

For me personally, doing the clone-everything style of Rust for a first pass means I still have a graceful incremental path to go pursue the harder optimizations that are possible with more thoughtful memory management. The distinction is that I can do this optimization pass continuing to work in Rust rather than considering, and probably discarding, a potential rewrite to a net-new language if I had started in somet…

Yeah only in Scala, Kotlin, F#, Standard ML, OCaml, Haskell, and all others that derive from them.

None of those are to my personal taste and I think Kotlin is the only one with unambiguously strong adoption in industry. I'm trying not to make value-judgment statements about others that do like them.

Re: Migrating away from Rust

#636

Post by busfahrer »

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…

> 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 informally specified, ad hoc and bug-ridden game engine called "Unity")

For the 4 people on HN not aware of it, this is a riff on Greenspun's tenth rule:

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Re: Migrating away from Rust

#637

Post by imtringued »

spullara wrote: post #229
doctorpangloss wrote: post #136

Earlier quoted context omitted.

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.

I would bet that if you want to build a game engine and not the game, the game itself is probably not that compelling. Could still break out, like Minecraft, but if someone has an amazing game idea I would think they would want to ship it as fast as possible.

This is correct. If you want to build a game engine, you better know what kind of game it is by making at least a playable prototype in a conventional engine.

Re: Migrating away from Rust

#638

Post by mtndew4brkfst »

palata wrote: post #530
mtndew4brkfst wrote: post #385

Earlier quoted context omitted.

For me personally, doing the clone-everything style of Rust for a first pass means I still have a graceful incremental path to go pursue the harder optimizations that are possible with more thoughtful memory management. The distinction is that I can do this optimization pass continuing to work in Rust rather than considering, and probably discarding, a potential rewrite to a net-new language if I had started in somet…

> generics, macros, sum types, pattern matching, Result/Option types. Many of these can't be found all together in a single managed/GC'd languages What about e.g. Kotlin or Swift?

I don't find the single-vendor governance / commercial origins of those two languages very reassuring, but that's not something that will trouble everyone equally if at all.

Re: Migrating away from Rust

#639

Post by pjmlp »

mabster wrote: post #632
pjmlp wrote: post #570

Earlier quoted context omitted.

While there are many technical reasons to use C++ over Java in game development, many commercial games could be easily done in Java, as they are A or AA level at most. Had Notch thought too much about which language to use, maybe he would still be trying to launch a game today.

Minecraft was Indie then. And anyway, it's now in C++.

Many people dream to make it as indie, most don't even achieve that.

No it isn't, there are now two versions of Minecraft, the classical one, and Minecraft Bedrock, that is the one written in C++.

Minecraft Bedrock doesn't have half of the community that Minecraft classical enjoys, hence why Microsoft is trying to use JavaScript based extensions to bring the mod community into Minecraft Bedrock.

Finally without Minecraft classical market success, there wouldn't exist Minecraft Bedrock at all, so Java did serve well enough to Notch's fortunes.

Re: Migrating away from Rust

#640

Post by tlxio »

mamcx wrote: post #214

This can be summarized in a simple way: UI is totally, another world. There is not chance for any language, not matter how good is it, to match the most horrendous (web!) but full-featured ui toolkit. I bet, 1000%, that is easier to do a OS, a database engine, etc that try to match QT, Delphi, Unity, etc. --- I made a decision that has become the most productive and problem-less approach of make UIs in my 30 years do…

Would you happen to have (sample) or open-source Rust code out there demonstrating this approach? I'm very curious to learn more.

For example; if you have a progressbar that needs to be updated continuously, you do what? Upon every `tick` of your Rust engine you send a new struct with `ProgressBar(percentage=x)`? Or do the structs have unique identifiers so that the UI code can just update that one element and its properties instead of re-rendering the entire screen?

Post reply on HN