v0.7.0, GitHub Organization, and Merging Atomic about concurrent-ruby HOT 22 CLOSED

What would people think about a policy of being an 'unopinionted' gem? As @jdantonio says we're a toolbox for concurrency, and in some cases that means some overlap between tools, and some aliases so people can find the method they're used to, but I think that's good. For example people can come to us for both promises and futures, without being lectured about which is better or why.

I think not having dependencies is part of being unopinionted: you don't have to use anything else to use this gem, and it's not a stack or a framework.

So I'm in favour of unopinionted and of no dependencies.

I'm also of favour of one big tool box at the moment - one gem. If we start dividing up I fear we'll keep going and end up with one gem per construct and a terrible nest of dependencies between them.

from concurrent-ruby.

I like that the gem doesn't have dependencies, I think that so far it makes sense. But we should also keep our mind open in case we need to add dependencies - we don't want to recreate everything, right?

from concurrent-ruby.

One Gem, or a Family of Gems

I like the idea of extracting actors from the lower level gem. I feel actors are an higher level abstraction that can be built over atomics-ivar-futures-etc and they are also maintained by a slightly different team (usually @chrisseaton and I are working on the lowest levels, but not on actors, for example)

External Dependencies

I agree with @chrisseaton and @lucasallan: we should avoid external dependencies. If we keep our gem well focused, after the @headius merge, we probably will not need anything else.
If in future we will create something requiring external gems, it will probably be another gem (like the actor in my previous point)

Native C and Java Extensions

I agree with you @jdantonio, our gem should be for everyone and Java or C extensions are only a way to optimize the code

GitHub Organization

What about a simple name like "concurrent-ruby"?

from concurrent-ruby.

I love the idea of being explicitly 'unopinionted'. For all the reasons @chrisseaton stated. If other developers want to build opinionated gems the wealth of tools we provide will make their job easier. We'll just keep building cool tools.

I agree with @mighe that if we were to pull anything out into a separate gem, it would be actors. Because there is no single canonical implementation of the actor model, any actor implementation is inherently opinionated. But I also think there is value in providing a simple actor implementation as part of a robust and varied toolkit. My vote is to keep actors for now and reconsider pulling that out at a later date if our implementation grows sufficiently large.

I'm fine with https://github.com/concurrent-ruby/concurrent-ruby for the organization/gem name if everyone else is OK with it. I know the name is fairly bland, but I think that's part of its charm. We aren't trying to be cute or edgy or hipster. To @chrisseaton's point, we're simply trying to create a robust, unopionated set of tools that, as @mighe stated, is for all Rubyists. The name may be unexciting but it perfectly states what we do and what we provide. It's unambiguous and unpretentious.

from concurrent-ruby.

Ok a few notes.

• At some point I tucked away https://github.com/ruby-concurrency for a rainy day. If we want it, I'll turn it over to the group. Otherwise I'll probably delete it.
• I like unopinionated too. java.util.concurrent can be confusing with many overlapping tools (Semaphore? Lock? CountdownLatch? SynchronousQueue?).
• I have not provided an abstract for my Steel City talk yet. My usual talk this year has been on concurrency, trying to promote concurrent-ruby and other libraries, as well as talking about the why of concurrency. I'm guessing @jdantonio submitted a talk on concurrent-ruby? Perhaps if your talk is accepted, we can figure out how mine can dovetail with it like maybe I give people the why and then direct them to your talk for the how).

Once we have an organization set up I'll move the atomic and thread_safe repositories in prep for merging. Once merged, we should do a final atomic release that just depends on concurrent-ruby, perhaps with an install-time message letting people know about the merge.

from concurrent-ruby.

I also like unopinionated as much as possible but concerning the "no dependencies" I can only repeat what I said on the other issue: If having no dependencies means swallowing everything that could be a depdency inside this gem then I think that's an horrible idea.

I think everything that may be used separately should stay outside (without going to the extremes), it's not like there much overhead to load two gems instead of one in any project and that way the basic pieces can still be used separately.

