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

101–110 of 799 posts

Re: Migrating away from Rust

#101

Post by Ygg2 »

bigstrat2003 wrote: post #84
Ygg2 wrote: post #64

Earlier quoted context omitted.

> Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects Yes. Because it makes a promise about backwards compatibility. > Rust language and library features themselves often spend years in nightly before making it to a release build. So did Java's. And I Rust probably has a fraction of its budget. In defense of long nightly feature more than on…

> And split the community and double your maintenance burden. If you choose to support 1.0 sure. But you don't have to. Overall I find that the Rust community is way too leery of going to 1.0. It doesn't have to be as big a burden as they make it out to be, that is something that comes down to how you handle it.

> If you choose to support 1.0 sure.

If you choose not to, then people wait for x.0 where x approaches infinity. I.e. they lose confidence in your crates/modules/libraries.

I mean, a big part of why I don't 1.x my OSS projects (not just Rust) is that I don't consider them finished yet.

Re: Migrating away from Rust

#102

Post by shadowgovt »

Excellent write-up.

On the topic of rapid prototyping: most successful game engines I'm aware of hit this issue eventually. They eventually solve it by dividing into infrastructure (implemented in your low-level lanuage) and game-logic / application logic / scripting (implemented in something far more flexible and, usually, interpreted; I've seen Lua used for this, Python, JavaScript, and I think Unity's C# also fits this category?).

For any engine that would have used C++ instead, I can't think of a good reason to not use Rust, but most games with an engine aren't written in 100% C++.

Re: Migrating away from Rust

#103

Post by wottuh »

ninjis wrote: post #79

The "Learning" point drives home a concern my brother-in-law and I were talking about recently. As LLMs become more entrenched as a tool, they may inevitably become the crutch that actually holds back innovation. Individuals and teams may be hesitant to explore or adopt bleeding edge technologies specifically because LLMs don't know about them or don't know enough about them yet.

[dead]

Re: Migrating away from Rust

#104

Post by bsaul »

shmerl wrote: post #63

Using poor quality AI suggestions as a reason not to use Rust is a super weird argument. Something is very wrong with such idea. What's going to be next, avoiding everything where AI performs poorly? Scripting being flexible is a proper idea, but that's not an argument against Rust either. Rather it's an argument for more separation between scripting machinery and the core engine. For example Godot allows using Rust…

it could be a weird argument, but as a rust newcomer, i have to say it's really something that jumps to your face. LLMs are practically useless for anything non-basic, and rust contains a lot non-basic things.

Re: Migrating away from Rust

#105

Post by minimaxir »

ninjis wrote: post #79

The "Learning" point drives home a concern my brother-in-law and I were talking about recently. As LLMs become more entrenched as a tool, they may inevitably become the crutch that actually holds back innovation. Individuals and teams may be hesitant to explore or adopt bleeding edge technologies specifically because LLMs don't know about them or don't know enough about them yet.

A showerthought I had recently was that newly-written software may have a perverse incentive to be intentionally buggy such that there will be more public complaints/solutions for said software, which gives LLMs more training data to work with.

Re: Migrating away from Rust

#106

Post by ChadNauseam »

anticrymactic wrote: post #91
koakuma-chan wrote: post #60

Earlier quoted context omitted.

The fact you need a usize specifically to index an array (and most collections) is pretty annoying.

This could be different in game dev, but in the last years of writing rust (outside of learning the language) I very rarely need to index any collection. There is a very certain way rust is supposed to be used, which is a negative on it's own, but it will lead to a fulfilling and productive programming experience. (My opinion) If you need to regularly index something, then you're using the language wrong.

This is getting downvoted but it's kind of true. Indexing collections all the time usually means you're not using iterators enough. (Although iterators become very annoying for fallible code that you want to return a Result, so sometimes it's cleaner not to use them.)

However this problem does still come up in iterator contexts. For example Iterator::take takes a usize.

Re: Migrating away from Rust

#107

Post by inerte »

gregschlom wrote: post #93
ninjis wrote: post #79

The "Learning" point drives home a concern my brother-in-law and I were talking about recently. As LLMs become more entrenched as a tool, they may inevitably become the crutch that actually holds back innovation. Individuals and teams may be hesitant to explore or adopt bleeding edge technologies specifically because LLMs don't know about them or don't know enough about them yet.

I was actually meaning to post this as an Ask HN question, but never found the time to word it well. Basically, what happens to new frameworks and technologies in the age of widespread LLM-assisted coding? Will users be reluctants to adopt bleeding-edge tools because the LLMs can't assist as well? Will companies behind the big frameworks put more resources towards documenting them in a way that makes it easy for LLMs…

There’s another future where reasoning models get better with larger context windows, and you can throw a new programming language or framework at it and it will do a pretty good job.

Re: Migrating away from Rust

#108

Post by pjmlp »

littlestymaar wrote: post #67
pjmlp wrote: post #55

Earlier quoted context omitted.

They might be unsafe, but there is enough tooling to pick from 60 and 50 years of industrial use, approximately.

Well, on the flip side with C++ some of it hasn't been updated beyond very basic maintenance and you can't even understand the code if you are just familiar with more modern C++…

Well it is upon each one to be good with their craft.

If not, the language they pick doesn't really make a difference in the end.

It is like complaining playing a music instrument to be in band or orchestra requires too much effort, naturally.

Re: Migrating away from Rust

#109

Post by excerionsforte »

I love Rust, but I would not try to make a full fledged game with it without patience. This post is not so much a moving away from Rust as much as Bevy is not enjoyable in its current form.

Bevy is in its early stages. I'm sure more Rust Game Engines will come up and make it easier. That said, Godot was great experience for me but doesn't run on mobile well for what I was making. I enjoy using Flutter Flame now (honestly different game engines for different genres or preference), but as Godot continues to get better, I personally would use Godot. Try Unity or Unreal as well if I just want to focus on making a game and less on engine quirks and bugs.

Re: Migrating away from Rust

#110

Post by 12_throw_away »

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

Post reply on HN