A modern programming language that makes developers happier.

kotlinlang

Looks like the `BigInt` adoption in place of a custom `Long` implementation will be very useful for kotlinx-io, or for the UUID/hex stdlib utilities, as they make use of longs quite often.

<@UFGCACPE0> this simple benchmark:
```@Benchmark
public fun bigInt(blackhole: Blackhole) {
  var r = js("BigInt(0)")

  for (i in 0..&lt;100) {
    r += js("BigInt(i)")
  }

  blackhole.consume(r.unsafeCast&lt;Any&gt;())
}

@Benchmark
public fun long(blackhole: Blackhole) {
  var r = 0L

  for (i in 0..&lt;100) {
    r += i.toLong()
  }

  blackhole.consume(r)
}

@Benchmark
public fun int(blackhole: Blackhole) {
  var r = 0

  for (i in 0..&lt;100) {
    r += i
  }

  blackhole.consume(r)
}```
gives me this result:
```Benchmark                Mode  Cnt      Score     Error   Units
BigIntBenchmark.bigInt  thrpt    4   1909.490 ±  85.321  ops/ms
BigIntBenchmark.long    thrpt    4   1043.697 ±   4.642  ops/ms
<http://BigIntBenchmark.int|BigIntBenchmark.int>     thrpt    4  13202.796 ± 176.814  ops/ms```
If you start adding in bitwise operations, `bigInt` will go down to match `long`, but I think it's a rare situation.

Oh so BigInt is quite a bit faster than Long then

It seems to be, until you start performing all the various `&gt;&gt; &lt;&lt; &amp; |`. I bet those are not optimized by v8 or other engines.

I do have a project where I use bitshifting a lot, but I don't think that section will be performance-critical so it should be ok

I mean you'll get the same perf as the current long implementation, or slightly worse. But going forward staying with native types is the good approach. JS is evolving fast.

This is the result with
```r += js("(BigInt(i) &amp; BigInt(50))")```
instead of the addition
```Benchmark                Mode  Cnt      Score     Error   Units
BigIntBenchmark.bigInt  thrpt    4   1912.579 ±  17.503  ops/ms
<http://BigIntBenchmark.int|BigIntBenchmark.int>     thrpt    4  13001.842 ± 235.835  ops/ms
BigIntBenchmark.long    thrpt    4    671.619 ±   6.282  ops/ms```
So `BigInt` is still faster. HOWEVER, my observation is `Long` will plateau at some point, while `BigInt` will keep getting worse as more bitwise ops are added. With 10 ands, the two will be equal, with 20 `BigInt` will be worse.

But keep in mind with `BigInt` you'll also get a smaller bundle!