zesterer

> My overall feeling is that if I could spend infinite time and effort, my C programs would be as fast or faster than Rust, because theoretically there's nothing C can't do that Rust can.

The exact same argument applies to assembly code. There are very good reasons that it's not used nowadays except in incredibly rare circumstances or in the embedded world.

It doesn't matter in the slightest how fast your language is in theory. Not one iota.

The only thing that matters is how fast the programs you write with it are in practice. The evidence is clear: it is significantly easier to write faster programs in Rust than it is in C, and this applies to even the most skilled developers.

Because the closure form is much more useful. You very rarely want to create a thread without first passing some state to it, and environment-passing with closures is a brilliantly ergonomic way to do this.

The article title is clickbaity as heck, but the content is (reasonably) sound.

A better title would be 'Rust's async model has some flaws that are a product of its desire to ensure safety and make the true cost of certain operations visible'.

Of course, such a title would never hit the front page of hacker news.

The problems the author identifies are real, but they're not unique to Rust. You can get around them fairly easily with dynamic dispatch, which is what basically every competitor to Rust's async model does by default.

I agree with the author that Rust's use of async in the ecosystem is increasingly universal and it's starting to become a little problematic. As the author of Flume and a (soon to be released) concurrent hashmap implementation, I'm trying to work on adding primitives that successfully marry sync and async with one-another. There's no doubt that it's hard though, and function colouring is a problem.

There's a pretty big difference here though. In the case of Unity, most of the very hot code is C++. With a custom Rust engine, most of it is Rust.

Yes, but only via the admin-only /build command. It's not an ordinary part of gameplay, aside from the limited destruction you can do with some of the weapons. We're considering adding some sort of building system, but we've not reached a consensus on how to best implement it yet.

Yep, this is correct. All of us Veloren developers very much appreciate the work the Cube World developer put into the game: it's great fun. Veloren isn't trying out outright compete with the game: increasingly, the project is adopting goals that differ. Over time, I'd like to see Dwarf Fortress be the game Veloren is most frequently compared to instead, since that seems to be the direction of momentum.

That's great! Make sure to tell us if you do, we'd love to put it up on the public server list!

> The first bug will cause a segfault and crash.

Or, you know, nasal demons

We're aiming for something that plays a bit like Legend of Zelda but allows you to interact with the world in a manner closer to Dwarf Fortress. We're also trying to keep movement fluid and dynamic with lots of opportunity to use the environment around you as you move throughout the world.

All of this is a work in progress (hence the pre-alpha versioning), but we already have a few hours of gameplay with dungeons and caves to explore, lots of items to craft and find, and several skill trees to upgrade. In the long-term, we're aiming for more procedural interaction with elements of the world.

> In the Unity games I’ve played GC doesn’t seem to be much of an issue

Remember that all of the 'hot' code is internal to Unity and is not written in C#. C# basically just takes on the role of a particularly powerful scripting language and isn't dealing with cleaning up huge amounts of data as would be the case for anything dealing with assets directly.

This is a good summary tbh

It's a mixed bag. Short of defining a formal spec and writing the program with a theorem prover, "bug-free" code isn't really a realistic goal. However, Rust does come with tools that at the very least allow the building of APIs that are very difficult to abuse via the trait system and other features such as sum types. Ultimately, spaghetti code is possible in virtually any language, so keeping a good eye on architecture is necessary no matter the language. What I would say is that Rust makes it easier to keep architecture constrained and correct.

BSD too!

Hi, I'm the founder of the project.

We chose Rust because it's performant, memory-safe, and comes with a host of modern features that make writing code with the language very enjoyable.

We could have chosen C++, but I'm very glad that we didn't. Memory safety is great: I've not needed to break out gdb even once throughout the history of this project, despite the size of the project. This safety means that code is easier to review because it 'does what it says on the tin' and is much less prone to UB and non-local behaviours. It also reduces the prevalence of bugs. I've been shocked by just how much easier it is to write reliable and bug-free code with Rust than it is with languages that I've used in the past (C, C++, Python, Vala, amongst others).

The type system is also very powerful and it lets us encode a lot of useful invariants that can be checked by the compiler. Knowing that what you're doing is correct-by-nature is a great help and it frees your mind up to focus on the logic of what you're writing rather than getting distracted by irrelevant details like representation.

