@junkk 是语法糖，但不是对象化，a |> x(...) |> y(...) 相当于 y(x(a))，用 pipe 可读性会好一点，编写的时候也会更符合人类思维（先用 x 处理再用 y 处理）

可能因为 JS 有 oop ，oop 链式调用可以达到相同的效果，只不过外部扩展需要有 extension method 之类的特性，extension method 可以覆盖 pipe 的功能。

@jorneyr 分发了才需要开源，服务端程序一般都是不受影响的，因为服务端本身不分发。对于 xxl-job 这种更加独立的服务端项目，需要开源的情况更少，就是你修改了代码，并且你的修改版分发给别人了（不管是花钱购买还是通过其他方式获得），获得分发后二进制文件的人有权向分发者获取修改后源码，其实这种情况几乎不存在。

@liuliuliuliu 你觉得 EF 的写法和我写的这两种有区别吗？基本连源代码字符串都差不多一样了。

@liuliuliuliu 你这个例子没什么难度啊，用 scala 的 sqala 这么写就行：
val users = db.fetch(query:
from[User].filter(_.age > 18).orderBy(_.name)
)
db.save(users(0).copy(name = "Dragon"))

甚至大部分人唾弃的 java 都有类似的库可以做到，java 的 drink 库 https://github.com/kiryu1223/drink 可以这么查
List<User> users = client.query(User.class)
.where(u -> u.getAge() > 18)
.orderBy(u -> u.getAge())
.toList();
只不过 drink 的更新不支持按照对象更新，用个 hibernate 之类的库配合就行。

@masterclock doobie 不是 orm 呀，算是个简易的 sql builder ，都与 sql 构建器，我推荐一个 sqala
文档网站： https://wz7982.github.io/sqala-doc/
scala 用户站介绍帖： https://users.scala-lang.org/t/sqala-compile-time-sql-for-scala-3-with-named-tuples-and-semantic-checking/10837
我个人也不喜欢 ORM ，隐藏太多细节了，门槛太高，个人感觉 sql builder 完全够用够好用。

现在大部分 AI 补全都有这个功能，next edit suggestion （ NES ），你可以点开对应 AI 工具的设置看看，一般都有的。不过 roocode/cline 这种不太一样，他们是纯 agent 类插件，不带补全功能，你要结合其他的一起用。

个人认为，低代码和开发者使用各种组建库开发没有区别。只是把调库变成了页面上选择库里的组件。调库一般也都存在一个问题，一个库封装程度越高，原子化能力越少，越易用，但是也越难定制，除非你去改库的源码。使用第三方低代码还存在一个问题，容易出现大量的限制，不像直接调库那么自由（比如你想和其他库组合一般会比较容易），在比如 http 调用相关，低代码平台如果不支持私有化部署，那就需要你把接口开放到公网并添加加密，这不管是开发还是安全上都是有额外开销的。

“一个老板一直在问 AI 有多强，听他的意思他好像想裁员了” 正是我这边在发生的事情，落泪了，目前有一些非开发岗位已经开始裁员了，最后肯定也会影响产研类岗位。

“在线工具箱”感觉排版上易用性还是 ctool 这种好一些，在使用一个工具的时候可以便捷地切换到另一个工具，或者提供多 tab 支持（作为程序员工具箱功能还是过少了，主要优点是界面比其他的工具箱美观）

@Ffffanwu 卖的是代码吗，license 是 AGPL ，贡献者的代码自然也是自动为 AGPL ，既然是 AGPL ，就不需要卖别人就能获取并修改，只是要求继续使用 AGPL 提供源码。那卖的只能是主干仓库和官网之类的内容。所以，做开源的时候一定要了解一点 license 相关的内容。

远程 IDE 或者编辑器终究是比不上本机方便的（比如 idea/vscode 用远程连接到 wsl 或者 linux 虚拟机）。
在 windows 上直接开发容易遇到几个问题：
1. GBK/UTF8 问题，虽然现在很多软件都默认 UTF8 了，比以前好了很多，但真的遇到还是难受（比如我刚学 java 那会儿用 tomcat 就乱码，还得找教程改环境变量什么的，Linux 很早就普及默认 UTF8 了，这方面好不少）
2. 长路径/长目录问题，如果你用 idea 做过开发肯定碰到过它提示命令太长无法执行的问题，需要改成 jar 模式运行，本来直接 jar 模式也没啥问题，奈何我之前做了个项目，需要一定的动态代码片段，所以我索性直接用 groovy 了，结果在 idea 上直接运行 groovy 报错命令行过长，而且这个没有 jar 模式。无奈我自己改了配置，使用 jar 启动调用 groovyshell 来执行对应脚本文件规避该问题。
3. NTFS 的小文件性能问题，这方面最近有解决方案了，windows 上现在可以使用 devdrive 改善，不过还是没有 Linux 快。这个性能影响的主要是编译场景，devdrive 可以提升 10%以上的性能，Linux 上会更快。
4. docker 使用的麻烦程度，现在 win 上 docker 只能运行在 wsl2 虚拟机上，端口转发比较不爽

