Rust really shines on this kind of job. Code is clean, simple and modulated.
Where do I find games to test this out?
RBoy: A Gameboy Emulator in Rust
21–30 of 63 posts
Re: RBoy: A Gameboy Emulator in Rust
#22Rust really shines on this kind of job. Code is clean, simple and modulated. Where do I find games to test this out?
Re: RBoy: A Gameboy Emulator in Rust
#23Why must every new rust project be reported here? Are there any other languages for which every new thing is being reported as if it were some major milestone? Is it true that this happens because Amazon is astroturfing rust like mad (as suggested on this website the other day)?
A couple of years ago every new Go project was being reported here; before that every new Elixir project was being reported; I don’t know if HN was around in the mid-2000’s but I’m pretty sure if it was, it would be full of every new Ruby on Rails project… these phases have been coming and going for as many years as I’ve been signed up here at least ¯\_(ツ)_/¯
HN was around in the late 2000s, which was enough to catch the latter part of the Rails craze, and yes there were a number of posts regularly on X in Rails/RailsClone, Rails vs Sinatra, Rails vs Merb, etc etc
Re: RBoy: A Gameboy Emulator in Rust
#24Why must every new rust project be reported here? Are there any other languages for which every new thing is being reported as if it were some major milestone? Is it true that this happens because Amazon is astroturfing rust like mad (as suggested on this website the other day)?
A couple of years ago every new Go project was being reported here; before that every new Elixir project was being reported; I don’t know if HN was around in the mid-2000’s but I’m pretty sure if it was, it would be full of every new Ruby on Rails project… these phases have been coming and going for as many years as I’ve been signed up here at least ¯\_(ツ)_/¯
Before that -- every Java. and before that, every PHP.
What was before PHP? Perl?
Re: RBoy: A Gameboy Emulator in Rust
#25Rust really shines on this kind of job. Code is clean, simple and modulated. Where do I find games to test this out?
[deleted]
Re: RBoy: A Gameboy Emulator in Rust
#26Earlier quoted context omitted.
there's only a barely working, undocumented backend for LLVM on the z80. You could probably do this with mrustc.
The Game Boy doesn't use a Z80 though. It's based on a SM83 core, an obscure Sharp design.
It's essentially a stripped Z80 without the DD-, ED- and FD-prefix instruction ranges. The core instruction block and CB-prefix range is (nearly) the same.
Re: RBoy: A Gameboy Emulator in Rust
#27Earlier quoted context omitted.
I wouldn't know, I hardly ever see such posts about other languages. Weird, isn't it, that only rust gets that treatment?
As of writing this the font page has the following: * Slacktyping: I'm typing when you're typing (2018) * The world's worst Linux kernel module * Show HN: Go playground powered by WASM that runs in the browser * Elk: A low footprint JavaScript engine for embedded systems
Amusingly enough, the said “Go playground” is actually written in Rust under the hood.
Re: RBoy: A Gameboy Emulator in Rust
#28Earlier quoted context omitted.
A couple of years ago every new Go project was being reported here; before that every new Elixir project was being reported; I don’t know if HN was around in the mid-2000’s but I’m pretty sure if it was, it would be full of every new Ruby on Rails project… these phases have been coming and going for as many years as I’ve been signed up here at least ¯\_(ツ)_/¯
Before that -- every Java. and before that, every PHP. What was before PHP? Perl?
I'd put Java's initial trendy period as before PHP's, Java was more concurrent with Perl for that kind of interest. PHP had a fair amount of reacting to the verbosity and tedium of early Java/C++9x static typing in the community
Re: RBoy: A Gameboy Emulator in Rust
#29I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).
I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascript I’ve seen plenty of very readable ternary operators (possible with the correct layout) replaced with unreadable junk by the prettifier.
It’s soulless to make all code look like bland corporate cardboard. It appeals to our OCD perfectionist tendencies but in my experience provides very little real value. Software is like writing. It can’t help but express how the author thinks about their code. These tools try to iron that personality out - and for what reason? Who cares in javascript if some files use semicolons and some don’t? Who cares if my where clause is on the same line or the next? The compiler doesn’t care, and neither do I.
(I will grant that all files in a project should have consistent white space, but you don’t need cargo fmt for that.)
Re: RBoy: A Gameboy Emulator in Rust
#30I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).
I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascr…
I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling.
The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact bespoke spacing of all code is the perfectionism you mention.