这要说的话肯定是“架构编程”最难，这个“架构编程”指的是“决定你的程序该干什么事情”，虽然程序也不一定是，甚至一般不是你写的，但是哪怕写得烂也没关系，这一层的东西直接决定了项目的前途。换句话说就是战略级别的“对人编程”。
不过这个一般是姓 C 的人考虑的事情，跟大多数人没啥关系。要说工程层面的话，我认为是“know-how”，先帝懂王普的时代，这个词经常出现在大明的新闻里，不知道还有没有人有印象。
各种领域的原理、公式、算法，这些写在教科书、论文里的东西，正常人只要肯下功夫，大多数都能搞懂。但是看完之后再用到 non-trivial 的项目里面经常会发现和书上写得不完全一样，这才是真傻眼的时候。
举个例子吧，比如前端做个页面效果，虽然做完交差了，但是自己看着总“差那么一点意思”，怎么折腾都调不好，虽然别人可能不会在意，但是事后想起来总有一种便秘的感觉。前端库很多，资料教程很多，你技术都掌握了，但是就 TM 差这么一点 ...

其实可能就是哪一组参数不太合适的问题，但是怎么定位到问题？我找到了之后又该怎么调？
类似的例子还有很多，比如为啥某某软件很流畅，某某就很卡；挑个手机经常会看到什么屏幕 /摄像头 /续航的“调校”，手机是高科技产品，那你 TM 从技术的角度给我解释下这个“调校”是啥；基础算法大家都会，项目里面的实际问题需要设计新算法该咋办；一个 ML 的项目，选啥模型，怎么调 ...
这个也不局限于软件领域，做个饭都有刀工、火候、调味的讲究，同一所学校，有的人平常看着普普通通考试必然前三，有的人天天做题成绩也就那样。不过情况都是一样的，同样的工具，别人的结果比你的更好，你还不得不服。

所以某些公司喜欢折腾什么“XXX 原班人马打造”——人家之前搞出来过的 XXX 大家都知道，都能抄，但就是抄不出那个“味儿”，偏偏最关键的就是那个“味儿”。这就是我对“know-how”的理解，写在书上的都不是最难的，没写上去的，或者没法写上去的才最难。

@ferock
我并没有认同 #42 ，主要是想表达“根据个人情况不同，不同的工具可以用于不同的用途，并没有通用的‘最适合’”这么一个观点，我想在这上面咱们应该是有共识的。

我倒是觉得 #3 从一开始就没有专门开回复的意义 :)

@ferock 我说的是“回复”里的“最”，主题里的“最”只有“最开始”“最后”“最新”三种用法，表示价值判断的，你依然是第一个。
我认为你在 #1 就有把你认为“终端用 win 或者 mac 才是最顺滑的”的个人经验套在别人身上的倾向。很明显楼主和 #3 都不同意这个看法。

你说
> 某一件事情，哪个舒服用哪个不就完了
现在问题是楼主大概不认为 Windows 能用舒服，虽然他并没有正面回答这个问题。#3 也不这么认为，虽然举的一堆“例子”很蹩脚。

再往后就掉进了
> 做技术的总可以想到一些办法解决问题，那这样扯就没底了。
的坑了
包括就算是基于 Windows 想办法解决 Docker 的问题，也大概率会涉及到一堆比较主观和个人的东西。

@ferock #41
我认为每个人的偏好和情况是不一样的，不能用个人的情况去硬套他人的情况
比如对我来说，“原生”的游戏就基本不是个事，但是 Windows 和 Mac 没了 perf_events 之类的东西倒要考虑一下，所以你的例子在我看来有点奇怪

> 你自己心里有 “最棒”，“只配” 满世界都是 “最棒”，“只配”
不如搜索一下回复里面的第一个“最”字出现在哪 ...

@ferock
> 不要和我提 dxvk 、Wine ，当然说的是原生！扯太多太浪费时间
来浪费下时间：为什么非要“原生”？

我感觉你的主要问题是“做业务做烦了”吧
然而底层也一堆奇葩 bug ...

