3 ms·

>I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you wan

by jasode 2mo ago

>I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it. Deep link to Chris Lattner interview where he says he learned lessons from Swift being rapidly released as open source meant that early design decisions that were suboptimal caused quick revisions. This caused a lot of complaints when later revisions to Swift caused breakages. This caused a lot of stress for Chris & the Swift team so he says he didn't want to repeat that for Mojo. https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=2h22m05s https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=2h22m05s Sure, one can simple redo the exact same playbook with Mojo and iterate out in the open with early versions, and when people complain again about their code breaking, he can "just ignore it" but he didn't like that experience with Swift.

saghm 2mo ago
That doesn't clarify anything at all to me at least. If the goal was to avoid people depending on it before it was ready, why had I been hearing about it for so long before this? Something being marketed is not consistent with a concern to avoid having people rely on it and voice their opinions.
- jasode 2mo ago
  >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.
  - saghm 1mo ago
    > 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?

by jasode 2mo ago

saghm 2mo ago

That doesn't clarify anything at all to me at least. If the goal was to avoid people depending on it before it was ready, why had I been hearing about it for so long before this? Something being marketed is not consistent with a concern to avoid having people rely on it and voice their opinions.

jasode 2mo ago
>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.
- saghm 1mo ago
  > 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?