你真要的话有 Embedded Postgres ，可以当作测试依赖使用。不过我建议对于数据库直接 mock 使用

感谢更新，这下很舒服了～

功能非常耗用，请问 UI 可以优化下吗，在我使用的主题(catppuccin-frappe)下边框黑色有点丑，或者能不能去除边框

@wonderfulcxm DBEaver 就是 Eclipse 平台的，在 Linux 上会稍微好看点（因为能享有 GTK 全局主题设置），win 上这套就很丑了。Eclipse 平台最大的问题是很多操作都会卡住 UI ，体验很差，dbeaver 也是，查询的时候如果连接比较慢，就会 ui 卡死一段时间

@maymay5 DataGrip 我大概 20 个数据源，同时操作一般不超过 5 个连接，内存占用起步 700M 左右，如果单页展示数据量不超过 100 列 2000 条的话，总体不会超过 1.5G 的占用

@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 好的点是他把所有软件和他们的配置都保存到一个目录下了，比较易于管理。而且安装时不会有任何弹窗，不会索要管理员权限，软件都是安装到用户家目录下。