game systems don’t need memory safety

I see what you’re saying but I don’t know if I agree on this point. Games are buggy messes before undergoing a long and arduous quality assurance process. While Rust’s iteration speed is maybe not great, I don’t think it’s really significantly worse than C++ iteration time, especially not with efforts like subsecond, that bevy uses for instance. And Rust is much more ergonomic and convenient to write than C++. It is in some ways a higher level language than C++ while managing to still allow for very fine optimisations, which are sometimes required in games. I think this would translate to productivity improvements too, although I don’t really have any data to back that up obviously.

I personally think the momentum is mostly what C++ has that Rust is lacking - i.e. a large body of game developers who are already well-versed in C++ and a large and established body of game engines and frameworks for every kind of game. Games are often pressed for financing, so venturing into the territory of new engines and new languages is not something most game devs can afford or want to spend their money on.

Do you mean Rust is unsuited for games, or that Rust simply don’t (yet) have the established engines/frameworks/libraries for it? I think Rust could be really great for video game development, but it’s true that the ecosystem is not quite there yet - though it’s getting better.

Interesting - I think this minimal solution I actually wouldn’t mind, but I’d be concerned about introducing syntax for callers. Keeping it as a private construct in libraries seems fine though.

Diesel is an ORM

This is kind of stretch to say though - it is not an ORM if you compare it to something like ActiveRecord. Diesel is just a DSL for writing SQL queries that are verified by the compiler.

sqlx requires a modern macro system

I wouldn’t say it requires using macros. You could definitely imagine verifying queries in the same way in languages without macros. But yea, this is one of the strengths of Rust I suppose.

Your last paragraph can be fixed even without an ORM though. Rust has libraries like diesel and sqlx that verify the sql in various ways.

Others have already pointed out the issue - in Rust, String is UTF-8 encoded and therefore characters are variable length. So you can’t just change a character in a string, as it may not fit (e.g. replacing ‘a’ with ‘🙂’ would lead to trouble).

You can do what the others suggest, but honestly for a game like hangman, I’d suggest you just work directly with chars and don’t use any string. As in, just use a Vec<char> instead of a string. Then you can freely change characters based on index, but this representation uses more memory than a typical String. But this won’t matter for your use case.

Definitely! The only other language where I felt the compiler actually helped me was Haskell. C and C++ just go like “something is fucked, you figure it out”.

I think the learning curve exists but it has been vastly overestimated by the rumours. I have many years of experience with Rust now, just ask if you are unsure of anything. Feel free to tag me in any post or PM me, then I’ll definitely see it.

Is this some american thing? I’ve never heard of anyone having a different name for a language class, that just seems odd to me. Your name is your name, doesn’t matter what language you’re speaking.

I think making the standard library larger in a composable way would be great. If we actually uplifted “blessed crates” from a loose concept to an actual thing in the build system, it would make Rust much easier to adopt for those who are not already well versed in the ecosystem.

No. “Hello, world!” or you’re doing it wrong.

but it can lead to absurdly high version numbers

I have a really hard time seeing this as a problem. Why is 125 an “absurd” version number? You’ve presumably done 125 patch versions since the last minor version, so doesn’t it just make sense?

It’s just a number, it doesn’t matter if it’s “high”.

Linux doesn’t use semantic versioning, right? So this is just an arbitrary number?

Might not be new but it’s not been posted here before :)

Not nearly as readable though

I don’t agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don’t have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.

Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It’s just a nudge, nothing more.

An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.

This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an “LTS” release, then crates could be encouraged to keep their MSRV compatible with that release.

But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on “just any” third-party crate at higher integrity levels.

I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn’t even be that hard (it’s certainly been done in many crates already).

Rust programs can definitely still consume a lot of memory. Not using a garbage collector certainly helps with memory usage, but it’s not going to change it from gigabytes to kilobytes. That requires completely rethinking how things are done.

That said I’m very much in favour of everyone learning Rust, as it’s a great language - but for other reasons than memory usage :)

This is the way with modern software engineering, especially in the industry. It comes from the basic fact that:

1. Companies want to get code for free from the internet - someone else already wrote that code, let’s use it for free and have better profit margins!
2. Companies do not want to spend time and effort vetting that free code, as that would make it… well, not free. That would require manpower (perhaps unless you trust AI to do it these days…) and that’s money.

Basically they want to eat their cake and have it too. This applies to all modern package managers for modern languages that make it easy to distribute your own code and consume free online code.

I doubt the industry will ever mature to a point where this will stop, as the tradeoff of getting free code with no work is just too good for most companies, especially the smaller ones.

Billboards and other physical ads and such suck but are thankfully already mostly illegal where I live.

Problem with other kinds of advertising is that it can’t be made illegal, not truly. People would still do it, it would just not be marked as such. I’m not sure how to fix this.

Have you tried the Rust book? I learned via that and it’s great.