Hello, Good work on release 37!

Was dropping JavaScriptParseSpec purely a "no one was using it" call, or is there a longer-term plan to phase JS out more broadly?

Asking because I'm currently relying on JS at the aggregation layer for things like a bitwise day-of-week mask during rollup:

{
  "type": "javascript",
  "name": "days_mask",
  "fieldNames": ["day_of_week"],
  "fnAggregate": "function(current, dow) { return current | (1 << dow); }",
  "fnCombine":   "function(a, b) { return a | b; }",
  "fnReset":     "function() { return 0; }"
}

No native longBitwiseOr aggregator exists afaik, so JS is the only real option here.
Would love to know if this is on borrowed time or not

Was dropping JavaScriptParseSpec purely a "no one was using it" call, or is there a longer-term plan to phase JS out more broadly?

ParseSpec in general had been deprecated for a long time, and in this release we removed all implementations. It wasn't part of a plan to phase JS out more broadly. Although, JS isn't generally recommended due to the lack of sandboxing. (The docs mention this is why it is off by default.)

I think in your case you could use an expression aggregator: https://druid.apache.org/docs/latest/querying/aggregations/#expression-aggregator. The functions bitwiseOr and bitwiseShiftLeft are there.

I think in your case you could use an expression aggregator...

just in case you need that expression aggregator at ingest time: #19508

Thanks both!
Good to know JS aggregators aren't going anywhere imminently, and the expression aggregator path is actually cleaner for this use case anyway.
Will migrate to bitwiseOr once 38 drops, appreciate the quick turnaround on #19508