Oh, that's really cool, I didn't know they had this project in the pipe. I agree that bundling tools with the compiler is such a great idea; a build tool built specifically for the language can assume so much more and do so much more, it's a net win.
I'm at a junction where I've been using Scala happily, but it falls down for numerical work because it can't call C libraries using large arrays without copying, because of the different memory layout used by the JVM vs. C, which really hurts for large data.
I haven't tried it, but I've heard good things about the experience and the performance. It didn't seem very functional though when I first looked at it which is what I was interested in at the time.
There's something to be said though for being able to write programs that will already be doing real work before the pinky finger has released the return key that launched them, I like the feel of that and I've missed that with the JVM.
So... how much of the NES does this emulate? As I understand it, it's pretty easy to get a basic 6502 core and a scanline renderer together enough to handle, say, Super Mario Bros. but if you support all the timing corner-cases and memory-map chips and such, it gets to be pretty frustratingly complicated.
EDIT: I should have looked more closely; looking into 'mapper.rs' reveals that it currently supports only the vanilla NES memory-map.
Since when does an NES take "decent processing power" to emulate? I emulated NES games on a 386DX40 and SNES games on a 486DX266. Certainly the emulation wasn't as accurate as what you get today, but neither is this tech-demo example.
I guess it depends on how closely you want to emulate the platform. For example, there was a great article [1] about a SNES emulator that required an extremely powerful machine, because it aimed to be a 100% accurate emulator. I guess if pcwalton decides to go for a very accurate NES emulator, the CPU usage would be non-negligable.
You're right, it's a silly statement. Because you don't need to run more than 60 frames per second, you won't start seeing performance degradation over native until you hit, say, 10X slower than optimized C.
What I was getting is that I think turning off the frame limiter and counting how many frames run in, say, 10 seconds would be a nice benchmark of compiler optimization.
I think you're missing the point. From the README:
"Its purpose is to serve as a technology demonstration to show how the Rust programming language is suitable for systems software such as emulators. [...] sprocketnes is also designed to be a relatively clean example codebase, showing off various Rust idioms."
I thought the official tutorial was good enough to start reading the library code. That's probably about as good as it'll get until the language stabilizes.
* Note: Rust is my language for the year. I can read Rust, follow program flow and I understand the major ideas but I've only put together toy programs.
I think it's neat that this doesn't used any managed pointers and avoids the Garbage collector. The fact that you can simply grep a codebase for '@' to find cases of managed memory is great in my opinion. I've been learning the Rust syntax a bit but am currently stuck trying to find a problem to solve with it that doesn't require me writing a bunch of libs from scratch or writing C interfaces. The Std/Core libraries are still rather lacking compared to say, the Go std lib.
I'm sure that will change, but for now it seems unfortunate. For example, there's an HTTP lib as part of Servo but according to some people in the IRC, it's not even very good.
Yes, the net lib was originally just intended to showcase preliminary libuv integration rather than as any sort of production library. Work is ongoing on a brand new approach to integrating libuv that will be both more efficient and more flexible. Once that's done I expect a proper, well-designed net library to emerge.
Fantastic to hear, I'm excited to watch Rust progress this year both in terms of libraries, language polish and tooling that has been hinted at in this thread. Some folks in the IRC gave me some pointers on another avenue involving HTTP so I've got something to play around with for a while when I get bored of writing Go :)
https://github.com/mozilla/rust/pull/4610
Independence from external build tools is one of the coolest features of Go, so I'm really excited about seeing more languages take this route.