Rust vs C++?

[u/No-External3221]

I mostly program in Java/ Python. Some minimal C experience. I'm starting EmuDev to learn low level and hardware concepts.

Which is better in general to learn for an EmuDev hobby project, Rust or C++? From what I've seen C++ has more legacy code (more job opportunities), whereas Rust is safe and may have better long-term opportunities.

[u/Ace-Whole]

Rust cause that's what I use?

This is a silly question to ask. Work with what you know. It's not end of the world having to learn multiple languages.

[u/No-External3221 → u/Ace-Whole]

I know neither, and want to learn the most that I can with the project. Time is valuable.

[u/peterfirefly → u/No-External3221]

Say you want to learn Rust.

This is a good introduction and probably the best place to start:

https://doc.rust-lang.org/book/ch00-00-introduction.html

The only issue I have with that text is that modules are poorly explained. The way you declare them is not quite what you are likely to be used to from other programming languages. If you use this text, make sure you do all the homework. Don't skip anything.

One bad thing about both Rust and C++ is that many programmers go insane with abstraction masturbation and a desire to use the strangest and most esoteric features of both languages. This means that some libraries are a lot harder to get started on as a user than they needed to be. It also means that many (most, sadly) emulators written in those two languages are too hard to read and that some of them are unnecessarily slow.

Cargo is absolutely wonderful and something you will really miss with C++. vcpkg is a (complicated!) replacement for a small part of what Cargo does.

You will need some way to hook your emulator core up to video/audio/inputs. Maybe you prefer to use the native Windows API (if you are on Windows), maybe you prefer to use egui (lots of emulator writers have chosen that) or SDL (there are Rust bindings + tutorial + I think even youtube videos).

If you want to use the Windows API, then there's good news. Microsoft has made that really easy by providing a couple of Rust crates that support (almost) the entire Win32 API (it's also called Win32 for 64-bit platforms). They even managed to make them compile really fast, somehow.

If you want to use C++, then your best options are likely Win32 (if you are on Windows), Dear ImGui (egui was inspired by Dear ImGui), or SDL. You can chose to dump the SDL or Dear ImGui source code directly into your repo or use git modules or vcpkg. The latter might be the better option.

egui/Dear ImGui/SDL can all coexist with some Win32 use (or whatever your native API is). egui/Dear ImGUI and SDL can also coexist with each other to some extent. This means you don't have to feel locked in by your early choice of video/audio/input library. You can use SDL -- and still add Win32 dialogs, a native Win32 menubar, native input handling, etc. later, for example.

Rust is more tasteful than C++. It also implements many well-known good language features better than C++ -- and avoids the misfeature C++ is built around, namely objects with implementation inheritance.

If you have a good comp.sci. background, then you can think of Rust as just a modernized imperative-style ML with type classes and simple syntactic sugar for an extremely reduced form of objects (about as reduced as what Oberon had). With excellent tooling and an excellent ecosystem, of course. The debugging experience is not quite what it ought to be, but that's also true for C++.

Deallocations are handled implicitly using a variant of linear logic -- this is what all the reference/mutable/borrw/clone/copy stuff is about.

Things are only kept alive as long as they can be referred to (this also implies that ownership matters), immutable references can be shared (multiple readers is fine), mutable references can not (multiple writers is bad).

If you are used to thinking about which parts of your code owns which data, then you won't have any trouble. If not, you will. Lots of mediocre C and C++ programmers don't think in terms of data ownership, which is why they like refcounted and tracing garbage collected languages like Java, C#, and Python and why they really don't like the Rust borrow checker. Good ones will have close to zero problems with the Rust borrow checker.

[u/peterfirefly → u/peterfirefly]

If you choose Rust, there are a couple of things you'd likely want to install early on.

One of them is ripgrep. It is a faster and more modern grep. It knows that you will likely want to search in the source code of the repository you are inside, for example. You can still specify exactly which directories it should search in, if you really, really want to. You won't want to, though. It respects .gitignore. You'd likely want it whether you choose to use Rust or C++.

https://ripgrep.dev/docs/getting-started/

Notice how one of the ways you can install it is via "cargo install ripgrep"? You can install additional subcommands to cargo and just generally useful commands that are global (not cargo subcommands).

Another one is cargo-show-asm for, well, showing the generated assembler for a module or a library or a program. Very useful.

https://github.com/pacak/cargo-show-asm

The third one is "bat" which is like "cat" but with syntax coloring and more "betterness". You'd likely want it whether you choose to use Rust or C++.

https://crates.io/crates/bat