markjgx

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.

> It's been flawless, more battery and memory efficient than Chrome

Is that actually true?

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.

hckrnews.com + DarkReader. DarkReader is such a good extension, couldn't live without it!

"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.

Awesome, thanks.