> I don't think any of the folks who are part of it are language designers
Ugh. Hate this sentiment that some people are language designers, and others simply aren't. So pretentious. If someone is designing a language they're a language designer, they don't need your approval.
And yes, designing the distribution, branding, community, and leadership around a fork of an existing language counts as designing a language. Just because the speaker's "team" seems to be lacking in those aspects doesn't mean they aren't an important part of language design.
Regarding the "full find and replace", they haven't gone through to change path names because that'd cause far more trouble in synchronization with upstream than it's worth. Accordingly, they haven't changed source text that references those path names. Knowing which changes are appropriate versus the ones that aren't takes far more "language design" know-how than simply doing the "full find and replace" the speaker suggested.
The fundamental critique here is that a language effort needs technical credibility to attract a critical mass of contributors, even if the effort is solely for leverage. Arguing that a CEO is technically a designer because they make decisions on branding and leadership is an evasive dodge in the form of a critique.
At some point in the creation of a restaurant one may wish to inquire on the chef leading the kitchen without getting into a debate as to whether the maitre d' is also a chef.
I don't think they do need technical credibility to "prove" themselves as a fork.
If it were the case that all was well in Zion and nobody had any desire to leave Rust, then sure this would need to make a compelling argument on technical grounds. But that's miles from the truth: a large number of folks involved in Rust have wanted to leave it, and not on technical grounds. If this is the fork that can attract people who have technical chops but don't want to deal with the Rust bureaucrats, good on them. The progress made so far in splitting off while maintaining upstream compatibility seems genuine and nontrivial.
It seemed quite pretentious and dismissive to me too. Sorry, didn’t intend to imply I agreed fully with the quote. But there is a deeper point which is part of our root comment: is it a genuine effort or a negotiation tactic?
False dichotomy. It's a step forward toward a better experience for all who want to write systems code with strict ownership semantics. It may be acting as a negotiation tactic now, but it's existence is only possible as a result of genuine effort of the folks involved in its creation. And if it's existence causes Rust team members to continue to publicly out themselves as pretentious try-hards who take the B out of BDFL, then it will become more and more genuinely important and useful for someone to have already put the work into maintaining a real fork.
Ugh. Hate this sentiment that some people are language designers, and others simply aren't. So pretentious. If someone is designing a language they're a language designer, they don't need your approval.
And yes, designing the distribution, branding, community, and leadership around a fork of an existing language counts as designing a language. Just because the speaker's "team" seems to be lacking in those aspects doesn't mean they aren't an important part of language design.
Regarding the "full find and replace", they haven't gone through to change path names because that'd cause far more trouble in synchronization with upstream than it's worth. Accordingly, they haven't changed source text that references those path names. Knowing which changes are appropriate versus the ones that aren't takes far more "language design" know-how than simply doing the "full find and replace" the speaker suggested.