找几个最近用 Linux 遇到的吧：
https://bugs.kde.org/show_bug.cgi?id=377901 KDE 桌面环境在开机 49 天后准时坏掉，窗口只能切换不能移动，因为一个 timestamp 溢出了
https://github.com/ggreer/the_silver_searcher/issues/168 ag 搜啥都搜不出来，原因是我搜的 git 仓库在 .gitignore 里用了 ! pattern ，然而 ag 不支持（这个到现在居然还没 fix ，换 rg 了）
https://github.com/openzfs/zfs/issues/12971 ZFS 文件系统下的文件在新版 Linux 内核下调用 splice 和 sendfile 等系统调用会报 EINVAL ，原因大概是新版内核改了某个内部 API 的名字

我感觉很多事情并没有本质性的变化
不过一般不会周末丁你一下就是了，这算是个好处

> 可能从出现 机械飞升开始 100 年 就能让人类失去存在的意义
不如想想现在人类存在的“意义”是什么，个体存在的“意义”是什么

科幻小说的重点也不是未来科技，外星文明啊 ...

程序一般不会出错，但是可能会随机触发五大善人中随机一人的核按钮

这个确实没错
当然反过来说很多软件在 Mac 免费，在 Win 没有也没错（移动生态不清楚）

你没法“像操作 Window 和 Mac 一样操作 Linux”，至少在 https://medium.com/@probonopd/linuxusability-have-no-respect-for-the-status-quo-cf736db2c764 这老哥吹的牛逼实现之前，这俩就是完全不同的东西

楼主就是没提跟性能相关的场景，一半都需要折腾内存

简单换个 malloc 库就可能有几个点到十几个点的提升
前俩月一个业余项目，就弄了个简单内存池，就少了几倍 cache miss

这贴快三十楼了居然还没有 #5 所提到的回复，匪夷所思
哦才发了五个钟头啊，那不用担心了，过段时间一定会有的 :)

对于个人用户来说 Debian 如果你用 stable 是会稍微有点老，可以考虑 unstable ，Ubuntu 也是基于 unstable 的。
当然都比不上世界上最好的系统 CentOS 7.

而且包管理器用啥语言写有啥关系么，这东西偶尔用一次又不是 daemon ，Portage 用 Python 写的，yum 以前也 Python 写的，Nix 还自己整了个语言来描述包

另外 Nix 默认装起来很快的，你跑不完可能是因为网络问题

不是坏事，要是用 Linux 必须要摸透这些东西的话，那怕是 1% 也不会去用 Linux

话说 Steam 虽然是 CEF ，用起来简直不是 Electron 胜似 Electron

@Buges 网站不错

是的，每年都可以庆祝"the year of Linux desktop"

很有意思的是，造成 C# 在特定领域不如 Java 受欢迎的最重要的，众所周知的那个原因，也亲自指挥、亲自部署了 TypeScript 的推广。
而 Java 这边是无法想像这种事情的。Java 这边也有一个“原因”，也要出新东西，但是貌似依然是要收费的？

Java 这个路径的问题本来不是什么大问题，但是实际对一部分人（主要是不用 IDE 的人，或者会用 IDE 的但是暂时没有用 IDE 的人）造成了 ergonomics 的麻烦

比如 GitHub 上面，打开一个 Java 项目，想简单看下源码要点 N 多次，这还是 GitHub 也“优化”了文件夹嵌套的情况下
就算我 clone 下来，直接用 shell 访问也要敲 N 多次键盘（还不说 clone 本来就多一步）
这些情况都可以装插件来缓解，但是在一个比较简单，插件比较少的环境中，这就成为了实际的问题。
一些其他生态中，很大一部分开发者就属于这种情况，那么 Java ，或者 Java 生态对于他们来说就是“麻烦”的。你不得不承认如果没有“专门优化”，处理文件比处理文本要麻烦十倍。

