>to avoid people depending on it before it was ready, why had I been hearing about it for so long before this?
There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.
I think it's as simple as comparing the the community dynamics of 2 different timelines:
- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0
- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0
Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.
> Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
Yes, and it's open source, and more to the point, it's because the developers do genuinely seem to want feedback and interaction with the community. That's ostensibly the entire point of having public release announcements, which Mojo has had before 1.0.
> The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
That does not seem accurate in terms of what I'm asking about here; if I'm reading the history right, Swift was not open source until version 2.2.
It's still not clear to me how any what you have said addresses what I'm asking: how does being closed source solve the problem that's cited as the reason for it being closed for so long, and why wouldn't not marketing/releasing the language at all be the actual solution to those sort of problems?
There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.
I think it's as simple as comparing the the community dynamics of 2 different timelines:
- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0
- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0
Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.