Questions about Property Testing / Stream Data

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! :grin:).

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 Likes

Sorry for keeping on adding replies but this is a thread to answer questions after all. :smiley:

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:

  • The language is no longer changing as rapidly so there are fewer opportunities to get involved
  • The number of features we are adding to the language is reducing (as it should)
  • The changes have become more focused and specialized (which requires more time investment to participate)
  • The community growth means the more accessible issues are addressed really fast because there is always someone ready to contribute
  • The community growth means discussions develop fast. If you join late, you will need to catch up on a big backlog (which is why I am very vocal about not side-tracking discussions)

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.

10 Likes

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:

  1. Discussing design decisions on how to make ExDoc extensible
  2. Reviewing and merging my PRs on how to implement such functionality
  3. Reviewing my own code that makes use of such extensions and even made some PRs to my code to cut unnecessary dependencies, although my code is unrelated to ExDoc itself

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.

4 Likes

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 :lol:)

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 :slight_smile: 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 :smiley:

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 :purple_heart:

8 Likes

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 :thumbsup:

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 :thumbsup:

Both the Elixir Lang Talk and Phoenix Chat mailing lists have been deprecated in favour of the forum Sean :003:

Both José and Chris (as well as Robert Virding) are members of the admin team here as well :003:

Welcome to the forum - it’s great to have you onboard :023: (in case you haven’t seen it, we’ve classified Elixir School as a book :003:)

3 Likes

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!

1 Like

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 :slight_smile:

The Phoenix Talk mailing list was officially deprecated in favour of the Phoenix Forum in July :slight_smile:

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.

1 Like

The Elixir News section exists for 1.5 years and I am the fourth most active user on the forum in terms of replies :slight_smile: 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.

6 Likes

This would be terrific! I’m happy to help in any capacity.

Thank you, this would be a welcomed addition.

5 Likes

Awesome! Would you be interested in writing those then? Should they be published on the blog with a link to the forum at the end for discussion? We probably need a better name too! :smiley:

5 Likes

Sure! I’m happy to help.

That’s a great idea, wonderful way to encourage conversation :thumbsup:

5 Likes

Perfect, I will ping you in private to figure out the details.

Meanwhile the Development page on the website is live: https://elixir-lang.org/development.html

Feedback is welcome!

5 Likes

TMiX → This month in Elixir.

A pun to all the “this week in X” known from other languages. Also a pun to our primary build tool which assemblies source code to modules and applications. Which the newsletter does as well in a sense

2 Likes

I like everything about it except the name. At least SOME indication that it’s about property based testing would be nice.

After its inclusion in Elixir, we will have two modules: Stream.Data and ExUnit.Properties. The library name (stream_data) will be fully gone by then. :slight_smile:

3 Likes

I’m curious, why the gen macro is part of ExUnitProperties. The other two macros are surely test related, but creating custom generators using the gen macro doesn’t seem like it would only be useful in a testing context.

1 Like

That’s a very good question. We have debated it as well as but it ultimately felt out of place in both ExUnitProperties and in StreamData. So we decided to go with a more conservative approach and keep it in ExUnitProperties. We can always add it to StreamData later.

1 Like

I’d put my vote on making it available with StreamData. I’ve created some date/time/datetime generators some time ago and just now also a version without depending on ExUnitProperties. The macro version is certainly more readable and also seems easier to understand for someone not intimate with the library. If I’d want to use them outside of a testing context (which seems to be the goal for the generators) I’d need to go with the less readable version:

3 Likes

I’m using StreamData with generators in my ProtocolEx sub-projects without using ExUnit anything (as it is a compile-time enforcement thing, not a MIX_ENV=test type thing, though those are used too).