@otakustay 另外你理解的 unhandled reject 似乎不对。比如我用你的库运行

Promise.reject(10).catch(function() {})

结果还是会打印 10，这不符合 ES6 spec 的规范。

@otakustay 我这边除了 unhandled rejection，还有 long stack trace，这个也非常重要。另外你可以测下你的性能和我的差别。

我的这个库的目的就是不添加除了调试用的任何非原生接口，换句话说用我这个库，可以没有任何副作用的删除它，切换到使用原生的 Promise。

关于 cancel/abort 这个不是 Promise 应该解决的问题，ES6 的 community 已经应该讨论过这个问题了。

@laoyur readme 里已经有个和各个库的性能比较了，看那个表格，其中有 Bluebird，你甚至能自己跑下 benchmark，具体怎么运行 readme 里也有。不过更复杂情况的性能测试不是当前的开发重点，性能会之后慢慢优化。

@magicdawn 我这个跟书上的不一样，一般书上的实现是跑不过那 800 多个单测的，我这个 80 行的是可以的，我这个可能更偏向工程实际些。对于想更深入了解的人可能有帮助。

@abccba 联系我吧，反正是马甲，无所谓 waistcoat01#gmail.com

@ewex 比如 whydoyouthinkitiselegant?

stringutil 这个不就两个单词么？should be single-word 这不自相矛盾吗？

@aaaa007cn `stringutil` 我笔误。别纠结后缀。关键是文件命名方式。

那为啥，不把锁屏键，静音键和音量键也去掉？太不极致了。

@binux 所以我说参考价值相对高低。我只能说这种反例相对比较少，肯定不能完美判定好坏的。引用数这个概念应该是公认比较靠谱的吧？star 数这种社交型的会更容易被非技术因素影响吧？我指的自动判定，自己人工判定肯定会更准。

话说 python 没什么好的实时引用计数统计服务吗？

github 参考意义确实不会太大，但是如果有人说他开发的某个项目我正在使用，那就比较有说服力了。至少我用过，知道这东西的好坏。

像 npm 里项目被引用次数比 github 要更具参考价值（类似论文引用次数）。比如你跟别人说你的项目被1000个项目引用了，这就比较能体现某个作品的价值了。当然很多产品级别的东西作为末端很难被作为库引用就是了。

@binux 话说 pip 有引用次数计数吗？类似 https://www.npmjs.org

其实我好奇的是能否在既定的次数内完成这个需求，按现在的解法，运气不好可能要重投无数次。

@Daniel65536 嗯，确实，没仔细想，感觉高中天天犯这种错误。

我给个可能不是最优，但易于理解的解吧：

1、记 N 初始值为 0
2、扔骰子，如果是奇数 N++
3、重复步骤 2，7 次

总共操作 7 次，得到的 N 值就是 [1, 7] 均匀分布的。

这题改下，求最少需要扔多少次，能达到均匀随机。

感觉现在很多人倾向于使用 nim，和 nim 比比呢？

@liubiantao 作为强迫症患者，你说完一句话怎么没句号之类的结尾呢？

@rail4you 嗯，有道理，标题确实应该换一下。可惜 v2ex 不能像 stackoverflow 或 quora 那样随时更换标题，发布五分钟之后就 lock 了。

@caizixian 这是是原创，请看第 4 条回复。