估计你们不知道，楼主是要在 linux 里跑 wine 的，既然 linux 桌面这么差，干脆用 windows 好了，wine 都省了

@ecloud PAM 本身是有规范的，具体实现遵守不遵守就不知道了

http://www.opengroup.org/rfc/rfc86.0.html

为了看得懂书和文档

@ecloud 上百台算个毛，我们这层 office 就有 200 多台 i5 和 i7 了。是不是主流不是你我说了算，intel 自己有明确定义，i3 是 entry-level consumer，i5 是 mainstream consumer，i7 是 business and high-end consumer，xeon 是 server and workstation。现在还有用 Q45 做主流的公司，我也算是开了眼界了。

@ecloud 实在找不到 N2600 或者 Q45 这种硬件，能访问到的只有 i5 和 i7，要么就是志强 E5。

就算完全不支持 N2600 和 Q45 又如何？只要主流的支持的好就行了。

json 不可能保存对象类型，json 反序列化的时候，你不是自己可以指定对象类型吗？

@ecloud 网友们做桌面用的集显，都是 i3，i5，i7 自带的，偶尔也会有 apu 自带的集显，根本不会去了解各种集显

@ecloud unity 桌面和 glxgear 跑起来没问题啊

一大票服务器的板载显卡还就是唐朝时候的 G200eR/eW ?
对不起，我们服务器显示器都没有，除了几台搞 GPU 计算的，要显卡何用？

@wohenyingyu02 Kotlin 在 JVM 调 C 库等同于 Java，Kotlin Native 只能调 C 库不能调 Java 库。

@succlz123 JVM 字节码混淆工具，理论上不应该区分 Java 和 Kotlin 生成的字节码。

@Miy4mori null safe 跟 Java 交互，调用 Java 的时候可以保证不会传不该 null 的 null 给 Java，获取 Java 返回值的时候可以写个!!后缀假定它是 nonnull 的，也可以假定它是可以 null 的，并不会损失 null safety。
能写的舒服一点，读的舒服一点，顺带稍微减少点 bug，已经足够了。

Kotlin 协程不知道算不算解决的实质问题，如果不用协程，我们新的需求要把 3000 个线程变成 30000 个，而用 akka 或者 vertx 这样的库又很难处理复杂业务逻辑，每次请求都要调用几十个服务，状态个数都超过 100 个了。如果不是有 Kotlin 协程，都计划用 Go 语言重写，放弃 JVM 了。

@bravecarrot 用了十几年 Linux 桌面了，没碰到过要自己下载代码编译的软件，只装一次系统，一直用到不用这台电脑为止，或许像我一样坚持用 intel 集显或者 nv 独显，就没那么多问题。

@ecloud 我的 intel 集显从来都是开箱即用啊，还要装驱动？

@notreami 注解只能缓解，不能根治语法的不足，比如做 DSL 的时候，用 Java 就很麻烦，用 Kotlin 或者 ruby 就很简单。

像这样一段 DSL，你用 Java 和注解可以很简单的实现吗？

html {
head {
title { +"XML encoding with Kotlin" }
}
body {
h1 { +"XML encoding with Kotlin" }
p { +"this format is now type-safe" }

/* an element with attributes and text content */
a(href="http://jetbrains.com/kotlin") { +"Kotlin" }
}
}

gradle 之所以用 groovy 做 build 的 DSL，也是因为语法表达灵活，现在 gradle 也支持 Kotlin 的 DSL 了，写法跟 groovy 的基本一致。


Kotlin 不自己造轮子，充分利用 Java 的库，这正是它最聪明的地方，因为数据结构都是 Java 的，跟 Java 才没有 interop 的麻烦，Kotlin 调用 Java 或者 Java 调用 Kotlin，不用做数据结构的转换，也不用任何 wrap，就跟调用自己语言写的库一样方便。一段 JVM 字节码，是 Java 编译来的，还是 Kotlin 编译来的，没什么明显差异，所以原生不原生也无从谈起了。

在技术的路线上，是深度更有价值还是广度更有价值，因人而异，同一个人的不同阶段答案也不同。

@LevineChen 是楼主自己觉得显摆了，然而观众们并没有这种感觉

@notreami 很遗憾，Java 9 并没有带来这些特性，第三方库也没法绕过语法限制。体系不完整是从什么角度评价的？

实际上 go 和 js 我也用，python 和 php 也用，学一门语言只是一个周末的时间，反正不加班，这点儿时间我还是有的。

在我正式开始用 Kotlin 的时候，搞安卓的都没几个人听说过 Kotlin 呢，今年突然火一把也是出乎我的意料。

@zwpaper Java 7 和 8 的特性，在 Kotlin 面前都不值一提，Java 9 都赶不上，可能 Java 10 可以跟现在的 Kotlin 比比。不过新入 JVM 坑，不建议直接学 Kotlin，因为几乎所有资料都是围绕 Java 的，至少得看得懂 Java。

@lowzoom 考量过 AKKA 和 vertx 还有 rxjava，这些库用来做底层通信协议是不错，处理复杂的业务逻辑的时候有点麻烦，状态个数比较多，不如 coroutine 方案来的直观和易于维护。而且迁移已有的阻塞型 Java 项目，用 coroutine 代价比较低，几乎不需要修改调用点之外的代码，之前甚至还考虑过用 Go 语言或者 elixir 重写，评估之后觉得成本太高，就等 Kotlin 1.2 发布了

@Lispre 的确不宜操之过急，使用小众语言很容易遭到同事抵制，对 HR 也不友好

@Betacoefficient JDK 代码里写死了，CST 就是芝加哥时间，你自己如何调整？

private static String[][] oldMappings = new String[][]{{"ACT", "Australia/Darwin"}, {"AET", "Australia/Sydney"}, {"AGT", "America/Argentina/Buenos_Aires"}, {"ART", "Africa/Cairo"}, {"AST", "America/Anchorage"}, {"BET", "America/Sao_Paulo"}, {"BST", "Asia/Dhaka"}, {"CAT", "Africa/Harare"}, {"CNT", "America/St_Johns"}, {"CST", "America/Chicago"}, {"CTT", "Asia/Shanghai"}, {"EAT", "Africa/Addis_Ababa"}, {"ECT", "Europe/Paris"}, {"IET", "America/Indiana/Indianapolis"}, {"IST", "Asia/Kolkata"}, {"JST", "Asia/Tokyo"}, {"MIT", "Pacific/Apia"}, {"NET", "Asia/Yerevan"}, {"NST", "Pacific/Auckland"}, {"PLT", "Asia/Karachi"}, {"PNT", "America/Phoenix"}, {"PRT", "America/Puerto_Rico"}, {"PST", "America/Los_Angeles"}, {"SST", "Pacific/Guadalcanal"}, {"VST", "Asia/Ho_Chi_Minh"}};

看标题以为有显摆，结果没有

@Betacoefficient CST 在 JDK 中是美国某个时区

单机可支持数百万以上 TCP 长连接 ，你确定？