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

121–130 of 799 posts

Re: Migrating away from Rust

#121

Post by IgorPartola »

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…

This already happens. Is your new framework popular on GitHub and on Stack Overflow is a metric people use. LLMs are currently mostly capable of just adapting documentation, blog posts, and answers on SO. So they add a thin veneer on top of those resources.

Re: Migrating away from Rust

#122

Post by bunderbunder »

ChadNauseam wrote: post #106
anticrymactic wrote: post #91

Earlier quoted context omitted.

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.

An iterator works if you're sequentially visiting every item in the collection, in the order they're stored. It's terrible if you need random access, though.

Concrete example: pulling a single item out of a zip file, which supports random access, is O(1). Pulling a single item out of a *.tar.gz file, which can only be accessed by iterating it, is O(N).

Re: Migrating away from Rust

#123

Post by brokencode »

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…

Developers often pick languages and libraries based on the strength of their developer tools. Having great dev tools was a major reason Ruby on Rails took off, for example.

Why exclude AI dev tools from this decision making? If you don’t find such tools useful, then great, don’t use them. But not everybody feels the same way.

Re: Migrating away from Rust

#124

Post by n_ary »

rad_gruchalski wrote: post #100
gregschlom wrote: post #93

Earlier quoted context omitted.

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…

Another way to look at it: working bleeding edge will become a competitive advantage and a signal to how competent the team is. „Do they consume it” vs „do they own it”.

Or a signal that, someone did not think about the bus factor and future of the project when most of the teams jumped ship.

Re: Migrating away from Rust

#125

Post by seivan »

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.

[dead]

Re: Migrating away from Rust

#126

Post by malkia »

YesBox wrote: post #28

Related: https://news.ycombinator.com/item?id=40172033 - Leaving Rust gamedev after 3 years (982 comments) - 4/26/2024

https://loglog.games/blog/leaving-rust-gamedev/#hot-reloadin...

Hot reloading! Iteration!

A friend of mine wrote an article 25+ years ago about using C++ based scripting (compiles to C++). My friend is super smart engineer, but I don't think he was thinking of those poor scripters that would have to wait on iteration times. Granted 25 years ago the teams were small, but nowadays the amount of scripters you would have on AAA game is probably dozen if not two or three dozen and even more!

Imagine all of them waiting on compile... Or trying to deal with correctness, etc.

Re: Migrating away from Rust

#127

Post by nonameiguess »

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.

I'm not a game dev, but what's a straightforward way of adjusting some channel of a pixel at coordinate X,Y without indexing the underlying raster array? Iterators are fine when you want to perform some operation on every item in a collection but that is far from the only thing you ever might want to do with a collection.

Re: Migrating away from Rust

#128

Post by _QrE »

gh0stcat wrote: post #61
_QrE wrote: post #26

> I failed to fairly evaluate my options at the start of the project. The more projects I do, the more time I find that I dedicate to just planning things up front. Sometimes it's fun to just open a game engine and start playing with it (I too have an unfair bias in this area, but towards Godot [ https://godotengine.org/ ]), but if I ever want to build something to release, I start with a spreadsheet.

Do you think you needed to have those times to play around in the engine? Can a beginner possibly even know what to plan for if they don't fully understand the game engine itself? I am older so I know the benefits of planning, but I sometimes find that I need to persuade myself to plan a little less, just to get myself more in tune with the idioms and behaviors of the tool I am working in.

I think even if you don't have much experience with tools, you can still plan effectively, especially now with LLMs that can give you an idea of what you're in for.

But if you're doing something for fun, then you definitely don't need much planning, if any - the project will probably be abandoned halfway through anyways :)

Re: Migrating away from Rust

#129

Post by SoKamil »

gwd wrote: post #97
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.

New languages / packages / frameworks may need to collaborate with LLM providers to provide good training material. LLM-able training material may be the next important documentation thing. Another potentially interesting avenue of research would be to explore allowing LLMs to use "self-play" to explore new things.

How can it compete with vast amount of trained codebases on Github? For LLMs, more data equals better results, so people will naturally be driven to better completion with already established frameworks and languages. It would be hard to produce organic data on all ways your technology can be (ab)used.

Re: Migrating away from Rust

#130

Post by littlestymaar »

pjmlp wrote: post #108
littlestymaar wrote: post #67

Earlier quoted context omitted.

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.

Except here you are a trained pianist and the tour manager gave you a pipe organ or a harpsichord.
Post reply on HN