go 编译启动是快，但是语法和生态都这么差劲…受不了啊

himccccaelhgphommckogopgpddngimf 这个也不错，感觉很轻量

啊，是为了好招人啊，那当我没说

正常场合下大家内存占用应该都差不多（ Java 别用 spring 就还行，用 Kotlin 搭配 vertx/ktor 等等。native image 可以参考下，个人没在生产使用过，不知道咋样

举报了没

恕我孤陋寡闻，中间人攻击基本上只能通过证书或者类似的其他“预共享的信息”来实现，你这里好像根本没提到对这个问题的解决方案。如果不想引入证书也可以参考下 Telegram 的 secret chat，两边用户可以通过对比一个颜色点阵来确保没有被中间人攻击。

毕竟纯 vertx 写起来挺难受的

vertx + kotlin coroutine，爽（

虽然反对一楼的逻辑混乱发言，但是你这个问题多半是开到有问题的 IP 了，小厂还能和客服商量商量，阿里这种···

这种类型的“参数化”大多数都是转换成数据库本身支持的“参数 sql”(prepareStatment 那种)+参数，然后提交给数据库解析

Java 传统的那一套 J2EE 体系里的东西（包括 JDBC 和 serverlet 等等）都是基于会占用线程的阻塞 io 的，高并发下不可避免占用大量线程资源，而线程又比较贵所以就······
如果你不使用这套传统生态的话， 新的库基本上都是基于非阻塞 io 的，如果你可以切换到 Kotlin，使用 Kotlin Coroutine 等方案也能享受到协程。
Go 原生就有协程，没历史包袱，生态的东西自然对协程都是一级支持。

至少在 Web 开发上个人比起 Go 更倾向选择 Kotlin，在语言特性上，Go 还是太缺乏了，就算说是“大道至简”，这也太简陋了。而使用 Kotlin，有并发需求的场景，完全可以选择规避 Java 传统的那一套生态。当然这个问题见仁见智了。

except （也不是不能用（

应该是只能子查询了（

哦不对…写糊了…这样查出来的不对

select s_id from Teacher inner join Course using t_id inner join Score using c.id inner where t_name != '张三'
可不可以？