Readit NewsWhat I mean is that a 70% score is meaningless to me. I need to know the movie genre, the audience score, the age of the movie and then I basically do a “lookup table” in my head. And I have that lookup table because I’ve looked up every movie I’ve watched on RT for 15 years so I know how the scores correlate to my own personal opinions.
As an example: the author said that critic scores should align with audience scores but no that’s not true at all. Critics tend to care more about plot continuity, plot depth and details while the audience tends to care about enjoyability. Both are important to me so I always look at both scores. That’s why a lot of very funny comedies have a 60-69% critic score but a 90%-100% audience score — because it’s hilarious but the plot makes no fucking sense and has a million holes. And if you see a comedy with 95% critic but 70% audience, it will be thought-provoking and well done but don’t expect more than occasional chuckles.
I wonder if audiences can appreciate these movies more than you give them credit for?
Let’s try a few more
- Death of Stalin (94%, 79%) has the pattern you’ve predicted.
- O Brother Where Art Thou? (78%, 89%) has the opposite of the pattern.
- Grand Budapest Hotel (92%, 87%) was appreciated by both, like American Fiction.
I’m just not seeing a pattern here. Looking at comedies that fit your description the critics and audience scores don’t follow a predictable 95%, 70% pattern.
People are 7x more likely to be using VS Code, which means that a niche tool is far more likely to have a VA Code plugin than an ST plugin.
Other than that, if the 11% of people using it are happy then there’s no issue.
So obviously the only way they could to this is with government contacts meaning the government themselves could already do it, but a lot of immigration stuff everywhere is full of people taking kickbacks.
They need an external customer for the fab so they can iterate and work out the issues. It’s anyone’s guess if someone trusts intel to manufacture on their behalf instead of sticking with an established player. They’re stuck in a chicken and egg situation - can’t reach high yields without a customer, but a customer only wants to sign up if the yields and future deliveries are guaranteed.
Intels only hope might be that someone, not naming names, coerces an established company to sign up.
It would be good if the Indian government could block the scammers but I guess it’s a lower priority for the moment.
A language reference is like documentation and a language specification is like a contract. If I uncover behavior in a system that isn’t documented, then I will update the documentation. But if the behavior fails to match the (formal) spec, then the system is at fault for not meeting the expectations of the contract, and the system needs to be corrected. As https://github.com/rust-lang/rfcs/pull/3355#issuecomment-134... states:
> If you built a rocket and that rocket crashes, you wouldn't update the spec of the rocket to say "it is expected to crash after reaching 3000m altitude". But if you made a typo that says the rocket should crash after reaching 3000m altitude and somehow passed review, you wouldn't add a self detonation device into the rocket just because of this either.
In contexts like safety critical/offline environments, the consequences of unexpected behavior can be dire and hard to fix in the moment (e.g. airplanes in flight). Liability becomes a real concern, and outside parties need a "contract" to be confident certain expectations or behaviors will be met in perpetuity. The reference doesn't offer that guarantee, and has understood itself to be a best-effort technical reference, despite attempts to increase its authoritativeness into a spec https://github.com/rust-lang/reference/issues/629
My opinion is that the spec is actually more needed for people inside the language than for people outside. Like the contractual element of a language spec fulfills a constitutional, if not judicial role, in the development process. However, I've learned requires a level of integrity that Rust can no longer hope to achieve.
My perspective of following the compiler development is that very often much needed features aren’t developed because of outside constraints - lack of a person to push it through, lack of consensus on how to implement it and the codebase not being built in a way that supports the feature at all.
A couple of features spring to mind - partial borrows of strict fields by methods and several “obvious” improvements to the type system. I think everyone wants the first feature but it’s hard to implement in the current borrowchecker codebase. Similarly, many features are blocked on the next gen trait solver because the current one is crusty and difficult to work with. Fortunately, I think they’re relatively close with the latter. I believe rust-analyzer is moving to the new trait solver and perhaps rustc will in the future as well. That will unlock a lot of improvements and importantly, fix many soundness issues in the compiler as well.
I can see where you’re coming from. A spec that you can point to allows a user to report a bug with some authority - your implementation is failing to adhere to the spec you wrote. Therefore this bug should be prioritised. And maybe this will lead to higher quality software.
The other perspective is that I’ve seen a lot of good developers, who have a lot of context on the project, leave the project. The reasons vary, but I gather burn out is a common one. They like their coworkers, they like the impact they’re having, but they don’t like a lot of the problems that come with maintaining a large open source project. Entitled people, drive by commenters, a codebase that has developed in layers over 15 years, slow feedback loops on RFCs. I fear that if we added people demanding fixes because of spec adherence, it would be one more source of burnout. This could slow down development as more people leave.
The folks working on the new trait solver are aware of the issues in the existing trait system. You can see all the soundness issues, many of which are tagged T-types here (https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...). They really want to fix these, and they hope the new trait solver makes it easier to get there. The constraints of the implementation appear to be driving which soundness issues get worked on. Issues have been paused with the hope that they will go away or be easy to fix with the new system. All energy goes instead to migrating to the new system.
Would it really help if someone said that hey, according to the project constitution, you’ve committed to fixing spec violations before you do feature work like new trait solver. Maybe, I don’t know. My experience with spec driven development is limited.
But my intuition would be to trust the people who’ve done the development so far. They’ve done a pretty good job of producing a successful, performant language. They’re able to add features much more quickly than most other comparable languages while maintaining a high degree of stability. They’ve supported an ecosystem that has roughly doubled in size every year for 10 years. If they want to do spec driven development, sure. If they don’t, that’s fine with me too.
I want them to choose a development system and a quality bar that they’re happy with. Today it’s RFCs and crater runs. Tomorrow it could be spec and spec. If they’re happy, I’m happy.
IMHO, I'm familiar enough with the spec effort to say that the GP and other naysayers are basically right. Despite my hopes, the effort to specify Rust has gone unwell.
In that case, I agree that the spec is different from the reference they’re building.
To try and understand where you’re coming from, you want the development of Rust to be similar to C++, where a group of people decide the spec and afterwards implementations implement the spec?
We don't know because we don't, and can't, have a competing compiler.
For all languages that have competing compilers they all improve on each other.
If you don’t know in what way Rust needs to be improved, you don’t know enough to be making confident pronouncements of what it needs.
And like I’ve pointed out before on this thread, a second compiler does exist. It could help with bootstrapping because it’s written in C++ but that’s about it?
Plenty of successful languages have just the one implementation. Python is a great example. Slowing down python development by making everyone proposing a new feature have to convince two separate teams to adopt it wouldn’t help either the Python ecosystem or the Rust one.
Frankly, this thread has gone like every other thread on this subject. Advocates for a spec and second compiler are unable to come up with technical arguments in favour of it. Instead they simply say “well I’ve seen it done by this other language, so it should be done here as well.” That’s just cargo culting.
The only thing different about this thread is hearing from people that work in progress spec and second compiler aren’t enough. No, it needs to be ready right now!!! Yeah alright.
People see what they want to see. They complain no matter what. Remember this thread started with “there’s no spec”, then “the spec work has been abandoned”, then “the spec work isn’t going fast enough”.
When they’re moving the goalposts this fast it’s hard to keep up. Especially because, like my other comment says, it’s not clear what they’d actually use the spec for.