Hacker News Reader

When people talk about a language being open source they primarily mean the compiler. A closed compiler surrounded by a collection of open source things is an anti-pattern and trap to be avoided if you're interested in open tools, that's why open sourcing the Mojo compiler was so important to many people.

> 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.

This I don't buy so much, as there seem to be a lot of core design decisions still up in the air: https://mojolang.org/docs/roadmap/

Chris literally was saying it from the very beginning (you can watch early interviews, obviously he was being asked about it), everything that happens with progressive opening is what he said he'll do and he gave rationale for it which is summarized by what parent comment says.

That doesn't seem to address what the parent comment says; they're arguing that the rationale for the progressive opening doesn't make sense, not that it didn't or wouldn't happen. If I say "I'm going to work on feature XYZ at work today because the sky is yellow and grass is purple", it would not make sense to defend my claim tomorrow by pointing out that I did work on feature XYZ.

> He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning

“Too soon”, I could believe, but “at the beginning”? https://en.wikipedia.org/wiki/Swift_(programming_language):

“Development of Swift started in July 2010 by Chris Lattner, with the eventual collaboration of many other programmers at Apple”

and

“It was initially a proprietary language, but version 2.2 was made open-source software under the Apache License 2.0 on December 3, 2015”

> 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.

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

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?

> 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.

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.

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.

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.

> 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.

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.

I don't understand that argument at all, unless you think that the only value of open source is in the potential for people to say nice things about your project. If you think there's inherent value in something being open source, you don't even need to have a Github repo (a tarball on your website with the source code is open source), and nothing anyone says would take away from that inherent value.

I'm firmly of the opinion that there's inherent value in being open source. I would honestly expect most developers to recognize that nowadays, but maybe I'm wrong. My concern is that someone who doesn't think this is the case is probably more likely to also not want to come right out and say it, because that would potentially prevent them from getting the value they're truly looking for from the stuff they do open source. The justifications that are being given here is that they seem to be heavily predicated on the value of open source being primarily from marketing rather than the very nature of code being open having value on its own, and I would be both surprised and disappointed if that's the opinion of the people in charge of Mojo. I'm sincerely hoping that there's something else going on here though, so I'm trying to give the benefit of the doubt and see if I'm missing something.

>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

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.

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.

>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?

> but you can also just ignore it.

Apparently, this isn't as easy for some people who are deeply involved

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

Has the title changed since you wrote this? It doesn't seem misleading to me. Misleading would be if it still wasn't fully open source. "It was partly open before" doesn't seem like it's worth a big warning. But that's just my impression FWIW

> 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 open source at the beginning.

Then he has learned the completely wrong lesson. Swift spent its first years floundering from breaking change to breaking change (from Swift 1.0 in 2014 to approximately Swift 5.0 in 2019) precisely because it wasn't open-sourced from the outset, instead being developed in the traditional airtight Apple fashion. In contrast, Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years pushing embarrassing major releases to an allegedly-1.0 language to fix problems that any actual user could have identified.

Well I think point was if they had gotten some fundamental things right from beginning they would not have to go through this 4.0 -> 5.0 breakage mess.

> Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years

One can keep pounding on this but endless discussions about pros/cons Rust Async model, library, framework bifurcation and shortcuts to deal with it does not seem like given an open design win that many in Rust community assume.

Going by the way Rust always seems to get inserted in any language related discussion no matter what, IMO it could a meme "What would Rust people do?" when deciding what should not be done.

I think a bigger issue than open source timing is the community governance necessary to shape a tool that serves the needs of a lot of stakeholders. Swift has lived under the shadow of Apple's (often secret) product priorities. The extremely poor backwards compatibility is why I invested in Rust instead, and I think Chris has expressed some misgivings about how the function builder stuff got added unilaterally. It appears what they're trying to do with Mojo is build a more coherent starting design with a closed process but the experience of client work, and then open having skipped over some of the teething issues. We'll see if it works.

> IMO it could a meme "What would Rust people do?" when deciding what should not be done

You betray your own ignorance here. Rust became massively successful despite having no corporate mandate or Big Tech progenitor, precisely because it listened to its users and empowered them to participate in the language design and development process. Trying to feebly gesture in the direction of Rust's async support doubly betrays your ignorance, both because Rust's async support is extremely good for its given design goals (not that it couldn't still be better), but also because you don't appear to realize that being developed in the open was what revealed the disastrous interactions between Rust's goals and the original pre-1.0 green thread runtime which characterized the language for a large proportion of its nascent development. Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.

> Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.

Well, one can always head back to their echo chamber to avoid hurt feelings, instead of telling others to not speak their mind.

"There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'" ~ Isaac Asimov, 1980

True. On positive side sometimes cult members do see wrong in their ways and apologize[1] . Sadly it is not always they will do that. Mostly they will spend time on attacking non-members.

1. https://blog.rust-lang.org/2023/05/29/RustConf/

> * Chris (also created swift)

He also created LLVM compiler

Also MLIR which is so prevalent in the ML compile stack everywhere.

https://mlir.llvm.org/

Also Clang and OpenCL.

Once they get an async story figured out I will be much more motivated to dive deeper into Mojo