It was written by pcwalton, one of the main driving forces behind Rust. (Unfortunately, it hasn't been updated for a couple months, so it won't build with latest rust).
NES emulators are a common and fun challenge for testing out languages. Here's one in Clojure that intends to be fully immutable, such that you can rewind and fast-forward through history at will: https://github.com/samfoo/clones
In the case of Sprocketnes, one of its goals is to serve as a demonstration of Rust's ability to run entirely without a runtime (see the long-outdated quote in the readme: "The Rust garbage collector is not used in this project"... we really need to get this updated for 1.0).
> It was written by pcwalton, one of the main driving forces behind Rust. (Unfortunately, it hasn't been updated for a couple months, so it won't build with latest rust).
Possibly the most telling sentence I have ever read about Rust. I am (well more honestly, was) excited by the language but until there is some sort of stability guarantee, it is a fun toy, a distraction.
The Rust community appears desperate to have continuous improvement at the core language level, and despite some hand-waving, it feels like they simply won't be pinned down. I will watch it with interested post the May 15th 1.0 deadline -- but since they shipped entirely new Path and IO in Feb -- added new language constructs and removed others (Alpha2)... I am worried...
> Possibly the most telling sentence I have ever read about Rust. I am (well more honestly, was) excited by the language but until there is some sort of stability guarantee, it is a fun toy, a distraction.
> The Rust community appears desperate to have continuous improvement at the core language level, and despite some hand-waving, it feels like they simply won't be pinned down.
What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".
> I will watch it with interested post the May 15th 1.0 deadline -- but since they shipped entirely new Path and IO in Feb -- added new language constructs and removed others (Alpha2)... I am worried...
Why would you be worried that we're following precisely the schedule that we said we would?
I was vague and unclear, entirely my fault. I really want Rust to be successful, I just think some of the decisions being made are shortsighted, so I will watch after release to see if I am correct, hope I am not.
> What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".
I guess I don't consider "stability" and "backwards compatibility" the same thing -- in the "stability as a deliverable" post, it was specifically referenced that rust will "continue to evolve at a rapid pace and even accelerate!" (quoted from memory, sure it is somewhat off).
I think a constantly growing language (no longer changing cause old code has to work, but growing... which seems worse) and the fact that libraries will opt into new features and bundle use of those features with bug fixes will mean that the entire userbase is on a 6 week upgrade cycle -- 8 or 9 upgrades a year. I consider that a mistake. Furthermore, I consider the idea that the channels will not fracture the community to be very naive. I expect a lot of libraries will just live on unstable and tell users to "come with them".
> Why would you be worried that we're following precisely the schedule that we said we would?
You are correct and that was unfair. I can't fault the team for doing what they said -- even if to an outsider it seems like an insanely late time to be doing these types of refactoring.
> no longer changing cause old code has to work, but
> growing... which seems worse
It should be mentioned that the "features" that Rust has yet to implement are largely not of the nature of "wholly new concepts that will drastically change the language", but tweaks to existing features to make them more performant and more ergonomic. Such features include lessening the restrictions on the borrow checker, making it possible to return unboxed closures constructed in a lower stack frame, and improvements to user-defined smart pointer types to make them equal to first-class constructs (such as the ability to do `Rc<Trait>`). "Growing" here means refining the language as it exists, not succumbing to featuritis.
> the entire userbase is on a 6 week upgrade cycle -- 8 or
> 9 upgrades a year.
I don't see how this would be the case. If you write a lib for Rust 1.0, the intent is that it will continue to work for all users on Rust 1.1, and 1.2, and 1.3, and so on. No need for the lib author to explicitly upgrade, and hence no need for lib consumers to upgrade.
> I consider the idea that the channels will not fracture
> the community to be very naive.
Nobody is expecting the entire Rust ecosystem to transition to stable overnight. Rust 1.0 presents a very conservative foundation upon which you might want to base your code. If you do, you are rewarded with future stability for all 1.x (and also means that even unstable users will be able to use your code without breakage). This means that the stable Rust ecosystem will gradually accumulate over time. This gradual transition process is fully expected and encouraged.
Rust 1.0 does not mean "the language is done and perfect". It means "we know you're tired of breaking changes, so we've set aside all these enhancements that we were planning on adding so that we can achieve stability sooner, with the expectation of landing those features backward-compatibly at some later date." Rust could easily spend years and years and years in an unstable state, seeking perfection, and there are some in the community who still wish that were the plan. But as someone who's been using Rust since 2011, I'm in agreement with the core team: stability now, evolution over time.
> "Growing" here means refining the language as it exists, not succumbing to featuritis.
In no world does "we expect that pace of change to accelerate" mean "we expect subtle refinement of the language". Refinement or polishing generally isn't something that "accelerates change".
The Go authors have a really nice slide they like to show that shows the interest in Go as a trend. And right after they announced Go 1.0 with the backwards-stability promise, the interest sky-rocketed.
You can't have a perfect language. Ever. But if you want people to use the damn thing to build actual software, you have to stabilize eventually. C/C++ aren't perfect either - even the most hard-core C++ fan will admit to that - but they get shit done.
Go gets shit done. Sometimes in an ugly way. Rust could get things done in a beautiful way, if they just....stabilized it. Just stop changing it.
"Stable" but adding new features every 6 weeks... which will get used by library authors... which will put all users on a 6 week upgrade cycle.. yey?
Or your favorite library author just likes nightlies, which effectively forces you to run nightlies to keep up with bug fixes if he isn't maintaining a separate branch (and who has time for that noise).
> "Stable" but adding new features every 6 weeks... which
> will get used by library authors... which will put all
> users on a 6 week upgrade cycle
Why would it force anyone to upgrade? If a library exists for Rust 1.0, and then a library author releases a new version of the library with Rust 1.1 features, the Rust 1.0 library does not cease to exist. And Cargo supports semantic versioning to make it easy for library authors to inform their users when a new release is backwards-incompatible, and automatically upgrade users to new minor releases of the lib when the user has opted into receiving them. Even if a library author breaks their own backcompat and does all new feature development on a new version of Rust, thereby requiring you to upgrade your own version of Rust in order to get new features, the worst case scenario is that you download a new Rust compiler and all your other code continues working (hence, backwards compatibility).
> Or your favorite library author just likes nightlies,
> which effectively forces you to run nightlies
If a sufficiently-popular lib exists only on nightlies, then there will exist demand from stable users for a lib of equivalent functionality that targets a stable release. Stability is a competitive advantage! And because Rust can release a new minor version every six weeks, the core developers can look at what popular libraries are using the nightly branch, determine which features that library can't live without, and then prioritize stabilizing those specific features for the next minor release. Six weeks later, that lib is suddenly using a stable release.
> If a library exists for Rust 1.0, and then a library author releases a new version of the library with Rust 1.1 features, the Rust 1.0 library does not cease to exist. And Cargo supports semantic versioning...
That's true, but it ignores the way modern software unfortunately works. Programmers are lazy, and maintaining multiple development branches takes work, so they will try not to do that if they can get away with it. How many bug fixes will get backported to Rust 1.0.x, or to the 1.0-supporting version of that library? Probably not very many. Most developers will just bump the major version every 6 weeks, because that's easier than worrying about stability.
I think this attitude is far too cynical. Library authors that care about their users don't break backcompat lightly, and they do backport bugfixes. The mantra "programmers are lazy" does not imply that programmers are inherently amateurs.
I think that isn't so much attitude as experience. That said, I will watch post May 15th and hope I am wrong, but I suspect despite the buzz some of the policies will be (broad adoption) language suicide.
I cannot express how amused I am at the silliness of this whole conversation, which is predicated on the absurd premise that users won't want to upgrade their versions of the compiler. What part of the phrase "backwards compatible" is lost on this crowd?
It was written by pcwalton, one of the main driving forces behind Rust. (Unfortunately, it hasn't been updated for a couple months, so it won't build with latest rust).