deprecate deno or improve maintainability

[Xuanwo]

Looks like deno did some breaking changes:

error[E0308]: mismatched types
   --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_core-0.272.0/arena/raw_arena.rs:290:43
    |
290 |         for alloc in BitSet::from_bit_vec(vacant).into_iter() {
    |                      -------------------- ^^^^^^ expected `bit_vec::BitVec`, found `BitVec`
    |                      |
    |                      arguments to this function are incorrect
    |
    = note: `BitVec` and `bit_vec::BitVec` have similar names, but are actually distinct types
note: `BitVec` is defined in crate `bit_vec`
   --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bit-vec-0.7.0/src/lib.rs:245:1
    |
245 | pub struct BitVec<B = u32> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `bit_vec::BitVec` is defined in crate `bit_vec`

[PsiACE]

It's just that bit-vec released a new version

contain-rs/bit-set#32

[Xuanwo]

It's just that bit-vec released a new version

deno specify bit-vec = "0" ...

[Xuanwo]

cc @wangrunji0408, #39 is the temp workaround. To fully address this, we need either:

• A. Wait for deno bumps all it's dpendences with correct version instead of 0
• B. Commit Cargo.lock in repo to make sure to pick the correct version during build
• C. Add some cargo update in CI to pick the version.
• D. Drop deno support entirely (?)

What do you think?

[Xuanwo]

Reopen to continue the discussion.

[wangrunji0408]

Let's keep our patch until deno-core releases its fix.

[PsiACE]

bit-set released version 0.6.0 🥰

[BugenZhao]

Personally I feel like deno is not that serious when it comes to specifying dependencies, e.g., foo = "0" or bar = "=x.y.z" with no strong reason. This may be because it is more commonly distributed as a binary than being used as a library. As a result, it is challenging for us to maintain support for it in this project, and it also blocks bumping other dependencies in the downstream (risingwavelabs/risingwave#13695 (comment)).

D. Drop deno support entirely (?)

So I would like to vote for this option. In risingwavelabs/risingwave#17544 @MrCroxx is also going to drop the support of Deno UDF in RisingWave.

[BugenZhao]

Let's keep our patch until deno-core releases its fix.

There's a considerable amount of breaking changes in recent releases of deno. I'm afraid it requires a lot of effort to stay up to date with the upstream. 😕

[Xuanwo]

Yes, I feel the same way; maintaining deno support for arrow-udf isn't worth it unless we have users.

[MrCroxx]

+1 for removing it until we get a real user.

[wangrunji0408]

cc @bakjos for awareness. What's your opinion? Is it possible to link a prebuilt binary of deno?

[bakjos]

@wangrunji0408 yes, think it's possible, but one of the advantages of having it embedded is less serialization and less communication overhead. I'm in long break, but can take a look in 6 weeks from now