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

191–200 of 799 posts

Re: Migrating away from Rust

#191

Post by tayo42 »

tptacek wrote: post #155
Bolwin wrote: post #144

Earlier quoted context omitted.

It's a lot worse. A high quality project can have great documentation and guides that make it easy to use for a human, but an LLM won't until there's a lot of code and documents out there using it. And if it's not already popular, that won't happen.

No, this doesn't ring true: long before there were LLMs, people were selecting languages and stacks because of the quality and depth of their community. But also: there is a lot of Rust code out there! And a cubic fuckload of high-quality written material about the language, its idioms, and its libraries, many of which are pretty famous. I don't think this issue is as simple as it's being out to be.

Isn't this article an example of that. There might be a lot of rust code but if the apis are changing frequently it's all outdated and leads to unusable outputs.

Re: Migrating away from Rust

#192

Post by foderking »

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.

great summary

Re: Migrating away from Rust

#193

Post by nu11ptr »

akkad33 wrote: post #62
nu11ptr wrote: post #6

I did the same for my project and moved to Go from Rust. My iteration is much faster, but the code a bit more brittle, esp. for concurrency. Tests have become more important. Still, given the nature of what my project is (APIs and basic financial stuff), I think it was the right choice. I still plan to write about 5% of the project in Rust and call it from Go, if required, as there is a piece of code that simply cann…

Is calling Rust from Go fast? Last time I checked the interface between C and Go is very slow

No, it is not all that fast after the CGo call marshaling (Rust would need to compile to the C ABI). I would essentially call in to Rust to start the code, run it in its own thread pool and then call into Rust again to stop it. The time to start and stop don't really matter as this is code that runs from minutes to hours and is embarrassingly parallel.

Re: Migrating away from Rust

#194

Post by Starlevel004 »

koakuma-chan wrote: post #60
Seattle3503 wrote: post #49

Earlier quoted context omitted.

What numeric types typically need conversions?

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

The actual problem with this is how to add it without breaking type inference for literal numbers.

Re: Migrating away from Rust

#195

Post by [deleted] »

eftychis wrote: post #157

This comment might not be liked by the usual commenters in these threads, but I think it is worth stressing: First: I have experience with Bevy and other game engine frameworks; including Unreal. And I consider myself a seasoned Rust, C etc developer. I could sympathize with what was stated by the author. I think the issue here is (mainly) Bevy. It is just not even close to the standard yet (if ever). It is hard for…

[deleted]

Re: Migrating away from Rust

#196

Post by [deleted] »

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.

[deleted]

Re: Migrating away from Rust

#198

Post by this_user »

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”.

Constantly chasing the latest tech trends has probably done more harm than good, because more often than not, it turns out that the latest hype technology actually does not deliver what the marketing had promised. Look at NoSQL and MongoDB especially as recent examples. Most people who blindly jumped on the MDB bandwagon would have probably been better off just using Postgres, and they later had to spend a lot of resources migrating away from Mongo.

To me constantly chasing the latest trends means lack of experience in a team and absence of focus on what is actually important, which is delivering the product.

Post reply on HN