Live data from Hacker News

Migrating away from Rust

deadmoney.gg

301–310 of 799 posts

Re: Migrating away from Rust

#301
post #34

Earlier quoted context omitted.

They mentioned ABI and the ability to create mods, which are Rust things. Here's a thought experiment: Would Minecraft have been as popular if it had been written in Rust instead of Java?

I mean, we already have a sort-of answer, because the "Bedrock Edition" of Minecraft is written in C++, and it is indeed less popular on PC (on console, it's the only option, so _overall_ it might win out) and does lack any real modding scene

Indeed. Java is sufficiently dynamic/decompilable a game written in it can be heavily modded without adding specific support. C++ is much harder (depending on the game engine), though not impossible. If you do add modding support then everything is much better regardless of language, though (see Factorio, written in C++ and with a huge modding scene, because it was basically written with modding in mind. Lua is certainly helping with that, of course).

Re: Migrating away from Rust

#302
One of the smartest devs I know built his game from scratch in C. Pretty complex game too - 3D open-world management game. It's now successful on steam.

Thing is, he didn't make the game in C. He built his game engine in C, and the game itself in Lua. The game engine is specific to this game, but there's a very clear separation where the engine ends and the game starts. This has also enabled amazing modding capabilities, since mods can do everything the game itself can do. Yes they need to use an embedded scripting language, but the whole game is built with that embedded scripting language so it has APIs to do anything you need.

For those who are curious - the game is 'Sapiens' on Steam: https://store.steampowered.com/app/1060230/Sapiens/

Re: Migrating away from Rust

#304
post #250

Earlier quoted context omitted.

Rust is very easy when you want to do easy things. You can actually just completely avoid the borrow-checker altogether if you want to. Just .clone(), or Arc/Mutex. It's what all the other languages (like Go or Java) are doing anyway. But if you want to do a difficult and complicated thing, then Rust is going to raise the guard rails. Your program won't even compile if it's unsafe. It won't let you make a buggy app.…

This argument goes only so far. Would you consider querying a database hard? Most developers would say no. But it’s actually a pretty hard problem, if you want to do it safely. In rust, that difficultly leaks into the crates. I have a project that uses diesel and to make even a single composable query is a tangle of uppercase Type soup. This just isn’t a problem in other languages I’ve used, which granted aren’t as s…

Building a proper ORM is hard. Querying a database is not. See the postgres crate for an example.

Querying a database while ensuring type safety is harder, but you still don't need an OEM for that. See sqlx.

Re: Migrating away from Rust

#305
post #14

The article title is half-true. It wasn't so much they migrated away from Rust, but that they migrated away from Bevy, which is an alpha quality game engine. I wouldn't have read the article if it'd been labeled that, so kudos to the blog writer, I guess.

The problem with Rust is that almost everything is still at an alpha stage. The vast majority of crates are at version 0.x and are eventually abandoned, replaced, or subject to constant breaking changes While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.

I wouldn't say 'almost everything', but there are some areas which require a huge amount of time and effort to build a mature solution for, UI and game engines being one, where there are still big gaps.

Re: Migrating away from Rust

#306
post #41

Earlier quoted context omitted.

> I am sure that is mostly access to additional external libraries that did things they wrote by hand in Rust This is the biggest reason I push for C#/.NET in "serious business" where concerns like auditing and compliance are non-negotiable aspects of the software engineering process. Virtually all of the batteries are included already. For example, which 3rd party vendors we use to build products is something that c…

In sectors that are critical here in the EU, nobody allows c# and microsoft due to licensing woes longterm. It's java and foss all the way down. SaaS also is not a thing unless it runs on prem.

C# and Microsoft are in all critical places in Europe. What are you talking about

Re: Migrating away from Rust

#307

Earlier quoted context omitted.

You think the JVM is slow?

IME large linear algebra algos run like molasses in a jvm compared to compiled solutions. You're always fighting the gc.

Ok. But we have plenty of C libraries to bind to that for.

They're far slower in Python but that hasn't stopped anyone.

Re: Migrating away from Rust

#308

Earlier quoted context omitted.

I have a personal-use app that has a hot loop that (after extensive optimization) runs for about a minute on a low-powered VPS to compute a result. I started in Java and then optimized the heck out of it with the JVM's (and IntelliJ's) excellent profiling tools. It took one day to eliminate all excess allocations. When I was confident I couldn't optimize the algorithm any further on the JVM I realized that what I'd b…

I'd rather write rust than java, personally

I'd have said the same thing 10 years ago (or, I would have if I were comparing 10-year-old Java with modern Rust), but Java these days is actually pretty ergonomic. Rust's borrow checker balances out the ML-style niceties to bring it down to about Java's level for me, depending on the application.

Re: Migrating away from Rust

#310
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…

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

> C++ has been faster than C for a long time.

Citation needed.

Post reply on HN