If I had to guess why HN is so attracted to Rust, there's a few things that compound on each other.
Rust occupies a point in the design space that no other language does. Statically verified memory safety, strong concurrency guarantees, a world class toolchain, and it compiles to native machine code. Before Rust you always had to sacrifice one of these. Go gives you safety and ergonomics but you're garbage collected and limited in expressiveness. C++ gives you performance but safety is entirely your problem. Rust is the first mainstream language to credibly offer all of it.
The toolchain is the part people underestimate. As someone from C++, I cannot overstate how much this matters. Our toolchain is literally cobbled together ancient runes. Package management is strange and archaic. You can't just add a package to your project. There are stacks of contrived and obscure rules that must be followed. The language itself is a hodgepodge of inconsistencies layered on each other over decades. Some codebases are hundreds of macro incantations deep. Some prefer overload maxxing, default constructor shenanigans, uninitialized memory. Macros aren't even part of the language, it's a file preprocessor glued on from the side. Headers and implementations are stitched together. System dependency management is hell on earth. Build systems are fragmented: CMake vs Meson vs Bazel vs Make vs Ninja, pick your poison. I could keep going.
Meanwhile Rust just works. You add a package in a few seconds. Compile to seven different platforms out of the box, including the web. Type references just work, nothing to forward declare. Cargo is your build system, package manager, test runner, doc generator, and publisher in one coherent thing. That entire category of bikeshedding that has plagued C++ for decades just doesn't exist. It's heaven on earth.
I was wondering how the JVM and V8 stack up. Do you have a source for that claim? Genuinely curious.
Coming from the game dev world, I’ve grown more and more convinced that managed languages are the right move for most code. My reasoning is simple: most game developers don’t have the time or patience to deeply understand allocation strategy, span usage, and memory access patterns, even though those are some of the most performance-critical and time-consuming parts of programming to get right.
Managed languages hide a lot of that complexity. Instead of explaining to someone, “you were supposed to use this specialized allocator for your array and make sure your functions were array-view compatible”—something that’s notoriously tedious to guarantee in game engines given how few developers even think about array views—you just let developers write code and most of those problems go away.
I’m not saying everything should be managed. Core engine code should still live in the predictable, statically compiled world. But history shows it can work: projects like Jak and Daxter were written primarily in a custom LISPy scripting language, and even Ryujinx (RIP), the excellent Nintendo Switch emulator, is written entirely in C#.
Another strong technical reason is that managed JIT languages can profile at runtime and keep optimizing call sites based on actual usage patterns. Normally, developers would have to do this by hand or rely on PGO, which works but is painful to set up.
Industry standards make this harder to adopt since platforms like Sony still block JIT, but I think this is the direction we should be moving.
"Surfer: The World's First Digital Footprint Exporter" is dubious—it's clearly not the first. Kicking off with such a bold claim while only supporting seven major platforms? A scraper like this is only valuable if it has hundreds of integrations; the more niche, the better. The idea is great, but this needs a lot more time in the oven.
I would prefer a cli tool with partial gather support. Something that I could easily setup to run on a cheap instance somewhere and have it scrape all my data continuously at set intervals, and then give me the data in the most readable format possible through an easy access path. I've been thinking of making something like that, but with https://github.com/microsoft/graphrag at the center of it. A continuously rebuilt GraphRAG of all your data.
Some players will also be convinced that you're cheating if you play the game really really well, and they will get upset. CS:GO (now CS2) has a very fascinating way of determining if someone is cheating. A ML based heuristic that is constantly being retrained, that can accurately judge whether someone is actually cheating or not based off their Overwatch (not the game) replay system. https://www.youtube.com/watch?v=kTiP0zKF9bc
On the code side it's pretty much the same as C++. You have a module that defines an interface and per-platform implementations that are included depending on a "configuration conditional check" #[cfg(target_os = "linux")] macro.
Glad this was flagged. A lot of people have a misconception of managed languages being slow compared to your regular ol' binary program, these days that couldn't be further from the truth. In traditional high performance C/C++ development you have to manually split your code into hot and cold paths, static analysis optimization can only go so far.
Do you want to inline this function in your loop? Yes and no, i.e. you might be taking up some valuable registers in your loop, increasing register pressure. Time to pull out the profiler and experiment, wasting your precious time.
Managed languages have the advantage of knowing the landscape of your program exactly, as __that__ additional level of managed overhead can help the VM automatically split your code into hot and cold paths, having access to the runtime heuristics of your program allows it to re-JIT your hot paths, inline certain functions on the fly, etc.
"and it looks like they're finally improved on what was a terrible, clunky, extremely dated UI." doesn't hold true, it's mostly the same UI with a dark reskin. Certain editor hot paths have been reworked and that's about it.
The editor is almost exclusively written in Slate, Epic's in-house Window framework/general GUI module. Slate's got a pretty interesting nested MACRO system. Most definitely not data-driven and pretty much as hard-coded as it gets, redesigning the editor for real would be difficult to say the least. In reality most experienced developers don't want a new design, they are happy with the workflow they have and I have to agree with them. I'm generally happy with the "if it ain't broke don't fix it" reskin decision.
Thanks. It's called BadLads, it's all about multiplayer roleplay, where each player has their own job. The games about to get giant procedural cities (with full interiors!) and native virtual reality support. Here's the last devblog, although a bit dated:
https://devblog.chemicalheads.com/posts/upcoming-update-teas...
I choose to irrationally support Linux, because I like Linux. There is literally no financial incentive for me to do so. We were recently debugging a newer build on Linux, which was inexplicitly crashing on a players machine, while running great in the testing environment. This was causing a major headache as the game needed to ship that day.
We had another Linux volunteer test it out on his mostly vanilla Ubuntu setup, and it worked great. Ended up creating a chart of all the available testing configurations, e.g. comparing drivers across all the available environments. The supposed blame ended up being a statically linked library on his system. Funny thing is the tester who was crashing was enjoying the game in Proton while I was debugging the Linux build.
Talking about Unreal Blueprints, did you know creating a new blueprint node is as simple as writing a C++ function and adding a reflection macro on top of it, that's it. It's freaking awesome.
If you don't want to download every single frame you could feed these into DAIN (Depth-Aware Video Frame Interpolation) https://github.com/baowenbo/DAIN
Rust occupies a point in the design space that no other language does. Statically verified memory safety, strong concurrency guarantees, a world class toolchain, and it compiles to native machine code. Before Rust you always had to sacrifice one of these. Go gives you safety and ergonomics but you're garbage collected and limited in expressiveness. C++ gives you performance but safety is entirely your problem. Rust is the first mainstream language to credibly offer all of it.
The toolchain is the part people underestimate. As someone from C++, I cannot overstate how much this matters. Our toolchain is literally cobbled together ancient runes. Package management is strange and archaic. You can't just add a package to your project. There are stacks of contrived and obscure rules that must be followed. The language itself is a hodgepodge of inconsistencies layered on each other over decades. Some codebases are hundreds of macro incantations deep. Some prefer overload maxxing, default constructor shenanigans, uninitialized memory. Macros aren't even part of the language, it's a file preprocessor glued on from the side. Headers and implementations are stitched together. System dependency management is hell on earth. Build systems are fragmented: CMake vs Meson vs Bazel vs Make vs Ninja, pick your poison. I could keep going.
Meanwhile Rust just works. You add a package in a few seconds. Compile to seven different platforms out of the box, including the web. Type references just work, nothing to forward declare. Cargo is your build system, package manager, test runner, doc generator, and publisher in one coherent thing. That entire category of bikeshedding that has plagued C++ for decades just doesn't exist. It's heaven on earth.