emacs

surge

试下这个

<img src="https://i.bmp.ovh/imgs/2021/01/7eebbcce10cf782e.png" class="embedded_image" rel="noreferrer" referrerpolicy="no-referrer">

呃，原来不支持 markdown

<img src = 'https://i.bmp.ovh/imgs/2021/01/7eebbcce10cf782e.png' />

呃，直接应用商店搜啊。。唯一需要注意的点是需要选一下设备类型，另外有些软件不给 macos 用


sorry 没看时间，忽略我

老哥还有位置吗

所有的 feature 分支合并到主分支之前，都需要先合一下主分支处理完冲突，而不是在这个 merge 中合并，因此 feature 分支和主分支的交点只有一个简单的 merge，如果发现某个 feature 分支的内容有问题，那么 revert 这个 merge 就好了。revert 的复杂度取决于你们在该 merge 的基础上做的改动量。

主要写 java 也写过 go，真想学一下咋把 go 写出 java 味。。

@suke971219 我就是后端啊，所以说只差个前端

6 了 idea 已经有了，就差个前端了

@myqa 说 API 差不多您肯定是没用过原生的 jedis 和 lettuce，“肯定使用上层包装”也是 6

确实有点为赋新辞强说愁的感觉；

楼主为了解决关系型数据库的模型、语义等和 Java 的对象模型不一致的问题，发明了一堆注解和一个 DSL ；
其他人为了解决同样的问题，发明了一个概念叫对象关系映射，同样的，发明了一堆注解和一个 DSL （ Criteria ）；

so，大家都是一样的东西，你这个咋就“完美的解决了上述两个问题”呢。。。

lettuce 的优点一直不是性能啊。。。而是可以复用的连接、易用的同步 API 、统一风格的异步 API 、完备的功能和对 Redis 新特性的支持

6 了

@gantleman emmmm 可能是我没说清楚。“游戏服务器对性能要求非常的高”这种结论一般是横向对比 web 服务器得出的，通常的逻辑链条是：游戏业务延迟敏感+连接数少运算量大 = 性能要求高 --> 要用 C++实现。我想说的是，在客户端的角度，服务器实现成什么样并没有区别，所以，没必要非得上 C++。

纯函数的话，这个想法是可行的。。然而纯函数的单测很容易写，通过这样的方法生成用例感觉绕路了。

其实不太能理解游戏服务器对性能要求非常高这种结论是怎么来的。。。对客户端来说，绝大多数 RTT 都在网络传输上，无论服务器实现成什么样，也就是响应时间增减几毫秒的问题，当然可能有个别业务特别耗时，但不会影响玩家的整体体验。因此，为啥非得上 C++呢。。。Java+ZGC 可以把暂停时间控制在 10ms 以内，大多数时候不超过 2ms 。。