欢迎！请参阅关于页面，了解更多关于这个社区的信息。
查看下面的gist以查看详细结果。
注意，对我来说，使用互操作是可行的我处于一个运筹学研究场景，其中随机值的计算时间非常重要。
但我想知道为什么Clojure不应该提出一个更好的`rand-int`版本。
我怀疑（如果有必要会检查），`nextInt`版本可能会有更均匀的分布（统计上更接近理论值）。
PS：这是 Slack 中一个问题的重复，来自 Clojure 频道。
为了绝对效率（或者至少不要留下任何剩余），我认为为 rand-int 设计一个专门的变体是合理的。这可能是 clojure 1.0 的简单实现。它可能简化了通过隐式全局 prng Math/random 的一体化。然而，多年来一直有人抱怨这种方法缺乏种子设置；普遍的解决办法似乎是定义一个包含随机实例的 dynvar 并将其调用委托给它，虽然这会带来 dynvar 的查找成本。但是您需要为 rand-int 引入一个专门的 Random 实例（很简单...只需封闭一个即可）。
请注意，如果您真的关注性能，我在机器上使用 https://dsiutils.di.unimi.it/docs/it/unimi/dsi/util/XoRoShiRo128PlusRandom.html 的 PRNG 比java.util.random 快约 2 倍，还有一些更专业的技术，如 https://dragan.rocks/articles/19/Billion-random-numbers-blink-eye-Clojure（尽管这些示例需要被强制转换为 int，可能还需要通过一些流 API 封装，并且还需要引入额外的依赖项）。
已记录为 https://clojure.atlassian.net/browse/CLJ-2635
