Imagining Elixir 2.0

You should be realistic – the core maintainers aren’t going to hard-fork their own language core and then maintain two copies. I agree with your sentiment overall – and it has been said by people much smarter than all of us here that a perfect software is achieved when you cannot take away anything more.

But in real life we cannot be gods and sometimes we have to maintain past mistakes – or simply a baggage we no longer need but others do.

The way to go about it isn’t to divide the community – which is what will happen if your proposal to remove some functions is implemented. The way to go is invest in good educational materials that can show some of Elixir’s gotchas right from the start (like using Erlang modules for a number of scenarios instead of emulating the functionality in Elixir and/or including wrappers in your app).

The “variations” part doesn’t seem like a good example - fetch vs get isn’t the greatest API, but smashing them together and then control-coupling to an option list isn’t great either.

Re: “where cruft and redundancies have been removed for better performance” in the conclusion - is there any research measuring the performance impact of having unused functions in Elixir? There’s definitely an impact in client-side-Javascript-land, but that’s a very different environment.

It’s as simple as publishing a new release.

Unless you’re saying :ecto, "~> 3.0" and :ecto_sql have somehow “divided” the community??

A great example that already exists in Elixir is IO.inspect/2-3

It’s very powerful and very convenient.

To your point, right now I need to remember the distinction between two functions, as captured by somewhat arbitrary naming.

An options list is more explicit and more powerful. If I ever want to change my code, I just add an option instead of having to use a whole new function.

Think about it.

Re: cruft and performance, I’m referring to compile time.

That’s a big part of how Elixir is able to announce it’s faster with each release.

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.

I’m confused. You said it’s used in ExUnit. I’m not necessarily saying that’s the right home for it, but…

Let’s look to another example: Erlang.

When you start a project in Erlang, instead of just getting :elixir by default, you get 3, IIRC.

One could argue that Erlang’s packages are too modular… and I’d agree with that!

But by the same token, I’d say Elixir’s core has some things that could be revised.

Now if 1.8 truly is the slowdown point, fine. It’s small enough.

But again, Valim’s whole argument for not adding new functions to say ExUnit (such as 2 that I proposed) is the notion that Elixir should be extensible.

At the end of the day, I think there’s a double-standard: the Core Team adds things even when the separation of concerns is poor or unexplained. And when I worked off of that, suggesting 2 macros, I get this line about extensibility.

The irony is I agreed with Valim’s point in principle, so I’m confused by the resistance here when I apply this same principle to the core itself…

Putting anything in the language core is a permanent commitment.

There are two things at play: What happened until now and what happens in the future.

I’m sure there’s stuff in the core, which could be removed. Though I’d expect all those to be deprecated and simply to not be removed because of not having breaking changes. All the rest therefore is there to have the elixir version we have today. That version is what José said is what he and the core team is happy about and what they refer to as essentially feature complete. Afaik any additional features following up should only be added if they really can’t be done in an external package (e.g. see the discussion about private modules) or otherwise greatly benefit from being in the core. It’s probably not their intention for people to now go and see what can be split out of current elixir, because it could’ve been an external package. Doing that would make it a different elixir to what we have today. Also a good stdlib is not a minimal one, but one, which is just right. Enough to get people up to speed, small enough to not feel bloated for a good amount of usecases (like embedded work will always fight for a few MB less) and powerful enough to not have people miss more or less essential functionality. Maintaining balance is the hard part here.

I’m confused where you disagree with me.

I’m saying the same point.

I’ll just say this: I think the core lacks order.

And while I don’t have the power to deactivate posting, please know that my intention was not a debate but rather a discussion.

And I am genuinely disheartened by the response