Thanks for your answer @whatyouhide
It makes sense but at the same time I think there is a chicken and egg problem underlying your example with Ecto. I imagine the decision to go with custom language constructs came because it was beneficial to the Dev UX and popularity did not play a role in that choice (but it certainly helped it to become popular). I imagine that the Phoenix Router and its macros has a similar story.
So while I understand your point of view, I think it’s a strange standpoint for the community because a package developer might think “I won’t add funky constructs because my package is not popular (yet?) and that will look unfamiliar in the codebase of its users”, thereby missing an opportunity to become popular.
Such macros can be added anytime, no need to wait for 2.0 for that since they wouldn’t break anything. I agree though, would be a nice addition.
Good point! 2.0 is more of a personal deadline to try to advance a proposal, than a technical requirement. More what I’d like to see in 2.0 than would have to wait to see I suppose.
should you not ask many other people not to kill you 
My day job requires me to live through the seemingly endless churn of Swift changes so I’d like to see the 2.0 release notes simply be:
* New Version Number
I love the fact that Elixir releases don’t chuck in rafts of new functionality and are not trying to cater for every whim or desire. It’s a refreshing change.
4 Likes
Yeah, I was just thinking, what I want from 2.0 is “ten years from now, maybe never”
2 Likes
The Swift compiler is great at understanding code written for the previous revision; only enough to tell you that it needs to be upgraded for the current revision … and then it can’t statically analyze it once you upgraded it.
1 Like
