现在大部分 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 的元编程手段比较单一，基本都是靠反射和字节码操作导致很少有编译期保证安全的库）。

@yh7gdiaYW 静态检查的部分没必要带到运行时，运行时需要的检查可以用 pydantic 之类的设施补全。支持复杂类型系统的语言大部分类型信息也是不会留到运行时的，因为运行时不需要。（而且不留到运行时这样抽象反而是零成本的，资源消耗更少，当然用 python 就不考虑这个了）

@JYLu 和 Typescript 那样的差距很大是指什么？如果说是类型运算方面的，那确实没有，但是仅仅是类型提示、静态检查错误检测，python 已经完全具备了。你只要使用带静态检查的语言服务器开严格模式就可以了。复杂代码也是一样的，python 和 typescript 一样支持字面量类型，union 类型而且还是自带 tag 的 union 类型，这方面反而比 typescript 要好用点。

@ExplodingFKL aot linking 对于客户端软件算是很有用的功能了。compact object header 也是很有用的特性，虽然还是实验性的，现在也只合并了半个实现（ 8 字节对象头），4 字节版本合并到 lillput 上了，还在更新支持各类 gc 之类的。对象头的缩减对于服务端程序感觉能减少 10%以上的内存占用，还能够减少 gc 压力，对性能也会有提升。

@yazinnnn0 要在 lambda 中使用变量的话，最好的方式是使用一个包装类，性能最高（数组开销比单个引用对象大）。可以直接使用 apache commons 库里的 MutableInt/MutableObject ... 之类的类型。

换 neovim 会好点，neovim 自带支持 osc52 ，vim 需要插件来支持。详情看 :h clipboard-osc52

tab 在不同地方一致性的问题在现在不是问题，主流编辑器/IDE 都支持调整 tab 的显示大小，github 也支持个人设置里设置 tab 的显示大小，或者在地址栏里使用 ?ts=8 参数可以调节代码中 tab 的显示大小。
tab 的好处就是不同人不同显示设备可以按照个人喜好随意调节而不破坏原本的代码，不过实际使用时可能要用空格补齐对齐，而且不同 ts 大小会导致对齐被破坏。例如下面的 python 代码
l: list[list[int]] = [[1, 2],
[3, 4]]
这里 [3 前需要空格补充对齐，而且换个 ts 可能就会导致左中括号和上一行无法对齐。（例如这个变量名 l 是很长的一串）
this_is_a_long_variable_name = ... 这样的东西，换个行来对齐就容易出问题