I don't understand. How does that make it not a fork?

It's a type of a fork but not the kind someone would expect after reading the headline.

The FAQ has a similar description, but doesn't make the assertion that it's not a fork, which I disagree with:

> Gren started as a fork of Elm. This is mostly considered to be an implementation detail, a way to speed up initial development.

> It's not a goal of Gren to replace, or stay compatible in any way with, Elm.

https://gren-lang.org/book/faq.html#what-is-the-relationship...

A fork is a fork. If Elm development was open to the community and the author could’ve just added Node support to Elm do you think Gren would exist?

Meh, it only happened to fork Elm to bootstrap early development and had no plans to carry on with Elm’s development nor trajectory. People in these comments are already confused.

The only interesting thing about Gren on HN is HN’s interest in Elm drama. I bet nobody here even mentions the language specifics but just meta discussion.

It usually isn't the best way to introduce it, but if you value clear communication it makes sense to say that it is a fork of Elm if someone wonders whether or not it is one. Otherwise you're venturing into territory where the meaning of words is arbitrary and only your favorite words to describe something are valid.

I think not, but only based on chaos theory. The author of Gren wouldn't be nearly as fulfilled though.

I could fork Linux, delete all the code, edit the README.md, and then relace it with say a nodejs CRUD app. This would be a Linux fork.

I mean Git by design, each commit is like a new .zip file. So "is technically a fork" and "is spiritually a fork" can be very different.

That would be throwing out the meaning of the word "fork" similarly but in a different way to denying how Gren started as a fork and thus is still one (though it's not the best way to quickly introduce Gren to its intended audience as a whole). There aren't simple algorithms to determine these things. It's the sort of job an LLM would be good for.

A fork where you diverge from the original is still a fork.

Most long-lived forks that I hear about are things that have developed into their own projects and have no intention of merging back to the original. Contrast with a short-term fork which will only live a few months and then will be hopefully be merged into the original; it will probably be so short-lived that people outside of the project won’t hear about it as a “fork” with its own distinct name.

A “fork” isn’t only making a GitHub fork so that you can make a PR against the original because you found a typo on the readme.

I think maybe the authors are using a strange definition of "fork": if you fork a project and then take it to a different direction, making incompatible changes from upstream then it's somehow not a fork anymore. I'm not too sure though if that's the thinking. (reading from https://gren-lang.org/book/faq.html)

Seems like a fork to me.

Or maybe the thinking is that they'll rewrite it from scratch at some point which would make it not a fork from code perspective.

I’m not claiming it is not a fork. It is.

That said, people expect certain things when you market something as a fork, so I’m a little careful in making that the first thing someone hears of the language.