You use the same process as for deciding if changes to rustc are compliant or not; the judgement of the language and compiler teams.
And running into these kinds of questions, both in a single project that evolves over time (rustc) and a separate project, help to feed information back into what you need for a formal specification; which is something that is being planned out. Having a second implementation can help find these areas where you might need to be narrower or broader in your specification, in order to clarify enough for it to be implementable or broaden it enough to accommodate reasonable implementation differences.
They are not trying to diverge in language implementation, but there will always be simple compiler bugs, which may crop up in one implementation but not another. For instance, some LLVM optimization pass may miscompile some code; gccrs wouldn't necessarily be trying to recreate that exact bug. I think that "bugs, quirks, and all" really means that they aren't trying to fix major limitations of rustc, such as introducing a whole different borrow checker model which might allow some programs that current rustc does not. They're trying to fairly faithfully recreate the language that rustc implements, even if some aspects might be considered sub-optimal, but they aren't going to re-implement every ICE and miscompilation, those are places where there could be differences.
I agree with you it has benefits, what I’m wondering about is if not more bugs (though not the same ones) would be fixed by contributing directly to rustc compared to the massive effort of building a new compiler.
Yeah, WASM was the result of taking a look at NaCl, realizing it could never be specified and independently implemented, and writing a spec for something better that could.
WASM is superior in pretty much all ways to NaCl other than being a bit more time to go through the whole specification and implementation process. NaCl was a great prototype, and WASM is a much more polished result because of it.
(P)NaCl was just too close to the past, roo many memories of activeX, flash and other crap still loomed heavy in people's hearts and they wanted a clean cut with the past, an open web, free from the dictat of corporations etc.
I do understand why people wanted something different and rejected (p)NaCl. But the reason is not technical, it's political (in the broad sense). Any technical issues could have been solved by fixing and extending (p)NaCl, but everybody involved understood it was not going to work
I used to work in the Native Client team at Google, both on regular NaCl and pNaCl. It failed for technical reasons too. And maybe, mostly for technical reasons.
pNaCl's biggest mistake was using LLVM bitcode as a wire format (see, for example, [1]). Another problem was trying to use glibc, instead of newlib. That resulted in a lot of low-level incompatibilities, as glibc itself is too target-specific. And implementing shared objects between portable and native world was really messy.
asm.js appeared as a simpler alternative to NaCl, and then it was quickly replaced by wasm, developed mutually by Mozilla, Google and others.
This is a common pattern in a lot of creative industries; some people have early, groundbreaking success, but once they're successful have a tough time replicating that. Some combination of now that they're rich, no longer really the pressure to succeed as they already have, they were in the right place at the right time and no longer are, they have less pressure from other people telling them "no", they no longer have the passion of youth in their favor, they were better at the "inventing a new genre" than competing in a more mature marketplace with everyone else who has already learned from their previous success, etc.
I don't know enough about the specifics of Romero to say which it is, possibly more than one, but it doesn't seem to be unique to him, I see this kind of pattern in pop culture all the time.
This phenomena is sometimes called the "sophomore slump" [1] in some creative industries and "second-system effect" [2] in software development. To add to your excellent list of reasons why this happens, I'd also add that early success may be the result of spending much more time on the first creative effort than subsequent ones. Some musicians spend years making their first album but then have only a year or two to try to repeat the success for a second album, especially if a label wants them to release another album while they are riding high and before their fame fades (supposedly). Second-system effect refers more specifically to feature creep in second projects in a series, but you can imagine the same thinking applying to creative industries too.
Not inconsistent with this, what seems warped to me is having these huge expectations for individuals after their first success in the first place. (Writing this thinking about someone like Romero working on something like a game; lot of what follows doesn't carry over to, say, music or writing.)
They needed talent to pull it off, but also lots of stars aligned for a bold experiment to work out, and true experiments don't always work out. Conversely, for each success there were many talented folks who tried good ideas and didn't see them work out. The more surprising the first success was, the more foolish you'd be to expect a repeat, it seems like.
If that's the basic problem, you can't "fix" it in the sense that you can't make someone keep churning out revolutionary new things. But you might get better outcomes and fewer embarrassing failures the more you think of individual talent as one factor. Folks still have to iterate, get feedback, work with good people, sometimes put a lot of work into an idea then see it they have to rework it, or even release some quick experiments that don't do that well. You don't maximize your odds of great results by sending someone off to work in isolation as long as they want.
One thing I see hints of here and there, but don't really have a great picture of, is the inner workings of organizations that produce new/weird but successful things more than just once. It interacts with business, luck, and changes in the world outside of course, but internally--how do they balance single vision vs. input from many folks? Do they build a lot they throw away? Do they go outside the team a lot for feedback (in Romero's world "playtesting")? Of course there's no one Right Way to do things, especially across domains, but it could be fascinating to see a bit more how various places work.
It doesn't ignore it; it explicitly says "Lots of work has been done in open source realms to create modern, and improved, versions of these interpreters for pretty much every device imaginable."
That opening sentence may be a bit clumsy, but what it's trying to say is that the games don't run directly on hardware on any of these machines, but instead runs in an interpreter.
Right, but those interpreters have been available for decades. That opening paragraph is an attempt to generate hype based on a false premise. That a sentence tacked on at the end of the second paragraph completely obviates the problem set up by the introduction only underlines the point: this article is much ado about nothing (blogspam) so we’d be better off linking to and discussing the original source.
The details about the original interpreter are what is most interesting for the Hacker News audience, and that’s been buried by that clumsy attempt at sensationalist journalism. For anyone here interested in playing the old games, my original comment gives them the details directly.
The point isn't that interpreters weren't available. It's that the original source wasn't available. The blog post talks about comments and variable names, that's what is valuable here.
It's surprising that something as simple as reading a file is slower in the Rust standard library as the Python standard library. Even knowing that a Python standard library call like this is written in C, you'd still expect the Rust standard library call to be of a similar speed; so you'd expect either that you're using it wrong, or that the Rust standard library has some weird behavior.
In this case, it turns out that neither were the case; there's just a weird hardware performance cliff based on the exact alignment of an allocation on particular hardware.
So, yeah, I'd expect a filesystem read to be pretty well optimized in Python, but I'd expect the same in Rust, so it's surprising that the latter was so much slower, and especially surprising that it turned out to be hardware and allocator dependent.
It's just the spin of it that threw me off. You're right: "why is a C implementation so much faster than a widely used Rust implementation" is a valid and interesting question. But phrasing it as "why is a Python function faster than a Rust function", when it's clearly not the comparison at all, distracts from the real question.
They are using FreeRTOS, communicating over a CAN bus using CANopen. Looks like this is a shutdown routine, shutting down various devices. They seem to have separate tasks for propulsion control and GPS.
It's flexible, and there are LEDs and linear optical sensors set up with an occluder in between that casts a shadow (or passes a light through a slit, according to the patent). The sensor detect where along the sensor the shadow or light falls, which indicates how much you have translated or rotated the control in a particular axis.
And running into these kinds of questions, both in a single project that evolves over time (rustc) and a separate project, help to feed information back into what you need for a formal specification; which is something that is being planned out. Having a second implementation can help find these areas where you might need to be narrower or broader in your specification, in order to clarify enough for it to be implementable or broaden it enough to accommodate reasonable implementation differences.
They are not trying to diverge in language implementation, but there will always be simple compiler bugs, which may crop up in one implementation but not another. For instance, some LLVM optimization pass may miscompile some code; gccrs wouldn't necessarily be trying to recreate that exact bug. I think that "bugs, quirks, and all" really means that they aren't trying to fix major limitations of rustc, such as introducing a whole different borrow checker model which might allow some programs that current rustc does not. They're trying to fairly faithfully recreate the language that rustc implements, even if some aspects might be considered sub-optimal, but they aren't going to re-implement every ICE and miscompilation, those are places where there could be differences.