泻药

首先纠正你一点，在可预期的将来，语言和语言的界限会越来越模糊，将来不太可能出现说，有什么是一个语言能做另外一个语言不能做的情况，就比如你说的kotlin能做的go都能做，那我可以这么说，go能做的，kotlin也都能做，只是说，会有些许的差异，比如说可能kotlin目前还需要jvm或者dalvik，那这个在大多数时候，并不是一个问题，因为jvm或者dalvik或者dartvm并不大，在安卓上的话，大概是～25m左右，这个是dartvm的大小，dalvik因为安卓自带有dalvik，所以这对kotlin或者java来说也不是个问题，那有一个问题就是可能字节码编译执行有些慢，其实jit之后，字节码的运行效率仅仅是启动时候会略有些慢，那为了解决这个问题，Google搞了art，本质上就是aot，启动加载的问题解决了之后，那另外一个就是gc了，gc的控制和算法也是所有语言通用的，go也有gc，所以从几点上说，kt对比go没有明显的劣势，或者说，go的优势在安卓上并不能得到很好的体现，那来看go对比kt有什么劣势

一个就是go引以为傲的goroutine，kotlin有coroutine，而且kt是stackless的coroutine，这个从根本性能上说，就比go的stackfull要有优势，最明显就是内存的占用，kt才几十个字节，go要几k，所以go就处于劣势，当然go的劣势在这里并不明显，其实go的goroutine现在其他几乎所有语言都在做，脚本一般用async/await的api，一些通用语言，比如java，则是提供底层api，java叫fiber，总体而言，async/await会简单点，毕竟包装好了，如果只是提供底层api的话，还需要自己包装一层，但这个很容易做，不是什么特别大的问题，所以总体而言，以后所有语言都有go的goroutine是大势所趋，其实都在做

另外一个就是go并没有很好的gui的支持，客户端的东西，其实大多数时候都在欺骗人眼，其实说白了，单线程模式更为合理些，而go似乎并不存在有单线程模式，go甚至都不允许你操作线程，你认真看gui，客户端相关的语言，都有一个ui线程，而且是不能block住这个ui线程，主要用来刷新的就是这个ui线程，这个是客户端跟服务器端开发一个显著区别点，那go都没有线程api，除了魔改go自身的实现以外就没办法实现这种搞法，所以go在gui上并不合适，从最基本的api上就缺少一些重要的组成部分

最后一个，gui客户端的合适语言paradigm一般是oop，你认真看类似的平台的这些语言，不管是苹果的swift，还是fx的那几个，比如kotlin，scala，groovy，java，还有flutter的dart，甚至微软的c#，这些gui的语言，无一例外，都有明显的oop特征，最典型的，都有class，而且都是显式定义，而且不少都强调class的封装，这就是pure oop语言的特征，groovy和js相对弱一点，但是js等前端则是通过分离脚本，置标语言（html/xml）和css来区分，这个做法也在其他gui中得到了体现，比如fx就是java等语言+xml+css，qt也有css这些，而go从paradigm上看，并不是一个oop语言，而且带有明显的pp的特性，所以并不合适用来做应用层语言，应用层语言最重要的就是oop特性，越pure越好，因为越pure意味着封装到class/object里面越是强制的，意味着每一个开发人员，在使用该语言的时候，都需要把自己的屁股擦干净，不给别人添烦扰，反正封装到class里面去，就很容易实现科学黑箱的操作，我才不管你是怎么实现的，能用就行了，那这个在大规模组织开发的时候，会有明显的优势，因为我不可能把每一个人的代码都认真看过去，如果是几个人还好，但是如果是十几个人的时候，就已经明显吃不消了，人的精力是有限的，而且非oop语言，有一个特点，喜欢乱写，尤其是pp特征明显的语言，你很容易发现几千行代码的文件，而且同一个功能，不同的人会经常各自实现一点，复用性比较差，这个我不能保证说oop语言没有这个问题，但是会好很多

综上，安卓等客户端开发并不适用于go，go本身的设计也是用于服务器端开发，所以没有必要强行征用go在安卓上

那不用go用什么？看Google在做什么

很简单嘛，Google在搞dart和flutter，那dart从paradigm等语言层面上看，就明显适合客户端开发，包括flutter自身设计是单线程的，aot，jit和几毫秒的gc停顿等，这都非常适合客户端

但是有一个坏处就是，flutter其实针对dart语言做优化的，其他语言要想在flutter上运行，其难度比较大，至少比做一个语言，运行在jvm上，要难一点，因为这些优化都得一一实现，如果不能掌握虚拟机本身的技术的话，发明一个语言，要难很多

就比如java的specification分为语言和虚拟机两个层面，加起来1700多页，语言也就是java语法，大概是一半，七八百页，虚拟机的specification大概是另外一半，七八百页，那如果你要在jvm上实现一个语言，如果是非脚本的通用语言的话，那你看字节码相关的那七八百页就差不多了，就是jvm的specification，但是如果你打算在dartvm上实现另外一个语言的话，不仅要看虚拟机的specification还要看语言(dart)自身的specification，这两个是紧密结合在一起的，那拍脑袋估计，可能难度和工作量直接翻番，而且随着dartvm等环境的改变，ide那边也得重新做，所以国产的东西如果想营造一个生态在手机上的话，难度的确要大很多，相比之下借用java的生态要简单很多，工作量拍脑袋估计，可能只有手机上的三分之一

扯远了，发点表情包：