看到推荐原子能的我就绷不住，v2 程序员水平已经次到这种对技术毫无探索就下暴论的 up 主都要推荐了吗？我记忆中的暴论视频至少有两个。一个是说差 1 错误的，说了半天为什么数组 0 起始是错误的，这个观点哪怕稍微做点搜索，看到迪杰斯特拉的见解也能知道不是大问题。另一个是说异常的，没有对 CE 做了解，对 rust 的和类型返回也是一知半解。我觉得这样的观点输出者火起来只会造成观众的水平下降。

严谨不易出错只要类型系统够强都能做到，不需要引入 effect 。依赖注入个人认为 spring 的这一套依然是最易用的，缺陷是编译器无法知道依赖是否存在，但是问题不算太大，只要你的组件不是惰性的，启动时也会报错，不会在提供服务时出错。（ spring 这套在有宏的语言里可以做到编译期生成从而确保依赖存在）。单元测试对于结构类型的语言应该很容易实现替换，对于 jvm 上的则因为 jvm 强大的动态代理很容易实现。对于编译期功能强大的语言也有编译期处理的方案。
Scala 3 现在主推的是 direct style programming ，直接简单的，普通开发者能理解的。可以说会 java ，就会用 direct style scala 。而 scala 2 时代社区基本都是 effect system ，门槛太高了，收益不明显。（当然 jvm 上也受到虚拟线程发布的影响，虚拟线程这个抽象方案让结构化并发变得很简单，异步代码可以很容易被集成到同步代码中而没有明显的性能影响，虽然极限性能还是比不过全异步生态或者 effect runtime ）

@wowpaladin scoop 只是多了安装、初始化的步骤，楼主写的东西太细了，实际上使用只需要几行命令就可以开始。
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression
scoop bucket add main
scoop bucket add extras
这样就初始化好了，后面安装就是
scoop install 7zip
这样
scoop 比 winget 好的点是他把所有软件和他们的配置都保存到一个目录下了，比较易于管理。而且安装时不会有任何弹窗，不会索要管理员权限，软件都是安装到用户家目录下。

@amorphobia 不建议所有东西都用 scoop 安装，特别是那些支持自动更新、增量更新的软件。scoop 安装库(比如 vcredist)和 cli 工具就好了，图形化工具大部分还是建议直接官网安装器（比如 IDE 、浏览器这些），比较小的软件比如 altsnap/everything/7zip 这些还是可以用 scoop 的

浏览器的话可以安装一个 surfing keys 然后按键盘的 d 往下滚动，e 或者 u 往上滚动。其他 pdf 阅读器类的软件一般也有类 vim 快捷键，可能是 j/k 移动，u/d 移动的。

@jheroy 这个选项是默认启用的，我也试过手动启用了，还是不能这样补全，你可以试试

@lelelelelele 设计模式是好东西，好到一些语言专门把特定的模式简化到了语法设计上。但是要避免做啥都上设计模式的思维。java 8 引入 lambda 之后可以考虑部分设计模式使用 lambda 编写来简化代码（比如策略模式可以是 Map<TypeEnum, Function<Input, Output>> strategies;）
设计模式其实在其他语言上也非常普遍，我不知道为什么很多人说的好像设计模式是垃圾一样。
我举几个例子：
1. python 语法上直接支持装饰器模式（函数装饰器），js 也有对应提案
2. 迭代器模式不用多说，增强 for ，现在各种语言支持的函数式 map 、enumerator 之类的东西
3. 观察者模式，响应式库都是这套，流式数据处理也一般需要观察者模式
4. 单例模式，kotlin/scala 直接引入 object 来支持（当然也是为了万物皆对象，摒弃 java 的 static ）
5. 代理模式，kotlin 直接支持 by 委托
7. 建造者和工厂，现在有些语言没有构造器，习惯上手写 builder 的很多

也有看到国产就反对的人。以 fastjson 作为例子：
fastjson 总是有人说漏洞，但是你实际去查询一下 cve 数量发现 jackson 比 fastjson 多得多。开源项目有漏洞本身就是挺正常的事情。（ log4j2 出大漏洞最后不还是该用用）而且 fastjson2 重新设计就默认关闭 autotype 了，也不是那种不维护的项目。至于性能相关，fastjson2 做了很多优化，wenshao 也给 openjdk 的 committer ，给 jdk 提交过一些代码（虽然有部分是为了提升 fastjson2 性能的，但是也是优化，在其他地方说不定也有用）
我个人认为，fastjson 这个库除了灵活性差，非定制化场景易用性和性能都是足够好的（ java 生态下，其他语言可以有更好的，java 的元编程手段比较单一，基本都是靠反射和字节码操作导致很少有编译期保证安全的库）。