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

181–190 of 799 posts

Re: Migrating away from Rust

#181

Post by zaptheimpaler »

ChadNauseam wrote: post #99
lynndotpy wrote: post #23

I love Rust, but this lines up with my experience roughly. Especially the rapid iteration. Tried things out with Bevy, but I went back to Godot. There are so many QoL things which would make Rust better for gamedev without revamping the language. Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev. But that's a really hard sell (and might be harder to implement…

I wish more languages would lean into having a really permissive compiler that emits a lot of warnings. I have CI so I'm never going to actually merge anything that makes warnings. But when testing, just let me do whatever I want! GHC has an -fdefer-type-errors option that lets you compile and run this code: a :: Int a = 'a' main = print "b" Which obviously doesn't typecheck since 'a' is not an Int, but will run just…

Yeah this is my absolute dream language. Something that lets you prototype as easily as Python but then compile as efficiently and safely as Rust. I thought Rust might actually fit the bill here and it is quite good but it's still far from easy to prototype in - lots of sharp edges with say modifying arrays while iterating, complex types, concurrency. Maybe Rust can be something like this with enough unsafe but I haven't tried. I've also been meaning to try more Typescript for this kind of thing.

Re: Migrating away from Rust

#183

Post by CharlieDigital »

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.

Pretty good.

I started using Visual Studio Code exclusively around 2020 for C# work and it's been great. Lightweight and fast. I did try Rider and 100% it is better if you are open to paying for a license and if you need more powerful refactoring, but I find VSC to be perfectly usable and I prefer its "lighter" feel.

Re: Migrating away from Rust

#184

Post by CharlieDigital »

bob1029 wrote: post #173
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…

You don't need to use Visual Studio, but it really makes a difference in the overall experience. I think there may also be some misunderstandings regarding the purchase models around these tools. Visual Studio 2022 Professional is possible to outright purchase for $500 [0] and use perpetually. You do NOT need a subscription. I've got a license key printed on paper that I can use to activate my copy each time. Imagine…

    > Imagine a plumber or electrician spending time worrying about the ideological consequences of purchasing critical tools that cost a few hundred dollars.
That's just the way it is, especially with startups whom I think would benefit the most from C# because -- believe it or not -- I actually think that most startups would be able to move faster with C# on the backend than TypeScript.

Re: Migrating away from Rust

#185

Post by palata »

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.

Except that C# is memory safe.

Re: Migrating away from Rust

#186

Post by cvwright »

jdprgm wrote: post #179
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've noticed this effect even with well established tech but just in degrees of popularity. I've recently been working on a Swift/SwiftUI project and the experience with LLM's compared to something like web dev stuff with React, etc is noticeably different/worse which I mostly attribute to there probably being at least 20 times less Swift specific content on the web in comparison.

There are a ton of Swift /SwiftUI tutorials out there for every new technology.

The problem is, they’re all blogspam rehashes of the same few WWDC talks. So they all have the same blindspots and limitations, usually very surface level.

Re: Migrating away from Rust

#187

Post by wewtyflakes »

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.

Doesn't this mean that new tech will have to demonstrate material advantages, such that outweigh the LLM inertia, in order to be adopted? This sounds good to me; so much framework churn seems to be code fashion rather than function. Now if someone releases a new framework, they need to demonstrate real value first. People that are smart enough to read the docs and absorb the material of a new, better, framework will now have a competitive advantage; this all seems good.

Re: Migrating away from Rust

#188

Post by forrestthewoods »

adamrezich wrote: post #172
forrestthewoods wrote: post #16

Rust is not good for video game gameplay logic. The ownership model of Rust can not represent the vast majority of allocations. I love Rust. It’s not for shipping video games. No Tiny Glade doesn’t count. Edit: don’t know why you’re downvoting. I love Rust. I use it at my job and look for ways to use it more. I’ve also shipped a lot of games. And if you look at Steam there are simply zero Rust made games in the top 2…

> Also you’re strictly forbidden from shipping Rust code on PlayStation. So if you have a breakout indie hit on Steam in Rust (which has never happened) you can’t ship it on PS5. And maybe not Switch although I’m less certain. What evidence do you have for this statement? It kind of doesn't make any sense on its face. Binaries are binaries, no matter what tools are used to compile them. Sure, you might need to use wh…

Sony mandates you use their toolchain. You don’t get to ship whatever you want on their console. They have a very thorough TRC check you must pass before you get to ship.

Re: Migrating away from Rust

#190

Post by klabb3 »

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…

> but the code a bit more brittle, esp. for concurrency

Obligatory ”remember to `go run -race`”, that thing is a life saver. I never run into difficult data races or deadlocks and I’m regularly doing things like starting multiple threads to race with cancelation signals, extending timeouts etc. It’s by far my favorite concurrency model.

Post reply on HN