@hhjswf 也不是不可能，但是 office 的话管理比较混乱，容易出错，系统的话可以做到一定程度的防呆优化，也好做历史记录

@westoy 这个其实还真不好说，主流的很可能会比定制便宜，但是每家店情况不同，有些老板就是有一些主流之外的额外需求，找主流定制的话价格可不低，反而第三方开发可能性价比更高

我们之前就对接过这样的线下店铺，他就想要某个 erp 的部分功能，再增加一些自身的需求开发，不过后面因为我们团队没有时间，没有接进来

@god7d 做过相关开发，要实现完整的 erp 当然不是 1 2 个人能搞定，但我估计这个朋友的需求重点还是管理和库存上面，压根用不到 90%的功能，只要沟通好功能细节，还是可以考虑接的，不要一听到 erp 就撤退

感觉可以接，别被楼上的吓到了
如果是外包，约定好责任义务维护费用和新功能开发双方商议定价就好了，外包没那么可怕

并发高不高 高的话需要考虑下是不是 gc 导致的

首先基于 electron 就不大可能变得太轻...

20 21 年很多推 rust 的文章，鼓吹初创公司用 rust 我就感觉这有点不合适
初创公司需要快速实现产品，而大部分的初创公司的产品都难以遇到真正的性能瓶颈（至少前几年是这样），而相比其他语言 rust 的学习曲线和开发效率也是有目共睹，所以实在不建议首选 rust
后悔选择 rust 的公司我都看了不少了，这可能只是个开头。。

看恐怖电影的时候播放今天是个好日子，最胆小的女孩子都敢一个人看

高度怀疑某个逻辑处阻塞或死循环了，导致无法切换上下文

提个小看法不建议为了 star 去做项目，我认为维护一个几十 star 的软钢需项目比上千 star 的通用轮子项目有意义的多
其实从这个出发点的话发起个很简单了，想想你工作或熟悉的开发领域有什么痛点、不方便的地方，然后用代码来解决 /提高效率，项目就有了

个人感觉有 2 个问题，1 是最低只需要 16 整数倍就行了，例如输入 15 字节填充到 16 即可而你的似乎会多一个 block 变成 32
另外是为了方便使用应该将 key 自动转换到 16 字节而不应该由使用者去关心具体的 key len

看到第八条，我觉得应该还不会全军覆没

https://blogs.360.net/post/%E7%94%A8-filesystem-api-%E5%AE%9E%E7%8E%B0%E6%96%87%E4%BB%B6%E4%B8%8B%E8%BD%BD%E5%99%A8.html
如果非要用 js 下载可以通过 filesystem 的方式，现在有不少新生服务都喜欢这个模式，优点是比较灵活

gorm 的 NotFoundError 这点确实很脑残，很多人都诟病，把业务错误跟服务错误都搞混了作者还坚决不改，只能自己判断下

gorm 不少地方使用起来都非常不方便，实在不明白为什么这么受人推崇 举个例子
指定字段是 Select("col1", "col2")而不是 Select("col1,col2")就非常反直觉，跟其他各种库包括数据库习惯都不一样

不过 gorm 的关联比其他库强大一点，可以灵活的实现各种关联模型

除了 gorm ，我比较推荐 xorm ，用起来也很不错

@Frankcox 你这个相当于前端把数据全部拉下来丢内存再下载 效率可想而知

大概率 fetch 的问题，前端要么直接跳转下载链接下载要么用 fs 去下载，fetch 那肯定会获取完数据才能处理，容易卡死

怎么这么多怀疑 14 岁开发的，我见过的 github 最小的开发好像是 8 岁

? Craft