这不是说 GitHub ，shell 或者其他生态做得多“好”，实际上屎的东西很多。Java 世界做出了全面偏向 IDE 的选择，是有利于隔离外面这些屎的。（至于 Java 自己一堆历史包袱和生态内部问题搞出另外一大坨屎那是另一个问题）
但是问题在于某些 Java 开发者的心态——既然自己决定了主动与其他人隔离，就不要在意其他人的想法。但是某些 Java 用户不仅没有这个觉悟，还振振有词“Java 适合做带项目，你看我们的带项目多牛逼”

问题是为了做“带项目”，就一定要抛弃“小项目”么？我认为这就是 Java （或其生态）在不欢迎它的群体眼中的最大问题。一个旁例是 C#，C# 在语言本身的风评上总体比 Java 好（好像越来越齁是一个问题），生态上则主要集中在那个众所周知的问题上面。C# 也能做带项目，这些带项目中一样各种设计模式啰哩啰嗦，一样嵌套一堆文件夹，但是 C# 也有很多小一点的项目，GitHub 上高 star 的 C# 项目中并不难找到文件夹嵌套和其他语言差不多一个水平，目录结构非常简洁的项目，大概和 Swift 项目的感觉差不多吧。而这并没有影响 C# 做带项目。

我的观察是这种现象与项目的 domain 是强相关的，某些领域的项目做得就很 Java ，某些领域就不那么 Java 。所以 Java 这些特点可能与此也有点关系。

ergonomics 的另一个例子是 ... TypeScript 。可以说 TypeScript 设计上是想要把 JavaScript 往 C# 的方向扭（毕竟这俩同源，虽然最近好像没绷住变成了 Scala :P ），有一些 TypeScript 项目也出现了 “Java 味”的雏形（暂且不用“重”这种定义模糊的词，我们就用 Java 来定义 Java 和“不知道哪个时代的 Java 特色编程思想”）。但是人们讨论 TypeScript 时，好像主要是在讨论它的 Scala/C++/Haskell ... 味，而不是“Java 味”，这一方面当然是因为很多人本来就对 JavaScript 有更多的“Java 味”的需求，另一方面就是 TypeScript 的 ergonomics 做得不错——不仅是不错，而且可以说几乎就是 Java 的另一个极端。

TypeScript 解决问题的方式很巧妙，考虑一个问题：TypeScript 的 killer app 是什么？ TypeScript 的 Rails ，Docker/K8s ，Flutter 是什么？
GitHub 的数据告诉你是 VSCode： https://github.com/search?p=1&q=stars%3A%3E1000+language%3Atypescript&type=Repositories （前两个是 Markdown 项目）
这就很有意思了，因为 VSCode 这个项目本身是 TypeScript 开发的，但是领导核心是 Eclipse 正统，代码也挺 C#，内置了（非常不错的，“原生”级别的） TypeScript 支持。和 Eclipse ，IntelliJ 一样，VSCode 不仅仅可以用于 TypeScript ，并且这部分人还不少——VSCode 官方插件市场里面，Python 、C++、C# 都买了热搜（讽刺的是往后一点就能看到 Java 的热搜），后面还有 Go ，PHP ，Dart ...
暂时无法对比这些语言和 TypeScript 的数据，因为 TypeScript 的支持是 VSCode 内置的，内置的，置的，的 ...
反过来想，就是这些语言的用户，都是 TypeScript 的潜在用户！

我个人主力用 VSCode ，写 C++、C#，OCaml ，Python ，当然还有 TypeScript/JavaScript 。JetBrains 做了 Rust 的 IDE ，但是像 Haskell 这种不可能有人给做正经 IDE 的语言，也把支持 VSCode 和 LSP 作为第一优先级，OCaml 官方教程给新手首推的就是 VSCode 。这部分长尾，VSCode 也全吃下了。
虽然 Electron 在资源占用方面也很“重”，但是反正我写其他语言也要装这玩意，从开发其他语言的 VSCode 用户，转到 TypeScript 开发者，在 IDE 方面没有 overhead ，也就是装个 Node.js 和 npm 的事儿。
这就是另一点了——JavaScript 从小做起，人家做小工具也不差，所以我装个 Node.js 跑个小工具也不亏。
赢麻了。

@secondwtq s/狠，真 /狠，原来是因为都去搞开源了，真