swoole和java_2020年各位后端开发者更看好谁，Java，go，node.js还是php（swoole）？

go 随便用了一下

感觉和java相比差距还略大

后端主要是生态问题，语言其实无所谓，或者说如果仅限于web服务器，瓶颈很少在语言上，基本都是其他服务器，消息队列，数据库，缓存的性能有问题。生态方面可能go接触的不多，反正做东西发现生态少得可怜，好多东西都是github上找个人维护的项目，根据历史经验，只要没有spring这类官方，那么会像node.js一样持续混乱几年吧，后端本来就是人少，没准儿会乱更久。。。

但是go应用范围感觉比java宽好多，自带runtime如果可以进一步缩减内存使用(比如几百K？)，那么很多java不能运行的地方go都可以去。目前是几M 对java而言很优秀，但是嵌入式设备的(边缘计算？)等，这个runtime目前启动没仔细看大概2M不到，但是gc不控制可以飙到很高，sync.pool似乎也是直接碰撞没有限制，还需要进一步优化或者自己小心写，或者自己手动gc。

但是一个问题是java最近其实应该算是加速发展了吧，如果AOT编译+jvm做必要精简(比如编译就指定GC形式等)+官方出协程(和官方出lamba一样)，那么岂不就是go了。。。 当然这里面工作量不了解，为了缩小二进制文件体积，要模块化后解耦很多老代码，虚拟机内的字面引用的方式修改等应该有很大工作量(java9看到AOT编译，现在是否成熟未知)。但是仅凭spring boot因为docker文件分层问题出的2.2版本来看，java生态至少还是原因对新技术有响应的，还在发展。

php node.js在开发速度方面还是比编译的语言方便太多，开发效率会快，部署也方便太多，rsync即可(node.js需要重启或者pm2这类工具自动检测文件变化重启？，好久没用node.js写过东西了)。go 和 java都需要编译区别不大

swoole稍微看过因为最近接手了一个swoole，既然高性能线程/进程模型现在都是固定的，网络异步IO+任务队列+不超过CPU核数的loop线程，IO耗时操作放入线程池或者再单独loop，那么直接用java解决不就好了吗？我看到这个swoole因为性能问题还自己写了缓存相关的通用代码，可见因为性能问题的确下了功夫，但是spring boot其实直接 用cache非常方便，一个配置文件几行注解，基本需求都满足了，看Php自己写的缓存工具很费劲(可能孤陋寡闻，php也许有很方便的缓存框架我没见过)，从这个角度讲，如果纯后端，真的没必要php，后台另说，php的确方便。 个人感觉swoole的存在是因为开发团队本身技术栈是php,直接使用swoole成本相对更低，比起转java或者go甚至node.js