既然前端发展出了 serverless，前端控制一切的系统。后端当然也要发展出 clientless，只返回静态的 html，所有逻辑全在后端控制的系统。

试用过一段时间，不看好：

1. 效率和灵活性上还是不如 ruby，语法还分叉了，也没法直接用 ruby 的脚本运行。
2. 生态和活跃度上也大大不如 ruby
3. 作为静态语言，开发工具的体验上还不如 ruby 这个动态语言。
4. 性能上 ruby 有了 jit，有了 ractor，差距在拉小
5. 真要极致性能的场景，还得上 c，c++，rust，甚至现在出现了新的竞争者 zig。

看到调查结果 ruby 份额还增加了。但是收入里 zig 排这么高，热门语言一个都没上榜，是用小众语言的都是大牛吗

服务都是要花钱的。长期稳定的业务早晚都自建集群。而创新业务不确定资源规模，还可能出现极端扩容的场景，云服务正合适

程序员最大的问题就是不会接单，甚至找不到接单合伙人

这才是长期维护的代码应该有的态度啊。人工回归测试的能力必然是有极限的，而代码的膨胀是无限的。没有完善的自动化测试，为了稳定性这不敢改那不敢改，最终就是屎山早晚重写。

ruby 语法太灵活，导致加新语法容易冲突。然后就这样了…。具体到上面的语法情况：

1. 右赋值是一种新的语法形式，感觉还好，多一种表达方式。相对右赋值，我觉得 regex 捕获赋值更看不懂，但一样是 ruby 语法一部分
2. hash 缩略写法，这个应该是从 js 那边抄过来的，写起来的确方便。但是 js 不需要后面：，会更好看一点。ruby 是语法冲突的妥协产物
3. 最后的调用，p a: 2, b: 3 ，后面传的是 keyword 参数，被 p 按 hash 收集了（ruby3 的 keywod 参数明确和传值的 positional 参数区分开了，避免了相关参数的歧义）。加｛｝那个则是和 block 语法冲突了。需要加（）避免歧义

总的来说，ruby 的特点是多种方式做一件事，充分信任程序员，激发程序员创造力，快乐编程。语法方面的最小惊讶原则，更多体现在熟悉了语言前提下的规则一致性，正交性，而不是可读性（比如上面模式匹配和 hash 简写法就是一致的。问题 3 造成歧义那个的确是 badcase，语法太过灵活还要一致不冲突挺难的）。 可读性和优雅虽然也是 ruby 的特点，但不是靠语言保证的，而是靠激发程序员的创造力，鼓励程序员多尝试，找到优雅的表达方式，是靠程序员和社区规范来保证的。语言本身只是不要成为表达的障碍。

还是有区别的，不变的数据可以共享，底层 C 扩展也可以并行且不受限制。介于进程和线程中间的一种状态吧

声明但可选安装的功能应该是 group 提供的 先用 group 声明可选安装，然后 bundle exec 的时候，如果环境变量里有 BUNDLE_WITH=对应的 group，就会确保安装并可以 require。否则可以不安装但一定不能 require

如果你是想通过 GemHome 里有不有对应插件来判断是否可以加载，bundle exec 没有这种能力。那可以 Gemfile 只做 bundle install 来保证 GemHome 有安装对应版本。然后直接运行脚本不要在 bundle exec 环境里跑。不过这种方式没有 Gemfile.lock 锁定版本的功能

bundle 环境的话，可选依赖是必须 Gemfile 声明的。声明了你就能 require 到。不声明就不能 require，没有对应集成。

是也不是。简单来说，ruby3 可以建多个 ractor。ractor 类似线程，但是互相之间不能共享可变数据，也有各自独立的 GIL 锁，所以可以并行运行。

api 靠生成 tags，有一个 gem-ctags 的插件可以在安装 gem 时自动生成。然后 vim-ruby 应该会改 path 和 tags 配置，这样就有基于 tags 的补全和跳转了

vim 的话，除了 lsp 的 solargraph 外，主要就是 tpope 大神的 ruby 全局桶，包括自动生成 tag，设置 path，关联文件跳转等等

ruby 的话，应该起一个服务器写 web 页面最方便

去 solargraph 提 issue，也许那天就解决了

不要妄想用技术手段解决政治问题

时不时会有稳定性问题。我都换成清华源了

你同事那种，叫单元测试，只保证自身的稳定性。外部依赖输入变了，那是外部的问题。用外部实际吐的数据 mock，也一样算单元测试。 你那种连 B 一起测试的方法，叫集成测试，保证的是 A，B 集成没有问题。 两种测试方法覆盖的目的是不一样的。单元测试要保证自身逻辑没有问题，所以覆盖面会很细，测试也需要很稳定，A 的功能没有变测试就应该能通过。集成测试则是全面的保证实际对外功能的正确性，受环境影响的随机因素比较大。比如 B 的输出数据变了，对应的测试 case 就可能挂，但其实都是正常的行为。因此集成测试的粒度就要粗不少，只测一些稳定的，关键的行为。

这 gem 发布出去，是不是需要使用方有 cargo 环境？

为什么上位机要用 G 语言输入？嵌套 js，ruby，python，lua 等等脚本不香吗

提 issue 让他们支持吧

相对它有啥优势？

加班至少应该 2 倍工资，所以等同于问月薪是否超过 9K

就是给架构师打杂

打工一般只能混个温饱。几倍的工资差距也就是吃得好点差点的区别。要想财务自由，只有靠投资和创业。资产的差距可以达到百倍万倍，而且还可以滚雪球越滚越大。

思维导图用 xmind，其他简单的用 uml，追求样式布局的用 draw.io

上面的字符串，用"\xff\xff"输入二进制字符串就好了。

感觉不是 graphql 不好，而是相关基建还不够完善，很多地方没有自动化和最佳实践，导致体验上没发展完善的 restful 好。能力上 graphql 是比 restful 强大的。graphql 也没限制用户用 restful 的方式，一个一个资源的请求处理。只是额外多了指定返回内容。这部分指定的内容感觉可以根据用户的模型自动生成。而且还多了字段变更的强类型检查。

战术减薪： 假设 10000 块工资 原定每天 8 小时，一个月 22 天，共 176 小时，时薪 56.8 自觉或者被迫加班，996，每天 12 小时，一个月 26 天，共 312 小时，时薪 32 减薪 44%

都有 gil，目前直接用，应该是 thread，因为可以自动切线程，调 C extensition 等一些场景可以放开 gil 并行加速。fiber 需要用专门封装的 api 才能达到释放切线程的作用。 另外 ruby3 要压榨多线程性能不应该用 ractor 吗