Yeah, on the flip side Apple is putting some serious engineering resources / funding in it. With Rust it is always creating committees, teams , sub-teams and so on and to actually do implementation there are far fewer resources.
So overall things balance out even if not big win for either.
Swift: Close process + big funding -> fast implementation / less feedback
Rust: Open process + little funding -> slow implementation / lot of feedback
Also even with lot of feedback many community members in Rust are already claiming very new features like Async in Rust are deficient in parts and feels rushed.
This feels intentionally ignorant of the state of Rust considering there is more funding and more people paid to work directly on Rust than any prior point in the project's entire history.
I am also best paid person today than any prior point in my entire employment history. However that does not mean my total compensation is anywhere near Google engineer or even in same magnitude.
Isn't that what normally happens when the language has important in-house use cases?
>Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.
I understand why Apple has a vested interest in maintaining control over the language. What I'm saying is that this puts Swift at a disadvantage in terms of broad adoption and the odds of the language surviving its creator leaving when compared to a language like Rust that has real community involvement and is perceived by everyone as more neutral.
If you look at the top of the page with Chris' comment, it looks like the Swift team is moving to address this:
>In the coming weeks, we hope to introduce a new language workgroup that will focus on the core of the language evolution itself, splitting off this responsibility from the core steering of the project. The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions.
It's less this one person's (Chris) presence or absence and more the sanctioning (implicit or not) of shitty behavior from some other person or persons.
Yep. I'm not a fan of people who think yelling is a normal part of debate.
I think this comes down to Chris being a very busy person who has better things to do with his time than argue about the direction of a project he no longer controls.
