3 ms·

> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He

by saghm 2mo ago

> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully ope source at 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. Yes, they might write code that depends on things that could change, but until last week it wasn't even 1.0 anyhow, so it's not like stuff might not break for people even if they didn't do that. Why was the language even being marketed at all pre-1.0 if "scaling" too quickly is a genuine concern? The only explanation that makes any sense to me is that he (or his employer) just didn't really care about prioritizing making it open. That's totally fair, but being disingenuous about is not. It honestly just sounds like they didn't want to admit that they didn't care to prioritize being open source, and I think that has some potentially concerning implications for what to expect in terms of communication around the direction of the language and ecosystem in the future. The fact that it's being developed in the open now is good, but it doesn't seem like the actual decision making is, and that's a red flag.

LoganDark 2mo ago
Do you remember how long it took Python 2.7 to die after Python 3 came out? Years. It was horrible.
- saghm 2mo ago
  I don't understand the point you're trying to make. Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? I don't buy the claim that a pre-1.0 language only a few years old without widespread production use is comparable to one of the most widely used languages on the planet that had been around for close to two decades at the time of what you're describing. Even if I did think that was a comparable precedent, that still doesn't address the more direct point I made about marketing the language at all if this was a concern. What does being closed source do to prevent people from running old versions of a compiler to avoid updating their code?
  - LoganDark 2mo ago
    > Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? No, just saying it's happened before and it doesn't seem unreasonable to be wary of it.
    - saghm 2mo ago
      Okay, but by that logic, if I can point to one instance of something suboptimal happening due to software being closed source, then it's reasonable to be wary of that too. I don't see how this is a plausible justification for keeping something closed source in the absence of taking into account the likelihood of something similar happening here, and for the reasons I laid out previously, I think it's borderline absurd to claim that was a real concern in the timeline that Mojo was closed.
      - LoganDark 2mo ago
        People choose what to worry about. You can say it's unfair because they could've worried about a different set of things, but at the end of the day it's their choice.
        saghm 2mo ago
        I'm not saying you can't worry about this; I'm saying it does not seem to be a particular compelling reason for Mojo being closed source for so long, and I'm dubious that the rationale was due to anything like this.
        chambers 2mo ago
        > I'm not saying you can't worry about this The relentless demand for justification is indistinguishable from a demand for others to stop doing things you don't like.
  - geodel 2mo ago
    It prevents endless discussions on github, hurt egos when my precious PR is rejected by committers, and commentary on not being true open source because they are not welcoming source contribution, feature request, when they are trying stabilize compiler and so on. Now none of these are guaranteed to happen when it is open source. But at least it is guaranteed to not happen when its not open source.
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.
eviks 2mo ago
> but you can also just ignore it. Apparently, this isn't as easy for some people who are deeply involved
- conmod278 2mo ago
  E.g. GRRM avoids reading fan theories so that he doesn't change his writings to actively thwart them.

by saghm 2mo ago

LoganDark 2mo ago

Do you remember how long it took Python 2.7 to die after Python 3 came out? Years. It was horrible.

saghm 2mo ago
I don't understand the point you're trying to make. Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? I don't buy the claim that a pre-1.0 language only a few years old without widespread production use is comparable to one of the most widely used languages on the planet that had been around for close to two decades at the time of what you're describing. Even if I did think that was a comparable precedent, that still doesn't address the more direct point I made about marketing the language at all if this was a concern. What does being closed source do to prevent people from running old versions of a compiler to avoid updating their code?
- LoganDark 2mo ago
  > Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? No, just saying it's happened before and it doesn't seem unreasonable to be wary of it.
  - saghm 2mo ago
    Okay, but by that logic, if I can point to one instance of something suboptimal happening due to software being closed source, then it's reasonable to be wary of that too. I don't see how this is a plausible justification for keeping something closed source in the absence of taking into account the likelihood of something similar happening here, and for the reasons I laid out previously, I think it's borderline absurd to claim that was a real concern in the timeline that Mojo was closed.
    - LoganDark 2mo ago
      People choose what to worry about. You can say it's unfair because they could've worried about a different set of things, but at the end of the day it's their choice.
      - saghm 2mo ago
        I'm not saying you can't worry about this; I'm saying it does not seem to be a particular compelling reason for Mojo being closed source for so long, and I'm dubious that the rationale was due to anything like this.
        chambers 2mo ago
        > I'm not saying you can't worry about this The relentless demand for justification is indistinguishable from a demand for others to stop doing things you don't like.
- geodel 2mo ago
  It prevents endless discussions on github, hurt egos when my precious PR is rejected by committers, and commentary on not being true open source because they are not welcoming source contribution, feature request, when they are trying stabilize compiler and so on. Now none of these are guaranteed to happen when it is open source. But at least it is guaranteed to not happen when its not open source.

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.

eviks 2mo ago

> but you can also just ignore it. Apparently, this isn't as easy for some people who are deeply involved

conmod278 2mo ago
E.g. GRRM avoids reading fan theories so that he doesn't change his writings to actively thwart them.