Part of my current work is development on small linux devices (not quite embbeded but still limited) and it's incredible the size your gems end up using if you are not careful and since, sadely, many gems have what I consider "stupid" dependencies you end up having to fork them or extract the code you need to keep a low profile.

As I said, just look at activesupport, there is a lot of useful things I won't deny that but when you use it in your project it feels like you use a nuclear reactor to light a candle... Is it really the path you want this gem to take ?

from concurrent-ruby.

The plan, then, is:

• Update the README and wiki with our goal of remaining "unopinionated"
• Update the README and wiki with our goal of remaining dependency-free, but reconsider in the future if the need arises
• Release 0.6.0 ASAP without the ActorContext spike.
• Create a "concurrent-ruby" organization in GitHub and move the repo (probably immediately after the 0.6.0 release)
• Give @headius commit access to the new organization so he can move his gems whenever it is convenient for him
• Create a roadmap for the 0.7.0 release, targeting the week before Steel City Ruby
• Plan the following updates for 0.7.0
  • New actor implementation
  • Pure-Ruby implementation of atomic references that matches the API of ruby-atomic
  • Merge of ruby-atomic that follows our current practice of "pure Ruby + platform-specific optimizations"
  • Merge of the experimental CRuby extensions
  • Gemspec configuration that is platform-aware and does not attempt to compile C extensions on unsupported platforms (based on the C Ruby experimental branches and the setup from ruby-atomic)
  • Update all Ruby mutex operations to follow the newly-agreed upon technique of explicit lock/unlock with ensure clause
  • Any other cool stuff we have time to work on between now and then

Is there anything I've missed?

from concurrent-ruby.

Sorry FJ probably won't make it this week - I have a lot of stuff at work now.

from concurrent-ruby.

• https://github.com/concurrent-ruby/concurrent-ruby and https://github.com/ruby-concurrency sounds good to me, concurrent-ruby/concurrent-ruby may be easier to remember though
• 👍 keeping one gem for now with keeping in mind possible extraction of Actors if it grows too big
• 👍 for being conservative about adding a dependency to this gem, but not totally opposed to it.
• 👍 "our gem should be for everyone and Java or C extensions are only a way to optimize the code"
• ruby-atomic has native Ruby implementation, afaik it does not need any changes before merging
• "lock/unlock with ensure clause" is in master

from concurrent-ruby.

@mighe @chrisseaton @lucasallan @pitr-ch @headius @schmurfy Did one of you create this organization: https://github.com/concurrent-ruby? It's the organization I was planning to create for this gem by it already existed.

from concurrent-ruby.

hm it was not there just few days back :/

from concurrent-ruby.

I did not create it... is there any way to know who is the owner? I could not find anything in github help.

from concurrent-ruby.

I've submit a help request to GitHub.

from concurrent-ruby.

That wasn't me, I'm afraid.

from concurrent-ruby.

The GitHub team has agreed to pass a polite message from me to the owner of that organization. Hopefully my request will be received in the spirit that was intended and we'll receive a positive response.

from concurrent-ruby.

I've created a to-do list of the 0.7.0 release at issue #98 0.7.0 Release To-do. I'm closing this thread so we can move the discussion over there.

from concurrent-ruby.

That wasn't me either.

from concurrent-ruby.

@headius It's been two days and I haven't heard back from the owner of the concurrent-ruby organization. We may need a Plan B. Are you still willing to share the ruby-concurrency organization?

@mighe @chrisseaton @lucasallan @pitr-ch What do you all think? Assuming we can't get the concurrent-ruby organization (which looks to be the case) should we use the ruby-concurrency organization that @headius suggested, or does anyone have a suggestion for a different organization name? I'm leaning toward ruby-concurrency, but I'm open to other ideas.

from concurrent-ruby.

I am fine with waiting litter longer a weak or two to see if we can't really get concurrent-ruby. ruby-concurrency sounds as great alternative to me.

from concurrent-ruby.

I completely agree with @pitr-ch 👍

from concurrent-ruby.

OK. I'll follow-up with the support person at GitHub early next week.

from concurrent-ruby.

it wasn't me either (just got back from vacation).
Both names are fine for me :)

from concurrent-ruby.