All of the above! I got .org and .net as well, to thwart spammers a little.

Eh, given that it’s an uncommon enough word, that is.

Oops, took it a bit too literally. I also wanted to suggest not announcing it, in case someone else liked the sound of one of them 😛

hmm. I’ve only seen it used heavily when doing websocket or Chrome (using chromex) plugin programming

any messaging. also it is nice (and very simple) at separating modal ui stuff. and anything like mathjax updates. I find it to be much simpler at this sort of thing than any explicit use of callbacks

I definitely tend to lean on built in promises in js. Can usually achieve most of the same stuff, and core async can expand to quite a lot of code, which can swell the js size

seems bit of a dense topic. Cognitect currently asks for some money from the community (https://www.patreon.com/cognitect ), so it's not impossible that they could give core.async a boost if some appreciation/interest was given.

That's licensing for REBL so I don't think you can just expect them to accept money from CT and divert it to core.async -- who is actually going to do the work?

To work on core.async requires a commitment of time/effort from someone who is authorized to work on a Contrib project.

As prefaced, I do think it's a dense topic 🙂 The suggestion I transmitted to Daniel @ CT was: 1.- Capture the interest in core.async et al first. Currently this capture has many flaws 2.- Armed with money and reified community interest, you can make specific offers that project owners (however busy) can consider more seriously

many of the bugs already have patches bit rotting away in jira

so it isn't like getting a posse together is going to do anything

review time deserves as much time/appreciation as coding time

to put things in terms of a system of queues, increasing output upstream of the limiting constraint is not going to increase throughput

but you are implying money can only be invested in output and not in input

I am implying if you get a bunch of people together to write patches, those patches are going to make the backlog in jira worse

we also can get an individual to review the existing patches

reviewing and merging changes is the bottleneck, and as far as I have seen, there is little interest to spread that around

e.g. when you ask alex about getting a patch merged the response is not "it would get merged faster if I could get help reviewing it" the response is "when I get to it, but I have a bunch of other stuff on my plate"

It seems plausible to me that that we could be mistaking lack of interest for lack of capacity I can literally intepret that from when I get to it and bunch of other stuff

ASYNC-165 for example fixes a bug in the cljs go macro, and the patches are 3+ years old now

it doesn't matter why they are aren't getting to it if there is no interest in letting other people get to it

> ASYNC-165 for example fixes a bug in the cljs go macro, and the patches are 3+ years old now that's not something I didn't know > it doesn't matter why they are aren't getting to it if there is no interest in letting other people get to it you don't think that a company that literally does consulting for a living can be incentivized to work on an area of its expertise?

I happen to have a few patches for core.async sitting waiting(including the 3+ years old one)

I don't know

I don't even use core.async for cljs, I use it for clojure and just happened to see that issue and write a patch for it. What I would really love is getting more exception handling patches merged

The way exceptions were handled before was super broken, after about a year I got some patches merged to fix it, and there have been some follow up bugs to fix there that have been sitting for years now

I also fixed the exception handling machinery for cljs's go macro, but the first round of fixes for that never got merged

You could also argue: if (fixing several things in) core.async was of that much business value, there would be incentive from within to fix it.

I think most people (project consumers) prefer applying workarounds to getting involved at all (which can be as easy as upvoting issues) clojure.coree rightly pointed out that some old issues/patches have practically no upvotes. So why would they prioritize those?

It's important to look at this page when you're talking about Contrib libraries: https://clojure.org/community/contrib_libs#_contrib_libraries -- core.async is "owned" by Rich himself and is marked "Stable". That means "working but development is irregular". So unless you can get agreement that someone else should take over as owner of core.async, any work you push for on that library will take Rich away from something else.

it is a shame that the irregular development of "Stable" means bugfixes don't land either

@U04V70XH6 Observation very much in point. At the same time, owners can change. It might boil down to a matter of incentives and rationale.

FWIW I've used core.async in cljs in 2-3 production projects (not solo). Old issues like lack of dynamic bindings can be quite a constraint As a practitioner I do have an incentive to make change happen

The first question is: would you (or some other user of core.async in cljs/clj) be willing to step up and own the project? The second question is: do Clojure/core think core.async could be maintained by a community member outside Cognitect?

(In fact, perhaps those are the second and first Q respectively, not the other way round?)

Maybe someone inside Cognitect could own the project other than Rich?

Exactly, in fact I don't think CT projects have been carried out by non-owners of the respective funded projects

Nice one 🙂 guess nil nil are placeholders for something like &env?

yes, guess so

user=> (defmacro foo [] [&form &env])
#'user/foo
user=> (#'foo 'foo 'bar)
[foo bar]

nice!