异步的优势

[taoso]

go 使用协程+阻塞的模式来处理并发问题。这样的模式虽然对运行时要求很高，但对程序员却非常友好。这样的代码码也非常容易维护。

异步模式最大的问题就是回调嵌套，项目大了根本没法维护。我就是不想用回调方式写业务代码才转 go 的。

你认为这类 go 语言的异步框架有什么优势，要解决什么问题？

[Allenxuxu]

@lvht
回调方式确实不利于写复杂的业务逻辑代码。

我开发 gev 的初衷也并不是为了来写业务逻辑，这样的异步框架更适合用来构建更为底层的基础设施，比如反向代理程序、消息队列等。

个人认为，这类 go 异步框架，使用更少的内存，速度更多，适用于一些有特殊需求的场景。

https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/
https://colobu.com/2019/02/23/1m-go-tcp-connection/

[taoso]

这样的异步框架更适合用来构建更为底层的基础设施，比如反向代理程序、消息队列等。

这一类场景使用 go 并无优势呀。c/c++/rust 都是更好的选择。

[Allenxuxu]

开发效率高，代码维护性好，rust我不了解，但开发效率，可维护性远比c/c++好。

[taoso]

go 本来就是牺牲性能换取可维护性的。对于你提到的场景，都是足够简单，用 c/cxx 开发是没有问题。典型的是 Nginx 和 Envoy。我不赞成一种语言打天下，本来设计哲学就不一样。

[Allenxuxu]

go 相对于c/c++性能稍差，但是可维护性高。我尝试在特殊场景平衡两者，而且我并不认为回调会大幅降低可维护性。
gev 足够简洁，并不会带来多少维护负担。

[zhaoke0513]

这种网络库稳定之后，应该不需要怎么维护吧
你更关心的应该是上层的业务逻辑

[yangjuncode]

异步对于1M或者以上的长连接是很有必要的

[MrChang0]

这个issue可以开着做长期讨论

[Allenxuxu]

这个issue可以开着做长期讨论

可以，听舒畅的👀

[MrChang0]

我觉得网络库很大的作用在于把业务和底层的处理隔离开来，在远古时期使用c/c++没有网络库的情况下还需要手动的listen，bind巴拉巴拉等等反智的行为，并且有太多的tcp细节需要处理。即使是到了go的时代，如果一个server还是从listen，accept开始写，这种行为依然是反智的。重复的底层劳动没有意义，把这些操作封装起来反复使用并且及时维护，这就是网络库存在的价值。

[shaoyuan1943]

我有个疑问，net包里的TCPConn本身就是基于epoll进行封装的，作者为何基于原始epoll-go接口来写gev?