Stream data supports only stateless generators and QuickCheck goes way beyond.
We wanted something that is included as part of the language. See the “Why have our own implementation of property testing instead of using an existing implementation?” section in the main post.
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?
Probably the latter as we still need to merge the library.
How do you intend to migrate to something like QuickCheck to get the added features it provides?
I don’t understand exactly what you’re asking. Could you explain a little?
It should be a matter of not importing ExUnit.Properties and importing the QuickCheck stuff instead.
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. 
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.
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.
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!
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:
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.
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.
When we decided GenStage and Flow should not be part of core, we communicated that too:
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.
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.
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.
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.
Sorry for keeping on adding replies but this is a thread to answer questions after all. 
I definitely have this concern too. What if I am ran over by bus? What if get bored of development a la Office Space?
It is one of the reasons why development and communication is open. If I disappear, hopefully the language goals and ideals have echoed to many developers who will be able to carry the torch.
That’s also why we have a core team and I actively delegate areas of the codebase that I have been the only person to work on to the other team members. In Elixir v1.5 there has been an effort in improving the Elixir compiler internals where I put little work exactly with this concern in mind. Overall the code is well tested and well documented.
And that’s also why I love initiatives like Elixir School and Elixir Forum, because they are run by the community and for the community, without any involvement of the Elixir team.
Finally, It is also one of the reasons why I said many times, including in this thread, that we can only add so much to the language:
A big language does not only fragment the community and makes it harder to learn but it is also harder to maintain. It is also why the language was designed to be extensible: so the community could build what is necessary without a push to make everything part of the language.
This leads me to the next topic.
For those who joined Elixir early on, it definitely has become harder and harder to participate in the language evolution. I don’t dispute that. However, I don’t think it is because of lack of communication, which hopefully I showed above is still on going and present, but because of many other factors:
When someone asks me how to contribute to Elixir, I always talk about the community and the ecosystem. That’s where the focus should be.
This is exactly one reason why stream_data should be included in Elixir: so that you can use it on the standard library to guarantee everything is as well tested as possible, and the invariants in the library are as well specified as possible.
This is exactly the right approach. Elixir allows you to perform arbitrary transformations on the AST in your code (AKA macro) and a great way to include arbitrary code from external sources in your project (AKA hex.pm), and the way forward is to use functions and macros and not adding new syntax or special forms to Elixir itself.
One might add functions and modules to the standard library if they prove very useful, especially as new OTP releases make those features possible, but I’m glad the “language” itself is mostly dead and most “improvements” happen on hex.pm and not on Elixir itself.
I’ve never contributed to the “language” directly neither in the form of actual code nor in the form of design discussions (although I might have done so, if you count stream_data as part of the “language”). But for what it’s worth, I have found it extremely easy to contribute to a core component of the Elixir documentation workflow (ExDoc). For the record, @josevalim himself has been very open regarding:
I have also raised multiple issues regarding design decisions in stream_data and both @whatyouhide and @josevalim were very open in discussing the pros and cons of each position, and such discussion led to actual changes in stream_data’s design. For interested people reading this, there are some issues that could probably use some extra input, like the proper way of shrinking floats.
I started typing a reply to this last night but fell asleep as it was 5am… José has covered everything but I just wanted to add that we’ve witnessed somewhat the opposite to Sean here on the forum and since it’s been raised, what we are trying to do to help José and Chris as the community grows.
With regards to community involvement, José has consistently posted in the elixir-news section with lots of threads seeking feedback (many more in his post above). Chris has done the same in the Phoenix Forum and quite often discussions that have taken place have led to quite fundamental changes or even minor (but helpful nonetheless) tweaks.
In fact many a time I have heard people mention that it’s a huge plus having the core team active in the community - which is in contrast to other languges such as Ruby where the majority of the core team do not speak English.
Having said that, I completely appreciate that as a community grows it does indeed become more challenging to get everyone involved. Again José has highlighted many reasons why that might be (and the fact that there’s more people to get stuff done is a great problem to have) but I think it’s also worth adding that when it comes to discussing important decisions - as a community grows it becomes significantly more time consuming reviewing (and sometimes responding to) everything everyone says, particularly when you’re discussing things with people of different backgrounds and levels of understanding or when discussions diverge. Just as an example, if you look at José’s last few posts in this thread these must have taken at least an hour or two of his time.
There are tools and strategies we have and can put in place (such as post likes) that can help. By also putting the onus on to people to do their best to be constructive and demonstrate their pov as effectively as they can (so the good ideas attract lots of likes, and the not so good ideas can be openly challenged) it somewhat alleviates some of the pressure from the core team as they can quickly see which ideas are gaining traction, and hopefully someone has already addressed issues that might otherwise require a response from them (as might have happened in this thread had I not fallen asleep 
)
I’m acutely aware of the burden a growing community can have on the core team/s and part of the goal of this forum is to help and support them, José and Chris as the community grows in a way that eases as much of that burden as we can while still remaining open and receptive to new ideas while moving the conversation forward It can be a tricky path but I think we’ve done a good job so far but I’ll let everyone else be the judge of that
The only other thing I wanted to comment on, is that again from my perspective, I sense a huge sense of community - at least here on the forum. I often get messages from members saying how much they love being part of this community and how it is one of the best communities they’ve ever been a part of 
Thanks so much for responding, apologizes if I have to reply back in in spurts @josevalim!
Truth be told I didn’t know you were using the forum because of how strongly you advocate for the mailing list but that is a welcomed change. For that reason alone I will commit to using the forum. As for the mailing list, it makes me cringe. Whenever I see people eager to participate get shut down and told to go the mailing list, I cringe. It happens a lot. I’m not the only person who dreads hearing about the mailing list either. No other project that I contribute to relies on a mailing list except an old Apache project.
There are so many better options to have conversations that are more intuitive and better suited to the task. I will spend my own money to have Elixir abandon the mailing list and move to something better. There is no disputing the number of active people on the mailing list is vastly smaller than Slack or Elixir Forum, plus there’s no need to have multiple conversations in multiple places about the same thing.
So visibility and organization of the information could use some work 
Right now news seems to be discussion and announced on the mailing list, the forum, IRC, Slack, and the occasional blog post by core members scatter amongst their own personal sites. Perhaps the Elixir-lang blog could serve as an aggregate for this information? The last blog post was in July. There’s a lot of exciting things that have happened between then and now that could have been covered. It’s obviously not @josevalim sole responsibility but there are other core members and the entire Plataformatec organization that benefits from Elixir. It would be wonderful to see more there. What can I do? What can we do? I would happily get involved as would any number of contributors to Elixir School but we’re not engaged so getting out ahead of things is nearly impossible.
Thanks again @josevalim
Both the Elixir Lang Talk and Phoenix Chat mailing lists have been deprecated in favour of the forum Sean 
Both José and Chris (as well as Robert Virding) are members of the admin team here as well
Welcome to the forum - it’s great to have you onboard 
(in case you haven’t seen it, we’ve classified Elixir School as a book )
Wonderful! When did this happen? I feel like I saw a mention of the mailing list not but a week or two ago on the Elixir-lang issues.
I had not seen it, thank you!
José first asked everyone on the mailing list to check out the forum around April last year, then a few months later deprecated the mailing list in favour of the forum
The Phoenix Talk mailing list was officially deprecated in favour of the Phoenix Forum in July
It’s possible it linked to an old mailing list thread or was referring to the language discussions mailing list? The language discussion mailing list and the Phoenix Core mailing lists are still active.
The Elixir News section exists for 1.5 years and I am the fourth most active user on the forum in terms of replies In some of those I am helping folks out but in others we are also discussing features and improvements to the language.
As with everything in life, many folks actually complained when we moved to the forum because “email is an established mechanism for communication”. Some discussions are more active here, others are more active on the mailing list.
The only place we reject feature proposals is the issues tracker. Because I have managed open source projects more popular than Elixir and if you don’t keep the issues tracker focused, then it becomes unmanageable, and then everybody loses.
The blog has a much wider reach so we are careful to announce projects like StreamData and GenStage only when they are ready to the general public. We are planning to announce StreamData there too but not when we are still discussing if the main API will be check all or something else.
That’s why we announce on the forum and on the mailing list, so we get the attention of the folks who are willing to try beta software, find bugs, contribute features, take part on conversations, etc.
Maybe a good compromise would be a “What’s new in Elixir master” as a monthly post that sums up what has been added to Elixir - it may be a suitable solution for those who are curious about what is coming in Elixir but are not able to follow its development closely. What do you think? Is anyone interested in picking this up?
At the moment I am also working on a document that outlines Elixir’s development process on the website so it answers many of the questions you and others raised here.
This would be terrific! I’m happy to help in any capacity.
Thank you, this would be a welcomed addition.
© Copyright Elixir Forum | Terms | Privacy & Cookies
