@lasuar Can't agree more!

如果不用 orm, 可以试试我这个 github.com/lesismal/sqlw

拉满更香

OP 可以好好修行下技术跳槽到好点的公司, 然后就可以较大程度避免这种队友了

这个度数不高, 如果年纪不是过大晶状体弹性太差, 可以趁早上欧欧眼保仪, 七八成的机会能把近视治好, 但一定要坚持使用它锻炼睫状肌, 坚持用, 效果挺好的.
个体差异, 不一定对每个人都有效, 价格小贵, 好像也有租的服务, ,如果不放心, 可以先看看他们介绍的原理再做决定. 用机器的好处是相比于自己看训练的视频或者自己锻炼那些能屏蔽不少干扰, 效果更好更专业, 但如果你有足够的耐心坚持自己自然训练法之类的, 不用机器也可以的

付费的课程多数都还可以, 免费的那些省钱费时间效果没多好

这么多人说行, 听得我都心动了

@james122333 如果有兴趣, #109 里的链接 "2022 Go 生态圈 rpc 框架 Benchmark" 这个帖子的性能对比可以看下, 性能强的基础上, 功能也比其他的 rpc 更丰富, 场景支撑能力更强, 扩展性也极强, codec, 中间件, 协议编解码都可以扩展. star 不如他们多不代表库没有他们好, 写得晚, 而且我个人没有大厂团队那么大的能量去推广罢了

@james122333 #144

> 看了看它就不只是个 rpc... 是长连线 也可以做完断线 呼叫满满的 http style 拿来当 http server 也无不可 不应该以 rpc 为名

大多数人对网络交互都局限在 web 相关那一套了, web 的人最多, 命名 arpc 一是为了讨好社区, 因为其他领域的受众太少了, 二是, rpc 也确实是一个大的功能项, rpc 也是 arpc 的主力功能之一而且把 arpc 用作 rpc 只比其他的 rpc 强(单说 golang, 其他语言我没那么多精力去实现和维护)

按 rpc 的定义, http 本身也是一种 rpc, 所以 http style 这种说法不准确, 至于拿来当 http server, http 做静态资源服务的话肯定是不适合用 rpc 来做, 至于 api, 确实可以用 rpc 替代, arpc 支持这么做的

最重要的是, 更广阔的场景, 其他 rpc 很难支持, 比如做 IM, 游戏, 推送服务, 用其他的 rpc 就不那么适合了, grpc 的 stream 一定程度上可以做一些, 但是 grpc 使用起来太麻烦了而且也局限, 远不如 arpc 灵活

网络交互, 就像我在 arpc readme 里写的, 主要就是 req-res(请求+响应), notify/push 不需要相应, 两个方向 client -> server 和 server -> client, arpc 都支持, 更多的业务场景, 一套全搞定. 不需要很多项目需要 server 推送那样再单开一个 ws 来做, arpc 当 rpc+server push 随便弄

泡茶, 即热饮水机出的所谓 100, 跟烧开的水对比下就知道了. 烧开的那才是真的 100

@cskeleton #39 监管, 合规, 就可以了, 否则即使有多套系统, 人家不告诉你, 你也没办法. 重要的是合法合规, 他们是国家队, 先不论过往股市如何, 单说正常流程上, 这些事应该由监管和合规这些来把控, 而不是你我在这猜测别人怎么搞就会被告不公平. 还是那个观点, 你先想想清楚为什么节前卡单那么多没被告再讨论吧

@james122333 #140

标准库 rpc 对于多数人可能足够用了, 性能上虽然没有什么额外的优化例如 pool 或网络的优化, 但也比很多垃圾框架要强了

另外, 你可能把 arpc 想简单了, arpc 是通用网络框架, rpc 只是一个功能罢了, 比标准库 rpc 丰富多了, 性能也更强

而且, 标准库 rpc 可能还是需要有一些额外的坑需要处理的, 我没做测试只是基于简单扫了下标准库 rpc 代码的猜测, 不一定准确: 比如最基本的例如 timeout/context 好像是不支持, 如果只用普通默认参数没有设置 TCP Keepalive, 赶上 server 设备意外掉电或者维护重启没有 TCP EOF 则 client 的 Call 就可能死等着阻塞了, 自己做一些额外的封装也不麻烦, 只是如果这样子, 还不如别人都支持了的方便
当然, 只要满足你们的需求足够用就可以了

@fox0001 @lesismal #141 但 grpc 即使让用户可选传输协议是否 TLS, 也只是相比于它自己好得多, 仍然只是个 rpc 罢了. 我的 arpc 其实是通用网络框架, rpc 只是一个功能罢了

@fox0001 grpc 就是因为强制 HTTP2 才拉垮的, rpc 场景多数是内网可信的环境, HTTP2 的 TLS 就成了性能的累赘. 如果不是强制 HTTP2, 而是可选传输协议, 让用户自己选择是否直接使用 TCP 或者使用 TLS 等加密通道, 则会好得多.

@helone #32 字节的 http 和 rpc 的 benchmark 数据是自称的，第三方测评跟他们官方的数据不太一致，最好是把测试条件对齐、自己跑下实际代码看看真实数据。另外，他们这些基于自家 netpoll 的库，在一些场景消耗不太正常，甚至用空间换时间、内存消耗比其他框架高的多、稳定性也存疑（我压测的时候就遇到过多次卡死、但其他框架都没事），如果生产上允许比较高的 cpu 那可能影响业务稳定性，如果只允许有限的连接数，那每个节点又没法省更多（跟其他 go 框架相比）

@james122333 arpc 的例子，可能比标准库 rpc 用起来还要简单些吧，像 net/http 一样简单：
https://github.com/lesismal/arpc?tab=readme-ov-file#quick-start

@james122333 标准库 rpc 算是中规中举，各方面一般。也可以看下 #109 我贴的连接，测评是鸟窝老师做的，最快的那个应该算是我的 arpc ，更快，使用简单，而且功能丰富得很，可以支持的业务场景也更多，包括推送、游戏、IM ，普通 rpc 是很难做这些场景的，欢迎体验