Those are two very distinct examples.

The reason we added String.myers_difference is because we use it for ExUnit diffing. If we didn’t have ExUnit diffing, we wouldn’t have String.myers_difference. Originally the diffing algorithms were inside ExUnit exclusively but some developers asked them to be extracted. Since the feature was already in core, it made sense to be extracted. However, if it wasn’t on core and somebody asked to add String.myers_difference, then we likely wouldn’t have accepted it.

So there is a whole history of how things evolved and how myers_difference plays an important role in one of ExUnit’s most important usability features.

With that said, there is no denial that deciding what is worth enough to get into core is decided by the core team. There are heuristics in place. Those heuristics were created exactly because before there was nothing and the community asked us to write down our decision process for guidance. It is completely natural for us to refine the process as the language and the community matures. I am also completely aware that we won’t make everybody happy.

In fact, the whole point of saying “Elixir is slowing down” is exactly to signal to everyone that proposals most likely won’t be accepted. The most relevant features have already made into core. Sure, we may miss some excellent features as part of core by taking such stance, but there is no perfect system.

Look, I completely understand it is frustrating to work on something and have proposals rejected. I am also an open source contributor. I also get this end of the stick.

Heck, this happens even on Elixir itself. You can find examples here on the forum of proposals that I have put dozens of hours into it, describing the rationale, the pros and cons, answered questions from the community, and they were ultimately “rejected by the community”. Either because the proposal really wasn’t as good as I thought or because I could not get my point across.

Ultimately, if you believe that there is a double standard, there is nothing I can do about it, but my conscience is clear that communication regarding Elixir’s future improved steadily and that we are doing our best to apply our heuristics consistently. In fact, even you cited an example of a feature that was built by the core team (ExUnitProperties) and it was decided to not be part of language either. It is a case extremely similar to yours and the outcomes have been the same, roughly around the same time period.

Somebody (usually myself) needs to “say no”, which means I will get flack from time to time and is, honestly, quite exhausting, but that’s the best system I can think of.

List/String.myers_difference are not in the core out of pure luck, but because it’s needed by the core itself. It currently is used by the ExUnit diffing mechanisms to give you the really amazing diffs in errors. So they simply couldn’t be in some external package and it’s nice that they are kept public so other people can benefit from the efforts of having it in the core.

The difference though is that none of the options given to IO.inspect/2-3 change its return type. We generally avoid having an option change the return type because it makes the code harder to understand.

For example, if we were to merge get, fetch and fetch! into something, the following call Map.something(map, key, opts) could return {:ok, value} | value | :error | no_return. This can have a negative impact in static analysis tools like diaylzer, which may now have to work with this broad return type, and even affect features in editors, such as the typespecs autocompletion found in VS Code Elixir.

Sorry but it is unclear how the suggestions above would impact compile time and how it relates to the “Elixir is faster” announcements. Can you please expand? If there are ways we can compile libraries and applications faster, I would love to hear.