Hacker News new | ask | show | jobs
by yodsanklai 535 days ago
I'm learning Rust at the moment (I'm going to join a new team that uses Rust). I'd say it's quite fun and I'm not good enough to have a strong opinion on the language, but I have a few thoughts though.

So far, I find the language design not super elegant. There are restrictive ownership rules, which are fine, but then a myriad of data structures that let you circumvent these rules. It feels somewhat ad-hoc.

Regarding pattern-matching and enum types, I can see why a C++ programmer is impressed with such constructs, but it's really underwhelming for an OCaml/Haskell programmer.

That being said, C++ is hard and complex and it's refreshing to be able to use a more modern language. Assuming you're certain you can't live with the performance overhead of a GC, Rust fills a gap, but it doesn't seem it's the end of the story. I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

5 comments

> So far, I find the language design not super elegant. There are restrictive ownership rules, which are fine, but then a myriad of data structures that let you circumvent these rules. It feels somewhat ad-hoc.

It's not “circumventing” the rules, it's adding automatic runtime check that the invariants are properly maintained when you cannot prove them at compile time.

The default restrictions are here so that you can have safe code without any runtime cost but, every once in a while, such limitation presents you from doing what you want to do. The various data structures you're talking about[1] then make sure that you can write the program you want but that it will not trigger undefined behavior, at the expense of some runtime cost, be it a branch (for RefCell) a reference count increment (Rc, atomic increment for Arc) or a lock.

[1] it's not “a myriad” though, merely 6 of them: Rc & Arc for shared ownership / being 'static, and RefCell, Cell, Mutex and RwLock for shared mutable state)

> necessarily a better choice than modern C++ for someone starting a new project.

Almost certainly but it depends on what you're making. If it's something that requires huge object graphs and GC then you'll probably have a bad time in Rust.

The compiler guarantees, dependency management, and modern toolchain is miles ahead of C++. I find that you have to be a wizard in multiple areas that don't necessarily involve programming when you're working on a C++ project. This comes on top of being a wizard in the language itself since it's huge and the std library has warts due to the "ABI compatibility over everything" mindset.

While not cargo level, vcpkg and conan + cmake help a lot, with much better compilation times, due to support for native libraries.

Still looking forward to the day cargo offers similar capabilities, without having to follow something like the whole Bevy setup.

> Regarding pattern-matching and enum types, I can see why a C++ programmer is impressed with such constructs, but it's really underwhelming for an OCaml/Haskell programmer.

What's underwhelming about Rust's enums and pattern matching? Lacking indexed types/GADTs?

> I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

The same enums, matching and other language features that aren't related to safety and yet allow the developer to write less boilerplate, alleviate the need to remember implementation details of the code used. And as someone said here, safety is not only about security vulnerabilities.

Not once I had problems with the borrow checker. Maybe it depends on the domain, requirements or project size. While I haven't finished any game in Rust, I am writing one (as a hobby/learning) and I try to avoid unnecessary and noticeable performance hits. Though I am working under the assumption that some runtime checks that are present in safe Rust and not in C++ are a net positive due to easier debugging. I'm not convinced that "unsafe" code and asm are necessary in modern gamedev.

> but then a myriad of data structures that let you circumvent these rules

Such as? There are only a couple of ones that come to mind, for very specific use cases.

>I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

C++ has decades of infrastructure, and is still the standard for games, so it's almost certainly not the better choice if your goal is shipping.

It's arguably better for best practices and may be a standard in the far future, but you're going down an untrodden path if you make that choice. you'll be spending just as much, if not more time fighting your tools than making a game. (unless you're comfortable with the few stable-ish Rust game engines).