servo 还早的很，试一下就能明白了。要内存占用低可以找老版本的 chrome ，但是我建议还是加内存吧。火狐不好说，不一定比 chrome 节约内存（我自己就用火狐）。火狐有一些挺好的调试功能，编辑和重发之类的，但是网络响应总是要结果出来才显示请求头，eventstream 也不是逐条出现。
可以尝试下微软的 edge ，调试功能相比 chrome 有改进，内存占用我印象中在 windows 上比 chrome 低

感觉也需要好的机会，前段时间 aws 挂了导致 postman 无法使用的时候，yaak 可是一下子 star 狂涨。但是这些工具都还比不上 reqable 免费的版本。

spring boot 的学习成本很低，低到不太会 java 的人经过简单培训就能写后端 json api ，有些学校安排的培训可能只有一个月都能学会（还包括数据库之类的）

你真要的话有 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 虚拟机上，端口转发比较不爽