Out of curiosity, will Elixir v1.6 dogfood its own property tests much, or is it going to launch with the suite more or less as-is, with the goal of instrumenting it further in the future?
christhekeele
0
josevalim
Creator of Elixir
rvirding
Creator of Erlang
How do you intend to migrate to something like QuickCheck to get the added features it provides?
1
tmbb
josevalim
Creator of Elixir
It should be a matter of not importing ExUnit.Properties and importing the QuickCheck stuff instead.
0
rvirding
Creator of Erlang
I was just wondering why not use QuickCheck itself and its Elixir interface? I suppose one reason is that apart from the Mini version it costs money. 
1
tmbb
Well, I suppose some people must be paying for it, and probably some of them are using it with Elixir, but it’s not the kind of thing you can bundle with Elixir xD I think this package might actually serve as a getaway drug into the really good stuff lie QuickCheck.
1
doomspork
I’d like to know this as well. When there are existing tools that do the job and then some, there should be a reasonable argument against them beyond wanting to write all of the code yourself. The few folks I’ve talked to about property testing all suggest that migrating to QuickCheck is an inevitability because it offers so much more than other solutions and has more miles under it’s belt. If you know the destination, why not focus on getting there?
It’s great to want to build everything yourself and it is a wonderful exercise but at some point reinventing the wheel becomes unproductive. Especially so when we’re talking tools that people and businesses are building their livelihoods on.
While an interesting point I think it brings up the original question of why the core team needs to be chasing this. If there’s already a better option why not focus on delivering features that lack mature solutions instead?
These are valid concerns which I’ve heard from a number of individuals as well as organizations evaluating Elixir, longevity is a concern many of us share.
What brought me to Elixir was the community and what felt like an opportunity to participate in the evolution of the language and the ecosystem on which it depended. That’s why I’ve spent the time to build and grow Elixir School among other projects. What has disappointed me in recent months is the feeling that the community was fading because without a community there is no future. It seems as the language’s popularity has grown, and there is more to be gained by those involved, the sense of community has begun to dwindle. We’ve seen a slow down in jobs because what was a surge of companies switching to Elixir has turned to a trickle and we’ve even seen companies abandoned it after investing time and money in the language. There are a lot of questions to be answered about Elixir in general if we’re expecting people to invest their time and for companies to take the risk of adopting it, so I applaud @josevalim for taking the step to start these conversations with community. I hope this is not an exception but rather a trend where the core team is proactive in engaging the community and not reactive.
There’s no hiding how much I enjoy and I care about Elixir, everyone knows I’m quite passionate about it. I happily spend my time on Elixir School, open source projects, mentoring, and training all of which I do for free in an effort to better the community and ensure a long life of Elixir awesomeness for all, but I would be remise if I didn’t say I shared some concerns for the future. Decisions should be made that drive the language forward and be done so in a way that seeks to involve everyone, not just a small group of friends and co-workers.
“None of Us is as Good as All of Us.” — Ray Kroc
Thanks again for doing this @josevalim. I think it goes without saying but we’re all grateful for the work you’ve done.
1
josevalim
Creator of Elixir
That’s literally one of the questions I have answered in the initial post. 
I mentioned three points in there. To recap:
It is not only about us wanting to write all of the code. All of Elixir is open source and I would say that including a library that is not open source as part of Elixir would go against the openness of the community that you outlined later on in your message. Finally, a solution written in Elixir allows us to better integrate it into the language and provide a more streamlined experience since it works on Elixir data types.
Just compare how Elixir has embraced OTP throughout the years. The fact we decided to make it part of the language instead of delegating to :gen_server (as we did before v1.0) led to the development of modules such as Task and Registry. Sometimes you may need to resort to the Erlang docs but by then you will be familiar with most concepts. This is possible because we took the first step and worked on making our tools mature.
I am glad you enjoyed the discussion although I would say this is an unfair assessment because Elixir development has always been open. As soon as the prototype for stream data was validated and it became clear to us it could bring benefits to Elixir, we had its version announced on both the mailing list and on Elixir Forum. Some of the questions I have answered here were actually asked and answered in the announcement discussion more than 2 months ago, including why we decided to have our own implementation. All other features that could be in the next version of the language are currently listed in the issues tracker and anyone can join the discussion.
So us being proactive is not an exception nor it is a new thing. It has been happening for the last years on the forum, mailing list, events and any other channel where people join and ask, especially because we can’t guess everyone’s concerns and having an open communication has always been the best way to go.
Maybe there is an issue of visibility of information and if that’s the case, we should definitely address it. But I definitely do not agree this thread has “started the conversation with community” because conversations like this one have always been ongoing.
Thanks for voicing your concerns!
3
josevalim
Creator of Elixir
To show more examples that we have always been proactive in discussing the major new features in every release, I will link to examples of flag features that have been proposed and discussed with the community:
v1.5 - Behaviours, defimpl and overridable
and a follow up later on about child specs in Goggle Groups. We also explicitly reached out to many other members in the community, such as book authors.
v1.4 - Registry
The Registry is one of my favorite examples because the community stepped up to validate that the Registry was indeed scalable, running benchmarks on machines up to 40 cores.
v1.4 - On GenStage and Flow not being added to core
When we decided GenStage and Flow should not be part of core, we communicated that too:
v1.4 - A declined proposal: removing char lists
This is an actually nice example of where we forgot to communicate why we decided to not add a feature. Then folks asked for clarification and we rectified it.
v1.3 - Calendar
This one we worked directly with Paul and Lau which were responsible for the existing calendar implementations and we came up with a proposal for the data types:
This one has no discussion on Elixir Forum because I believe that’s about the time we were starting to ramp up on the forum. That’s why you won’t find previous proposals on the forum although they have always been on the mailing list.
All other proposals above can be found in the Elixir News section in the forum (which is what I did right now) or by searching in the mailing list.
Everything else
You would find the other features and bug fixes in previous releases in the issues tracker. Those don’t have proposals because they are smaller in scope. You will also see that many of them have been implemented by the community and not the core team.
v1.6 - A counter-example: the code formatter
There is actually a counter-example where the development happened behind “closed doors”. This was a deliberate decision because style discussions can be quiet opinionated and heated. So unless it is clear to everyone that the goal is consistency and not personal preference, it can be very hard to make progress (and we did have some heated discussions in the core team! 
).
Still, when the prototype was done, we merged it into Elixir and got more than 200 PRs from 84 people over the course of 3 days to format the Elixir codebase. The feature is in master now, about 3 months before the next release, for anyone who wants to give it a try.
12