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