范狂夫
谢邀。
已经是2018年4月22日现在了，新时代中国特色社会主义大好形势下，繁荣的中文互联网上，到处推送的「重磅」「震惊」内容，差不多都是「中兴药丸」「中兴乙烷」之类。
这种时候再讨论亡我之心不死的帝国主义出品的「技术栈」，是不是有些「不合时宜」「不与中央保持高度一致」「顶风作案」「逆潮流而动」「自绝于兲朝人民」吖？
但是呢，当代信息技术领域精英辈出，与时俱进的童年才俊纷纷摇身一变为青年才俊，在战斗中出生在战斗中成长的这些党国栋梁，知识结构还就是这些「有美利坚特色的帝国主义」内容。
我已经不当码农好多年，当年也是「不入流码农」而已，不值一提不值一提。但是，考虑到知乎站方和活跃网友的热情，还是厚着脸皮勉为其难，以一个老迈年高的历史唯物主义的尘埃的身份，传授一点人生经验。
在「贸易战暂落下风」的大背景下，主席台前三排首先要考虑的是「止损」，也就是避免「被切开的血管」之悲惨命运，提供现金流向海外源源不断输送利益之类科技进步，属于饮鸩止渴。
按照临时抱佛脚上网乱搜弥补代沟所获得的信息，「.Net Core」也是跨平台，微软官方提供了Windows/macOS/Linux这三种主要的操作系统之下的「运行时环境」，或曰「Java™多年前就做到的事情」。
但是呢，「多年前」就有码农抱怨「一次编写处处调试」的问题，说Sun/Oracle技术储备不够，自家出品JRE在各平台都不一致，同一个平台下升级版本都不一致，导致「部署之后绝不升级」这种项目惯例。
就我听说的例子，某项目已经非常小心谨慎了，在Java6还是7推出之后，为了稳妥起见仍然选择了已经过时的冻结的1.4.2环境。结果呢，相信Oracle™的节操的项目负责人，因为忘记比较开发环境和运行环境中官方发布的JRE之八阿哥修订版「1.4.2_XX」最后几位修订号，导致码农加班时间极大充沛，还经常摸不着头脑：「跑不了，为啥呢？又好了，为啥呢？」
单纯从技术角度判断，Java™是虚拟机，实时编译是后来追加的功能；而.Net设计之初就是编译为本地代码之后再运行。从实践中也感受到，在.Net低版本时期购买的第三方控件，可以不加升级和修改的直接在高版本开发环境下使用，并不会影响运行效率。仅从这一点出发也知道，.Net技术栈对于向后兼容保护企业既有财产很有诚意。
顺便，在.Net刚出现的时候，开源社区有两个针对性的项目，一个就是山寨版「Mono」，另外一个是「DotGNU」要把所有内容统一编译为Java™字节码。前者成果充沛，后者嘛，停滞很久了，据称由于Java™「劣根性」而遭遇了技术上难以解决的问题。
目前两套方案都跨平台，都免费发布，并且都有官方保证兼容性，都可以做到移植「既有项目」到兲朝很可能「大力」推广的Linux等开源平台上。那么，就当这个过渡时期已经有惊无险了吧，接下来干什么呢？
除了Oracle™起诉谷歌侵犯Java™知识产权获赔巨额金钱的旧闻之外，最近还有一条新闻，说苹果下架了所有带「JavaScript™」字眼的「哎屁屁」，因为「JavaScript™」这个字眼也是Oracle™的注册商标。所以，如果不想被「伪装成IT企业的律师事务所」配合美帝灯塔国商务部地毯式索赔，建议还是使用「ECMAScript」这个标准化组织使用的名称。
而微软的C#也是ECMA标准之一，叫什么名字无所谓，能用就行。具体「技术」的知识产权问题另说，若是「名称」都被无孔不入的讼棍利用，确实很难获得信任。仅从商业角度判断，Oracle™讼棍「无理取闹」的「前科」，也应该值得所有兲朝信息技术企业加以警惕。
说了这么多，结论是什么呢？
有个前提，号称「官方逼死山寨」的「.Net Core」是不是真的逼死了「Mono」，还是互相促进的良性竞争关系。如果没有真・开源的替代方案，兲朝选择微软技术栈并不明智。
同时，众所周知Java™有第三方的实现，IBM就因为对Oracle™官方发布嗤之以鼻而自己开发了一套，各种开源的实现也有。但是，「兼容」Java™需要Oracle™「认证」，费用高昂，不想掏钱还想用Java™技术栈，就会面临Oracle™讼棍的胡搅蛮缠，最终被美帝灯塔国商务部加以制裁。
这都是现实问题，按照兲朝惯例，这些问题都能「找关系摆平」「地球上没什么事是一顿清真美食解决不了的，如果有，那就两顿」。
就当都已经搞定/摆平/解决了吧，没有后顾之忧，也没有前车之鉴，这种时候，我选.Net Core。