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

561–570 of 799 posts

Re: Migrating away from Rust

#561

Post by pjmlp »

lolinder wrote: post #539
jamessinghal wrote: post #484

Earlier quoted context omitted.

Yes but it would just be the hot loop in this case; the rest of the app can still be in idiomatic Java, and you still get the GC.

Exactly. Write it in Java, optimize what you need to, leave the rest alone.

As polyglot dev, I never understood this religious approach that it has to be 100% pure unadulterated in language XYZ for performance.

Nope, embrace the productivity of managed languages, if really needed, package that rest in a native library, done.

Re: Migrating away from Rust

#562

Post by wolvesechoes »

ogoffart wrote: post #465
the__alchemist wrote: post #403

Earlier quoted context omitted.

Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit! I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

If you're looking for a stable GUI toolkit, there is Slint

Unless you would like to have a tree view widget.

Re: Migrating away from Rust

#563

Post by chubot »

WalterBright wrote: post #470
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

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 languages for different programs? Or are they integrated somehow?

Compared with GC, borrow checking affects every function signature

Compared with manual memory management, GC also affects every function signature.

IIRC the boundary between the standard library and programs was an issue -- i.e. does your stdlib use GC, and does your program use GC? There are 4 different combinations there

The problem is that GC is a global algorithm, i.e. heap integrity is a global property of a program, not a local one.

Likewise, type safety is a global property of a program

---

(good discussion of what programs are good for the borrow checking style -- stateless straight-line code seems to benefit most -- https://news.ycombinator.com/item?id=34410187)

Re: Migrating away from Rust

#564

Post by palata »

mabster wrote: post #544
palata wrote: post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

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…

> but there is a reason that commercial gamedev is typically C++.

Sure, and that's kind of my point. There are a few use-cases where C++ is actually needed, and for those cases, Rust (the language) is a good alternative if it's possible to use it.

But even for gamedev, the article here says that they moved to Unity. The core of Unity is apparently C++, but users of Unity code in C#. Which kind of proves my point: outside of that core that actually needs C++, it doesn't matter much. And the vast majority of software development is done outside of those core use-cases, meaning that the vast majority of developers do not need Rust.

Re: Migrating away from Rust

#565

Post by davedx »

Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

One thing that struck me was the lavish praise heaped on the ECS of the game engine being migrated away from; this is extremely common.

I think when it comes to game dev, people fixate on the engine having an ECS and maybe don't pay enough attention to the other aspects of it being good for gamedev, like... being a very high level language that lets you express all the game logic (C# with coroutines is great at this, and remains a core strength of Unity; Lua is great at this; Rust is ... a low level systems language, lol).

People need to realise that having ECS architecture isn't the only thing you need to build games effectively. It's a nice way to work with your data but it's not the be-all and end-all.

Re: Migrating away from Rust

#566

Post by palata »

tonyedgecombe wrote: post #487
vips7L wrote: post #368

Earlier quoted context omitted.

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.

Does Java have sum types now?

I think Java 21 does. Scala and Kotlin do as well.

Re: Migrating away from Rust

#567

Post by mrweasel »

CharlieDigital wrote: post #18
byearthithatius wrote: post #3

Love to have this comparison analysis. Huge LOC difference between Rust and C# (64k -> 17k!!!) though I am sure that is mostly access to additional external libraries that did things they wrote by hand in Rust.

C# is a very highly underrated (and oft misunderstood) language that has become more terse as it has aged -- in a very good way. C#'s terseness has not come at the cost of its legibility and in fact, I feel like enhances it in many cases. > The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. This is also a highly un…

> C# is a very highly underrated (and oft misunderstood) language that has become more terse as it has aged -- in a very good way

One negative aspect is that if you haven't kept up, that terseness can be a bit of a brick wall. Many of the newer features, especially things where the .Net framework just takes over and solves your problem for you in a "convention over configuration" kinda way, are extremely terse. Modern C# can have a bit of a learning curve.

C# is an underrate language for sure and once you get going it is an absolute joy to work in. The .Net platform also gives you all the cross-platform and ease of deployment features of languages like Go. Ignoring C#/.Net because it's Microsoft is a bit of a mistake.

Re: Migrating away from Rust

#568

Post by N_Lens »

stefanka wrote: post #528
__loam wrote: post #73

Earlier quoted context omitted.

I used to hate the language but statically typed GDscript feels like the perfect weight for indie development

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.

Re: Migrating away from Rust

#569

Post by mrweasel »

dicytea wrote: post #174
CharlieDigital wrote: post #138

Earlier quoted context omitted.

> People tend to be influenced by opinions online but often the real world is completely different. Unfortunately, my experience has been that C#'s lack of popularity online translates into a lot of misunderstandings about the language and thus many teams simply do not consider it. Some folks still think it's Windows-only. Some folks think you need to use Visual Studio. Some think it's too hard to learn. Lots of misc…

> Some folks think you need to use Visual Studio How's the LSP support nowadays? I remember reading a lot of complaints about how badly done the LSP is compared to Visual Studio.

I still think Visual Studio is better, but you can easily work on small to mid-size projects in VSCode. Could you use Vim? I probably wouldn't, but you can say the same for Java.

Re: Migrating away from Rust

#570

Post by pjmlp »

mabster wrote: post #544
palata wrote: post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

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.

Post reply on HN