You will find this is a very controversial statement. I’d say people who create and maintain languages are likely to disagree.
Nothing much to be disheartened about, do you have some sort of a huge blocker working with Elixir?
dimitarvp
English3000
Again, were it up to me, I would have closed this, as it is a debate not a discussion. But given the debate continues, I must continue making my case.
Elixir lacks order in that there is no objective criterion for what does or doesn’t go in the core.
The Elixir team focuses on language features that:
- are necessary for developing the language itself
- bring important concepts/features to the community in a way its effect can only be maximized or leveraged by making it part of the language
These are heuristics. The core team determines what belongs and what doesn’t. Extensibility can be cited to avoid going in one direction while reason #2 can be cited to do so.
The problem, from an open-source standpoint, is that there is no system to consider new ideas (in my experience, just hostility). As a result, might is “right”.
I mean, so be it–Valim has done a generally great job.
It’s just frustrating…
I’ve already made the distinctions in my article from an organizational standpoint.
In terms of documentation, currently functions are arbitrarily put in alphabetical order. Again, I’ve already written this before, but just for visibility–the benefit is ordering is predictable; the downside is it is cluttered. Were an additional level of granularity to be added (like how modules themselves aren’t ordered completely alphabetically, but rather alphabetically within logically arranged groups–or like in Kernel where there is a second dropdown for guards), that would provide users the best of both worlds.
Last, in my experience, the codebase itself in certain places could be refactored for concision and clarity. Part of this is the scope of my article, and the other part is an experience I had trying to contribute to :ex_doc which isn’t part of the core.
0
English3000
Whatever the case, whatever the reasons, it doesn’t really matter. The great thing about tech is even if a bunch of people don’t like the sound of one’s idea… one can simply build it.
For those of you who are interested in what I have in mind, please feel free to check out my gists.
0
josevalim
Creator of Elixir
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.
30
josevalim
Creator of Elixir
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.
5
ssboisen
@josevalim have the Core team considered changing or improving the syntax for pattern matches on and construction of maps?
One of the changes I would love to see is ability to only having to specify the name of the key and get a variable of the same name:
%{ name, age } = my_map
or only specify the variable names and get keys using the same names:
name = “Jose”
my_map = %{ name }
This is similar to how clojure does it and especially newer js syntax.
0
LostKobrakai
This has been requested a multitude of times and rejected every time. See also: A story of regret and retiring a library from Hex – Andrea Leopardi
1
blatyo
Conduit Core Team
I tried to get that added to elixir, but there was a lot of opposition. https://forum.elixirforum.com/t/proposal-add-field-puns-map-shorthand-to-elixir/15452
I don’t see that changing. I think the best option at this point would be to implement %/2 in Elixir instead of a Kernel.SpecialForm, so that you could at least do that with structs.
2