Click Lab 98 

@FrankHB 越是这种情况越是没理由？ python 的科学运算库可不少啊，底层都是 C ，性能相比其他语言也没太差，DL 方向用的最多的语言是哪个不用我说了吧

不要玩 python 慢的梗了，python 很多对性能依赖高的包都是 C 写的，使用起来性能差别不会特别大。关于 GIL 有 nogil 项目，虽然不知道什么时候能并到主线： https://github.com/colesbury/nogil

上一层少打了驱动两个字。顺便说一下我安装 linux 遇到的唯一问题，安装后没有声音，后来安装了 sof-firmware 就好了，和声卡有关，如果遇到相关问题可以尝试下这个解决方案。

什么年代了还在说 nvidia 的兼容问题，几年前闭源显卡就在 linux 上跑的很好了，现在还有开源显卡。我个人现在使用的是暗影精灵 8p(3070ti)，装 archlinux + nvidia-open 开源驱动，开源驱动现在遇到的问题是 nvenc 无法正常使用，其他都很正常，介意的使用闭源驱动就好，闭源驱动需要添加一个内核启动选项 ibt=off 才能正常使用。

@PhaSelEza 禁用 X 的话 electron 应用全都无法使用输入法，个人认为没必要舍弃 xwayland 。顺便推荐一个 wm ，Hyprland ，更好的动画和更积极的更新。sway 更新比较缓慢。

@wjx0912 scoop 有些想法其实挺不错的，比如不同版本只是不同的软链接，比如用户级别安装不用考虑权限问题。比如各种配置文件都单独放置在一个目录。而且打包也很方便，直接整个 scoop 目录赋值到另一台电脑上很快就能用

试试 httpyac 吧，用法基本和 http client 一样，有 vscode 插件版本和单独的 cli 版本，直接用 vscode 插件版就可以了，可以直接写 js 代码来组装参数，可以生成不同编程语言或者 shell 的调用 https://github.com/AnWeber/vscode-httpyac

尝试把 idea 的虚拟机最大占用内存改大，或许会有所改善，我个人使用的是 2.5G

@shawndev 虽然是编码问题，但是 win 下默认情况直接安装 vscode 跑 python 就是这种结果。win 的编码历史遗留问题一直不解决，小白学编程的困难就会一直在这儿。（ win 的 utf8 怕是一直有个 beta 标识了）

@NoNewWorld Manjaro 并不省事，起码不比 Arch 省事，可以看这篇博文： https://zhul.in/2021/01/01/Why-I-dont-recommend-Manjaro 不建议不愿意折腾的新人使用滚动发行版（包括 Manjaro ）。

@Mithril Linux 下驱动更新和卸载可比 win 方便多了。声卡现在靠 sof 项目也不错的。比 win 差一点的应该也就没有杜比全景声这类玩意了。不过要改音效有 easyeffcts 这类工具。

@NoKey vsc 官方有提供预置了 java 插件的安装包（实际上和手动安装没有差别），体验嘛，就一个字 “烂”，当然，写写 LeetCode 这种单文件代码的体验还是比 eclipse 好点的。做项目就算了

@wolfie enhanced-for 是使用 iterator 的，但是 forEach 的实现取决于 Iterable 是怎么实现的，例如 ArrayList 的 forEach 是 fori ，至于性能上，使用 forEach 会创建一个 Consumer 的匿名类对象，不过这个性能影响可以忽略不记。stream 里的 foreach 实现和 Collection 里的也是完全不一样的，stream 会创建新的对象来持有容器内的数据再作处理，不过 stream 可以使用 parrel 提升性能，如果直接使用，性能是不如 enhanced-for 或者 fori 的。

关于简洁和性能，使用古老的 apache commons + google guava 工具包就能解决大部分 stream 能解决的问题，而且语法更简洁，性能也更强。例如 guava 的 Maps.uniqueIndex 和 Multimaps.index 我就经常用。关于时间类型，如果使用 Date 类型，大部项目也都会有个 DateUtils 之类的工具类，内部怎么实现没人管（很多时候我会选择使用 java.time 包下的工具实现），反正最后数据是正确的就行，而时间的 parse 和 format ，我更倾向于使用 commons 的 FastDateFormat ，性能更好，占用内存小，而且线程安全。

@karloku 一边热爱开源，一边用 vscode 搞死 atom 。一边热爱开源，一边用 winget 借鉴并搞死 AppGet

@nothingistrue 我的意思是官方文档只从来没说过 java 编译器能做到向后兼容，但是说过保证 vm 下运行二进制兼容。至于以前版本的不兼容性可以从 oracle 文档上找到，比如 https://www.oracle.com/java/technologies/javase/incompatibilities.html https://www.oracle.com/java/technologies/compatibility.html
jdk9 最大的改动应该也就是模块化（实际上影响并不大，大部分在 jdk8 下写的代码能在 jdk9 上编译）但是 jdk16 加了模块安全性相关的功能，需要加额外启动参数。个人尝试过升级 jdk8 的项目到 jdk17 ，遇到的问题有：1.lombok 兼容问题，升级 lombok 就可以解决 2. javaEE 模块在 jdk11 时被移除，通过 maven 重新引入即可解决。3. sun 包被移除，但是能在 java.util 下几乎都能找到替代类。4. jdk16 引入的模块安全问题，加启动参数即可解决。

@zrc 部分设计模式的出现是因为语言本身的表达能力不够，很多用函数式写代码的人几乎不考虑设计模式。（可以看一下 github 上的一个项目 https://github.com/niltok/magic-in-ten-mins java 写的函数式编程）。jvm 如果足够强大，可以在运行期间检测运行状况并调整自身的设置（例如根据当前运行环境的内存和对象大小自动调整 gc 触发的时间）那么也不需要调优。目前 ZGC 是宣称最大 gc 时间不超过 1ms 的。

@nothingistrue jdk 本身就不向下兼容，jdk 的兼容性只是二进制兼容，即 jdk8 编译出来的.class 文件可以在 jdk17 的 jvm 上运行