Rust plays very well with data-oriented design. This works great for us. At its heart, Veloren uses a high-performance ECS that is extremely cache-coherent. There's still lots of optimisation work to do, but we're already seeing that servers that can handle hundreds of players and millions of entities without issue, despite the fact that terrain generation is done server-side (and, as such, we have similar performance constraints to games like Minecraft).

The client, server and client/server frontends (frontends are logically independent and alternative frontends can be written for the game) are all written in Rust. In addition, the in-development plugin API will allow for plugins written in Rust and compiled to WASM.

In addition, Rust is also very portable. Compiling the game on (and for) many platforms is incredibly easy. The game runs well on Windows, Mac OS, Linux, BSD, and community members have even gotten it running on the Raspberry Pi and a hacked Nintendo Switch!

I hope this doesn't come across as being overly evangelical, but I think I speak for all of the developers when I say that we have no regrets in the slightest about choosing Rust! That doesn't mean it's the right choice for all projects, of course. The Rust gamedev ecosystem is still relatively immature. Although this is changing fast, don't expect to find any nuts-and-bolts game engines ready to go. However, if you're not afraid of diving down into low-level APIs here and there, Rust might be a great choice.

Edit: At a second glance, I see you're asking more about why mentioning the language is important. As a community-driven project, we rely on encouraging new contributors to work on the game and the choice of language is something that developers usually care about a lot. Extensibility and open development is really important for us and so 'showing the innards' is a big part of what we do when interacting with the community. Unless it's security-sensitive, we'll always discuss development issues and ideas in a public forum where anybody can add their input.

Hey Jeremy! What sort of support do you have for graphical APIs like windowing, graphics, etc.? I'd be really interested in working with you to port Veloren (https://veloren.net/), also written in Rust, to Redox at some point in the future: if nothing else, as a demonstration of what a pure Rust tech stack can do. If you're interested in this, feel free to message me on Reddit (same username).

There is no one definition of 'formal verification'. Sel4's verification required developers to specifically demarcate the behaviour they desire and generally requires the use of abstractions with very predictable safe semantics. In addition, Sel4 is less than 9k lines of code.

That is a very, very long way from developing a general-purpose compiler for a general-purpose system language that can perform arbitrary formal verification for arbitrary code. That's not the goal of Rust and I doubt that it would be a particularly useful one for 99% of developers anyway. The goal of Rust's safety promise is that the verification and review of an entire codebase (as would be the case in C) shrinks down to just a very small corner of that codebase (that which is demarcated as 'unsafe').

In practice, I think that unsafe uses are substantially rarer than that even. Veloren (https://gitlab.com/veloren/veloren/) has almost 120,000 lines of code nowadays and yet has fewer usages of unsafe code than you can count with a single hand.

This is actually pretty easy to do, and indeed vanilla Rust does sort of guarantee that memory leaks can't happen, at least when using its normal ownership rules.

However, Rust's standard library also includes types (implemented with unsafe code, but only accessible through safe interfaces) that allow shared ownership through reference-counting like `Rc`/`Arc` and also ways to mutate shared memory like `RefCell`/`Mutex`. These two things, in combination, allow the creation of self-referential data (i.e: effectively a leak). For this reason, it's necessary to consider leaking a safe (if generally unintended) behaviour.

After all, leaking isn't "undefined behaviour" and it generally isn't intrinsically harmful to the program, except at the limit when the computer runs out of memory in which case you get a safe, well-defined OOM panic. Heck, there are even a plethora of useful techniques that use leaking. Leaking a data structure proves to the compiler that it will stay around indefinitely (i.e: it has a "static" lifetime), for example, which allows you to do things with it that Rust would normally forbid.

That is not to say that Rust doesn't provide any protection from leaking, however. Its ownership model generally makes leaking extremely difficult to do accidentally, particularly when designing programs idiomatically, and its standard library contains a variety of abstractions that aid in managing shared memory correctly without leaks (Weak RC references, reference swapping, etc.).

I don't think I've personally ever experienced a leak-related problem that wasn't a result of badly-considered unsafe code despite the fact that I've been writing Rust every day for about 5 years and as my day job for the last 2 of those.

My god these people need to read some Marx. You cannot effectively disentangle these things, they are mutually-dependent and both a product of the same socioeconomic system. The conditions that created Elon Musk, Donald Trump, and pharma companies are indivisible. There is no competition between methods and mindsets, only systemic failures and broken incentives that result in a conflict between them.