有道理

基本方法被反复调用。

用户角度分析：

1. 用户经济实力不行。玩家群体：青少年、学生党肯定不行，成年人背上房贷和小孩也不行，只有高工资白领。
2. 用户时间，有消费水平的白领，在 996，他们不是在加班就是在睡觉回血。这个群体可以焦虑但是很少会持续投入在游戏中。
3. 居住条件，高端游戏需要买主机、而主机还需要一个房间。城市的打工人，普遍在租房，租房生活质量不高，抑制买大件欲望。

简单的说，玩家不论是 经济实力、时间、生活水平都支撑不起来市场。

如果一个市场没有容量，优秀的作品也就不会涌现。 一部佳作，需要大量的从业者、用户堆砌中，产生。

政策角度

1. 版本号
2. 创业门槛

现在都太高了。游戏投入本身就高，会因为政策约束血本无归，倾家荡产。 靠兴趣支撑的，游戏这种可能会啪啪打脸，游戏的投入非常高，属于重资产 项目。个人能做的题材非常局限。

这也束缚了作品的数量。

不会。因为不是根据词法分析的，是运行时分析。如果出现循环调用的程序，你自己的程序死循环，爆栈退出，那么 trace 本身也会被退出。不会获得最后的图谱。

用 vistual_call 分析 vistual_call 自己

require_relative "vistual_call"

def call_a
end

VistualCall.trace(title: "Outer", show_dot: true) do
  VistualCall.trace(title: "Inner", show_dot: true) do
    call_a # whatever
  end
end

用的人很少

超出资源和四个动词的概念就必须得额外约定。

RESTFul 只是一个 CURD 业务场景下的推荐标准，尝试标准化，只是一个功能子集。

很容易就突破 Restful，比如 search 这个动作，就很容易打破 Restful 他不属于 资源，又会超出四个标准动作。

Python 简洁的语法，以及 C 包装了一层，逻辑非常简单。多编程范式，主要是函数式的表达接近数学表达。早期被数据科学家当做穷人的 Matlab。现在变成了标配。

有了巨大的科学家用户群，才有各种处理数据的计算模块，其实这是生态的问题。

Ruby 的语法比较花，如果用来描述数学，就比较缺乏一致性。 Ruby 的花式语法，就是他的设计特性，主张模拟自然语言，文学性编程。虽然多样，但是都是模仿自然语言。

Ruby 能诞生 ROR 的原因是，ROR 的作者把元编程（Ruby 击中优化的特性）玩的非常 6，主张根据约定自动生成代码。这才有了非常特别的 Rails。 提高 Ruby 的性能也没什么毛病，因为动态非常慢，提高性能，可以帮助任何元编程的程序提高速度。

语言工具本身是中立的。设计的时候带有设计者想表达的特性和目标。 最终语言发展取决于生态，也就是用户大量的贡献，以及出现杀手级应用。

正常

没有直接用 windows。

Ruby 的实现依赖于 Linux 更多。

你可以在 Windows 中启用 WSL 上跑 Linux 再尝试下 Rails

你需要糊口，这个可以让你糊口就有价值。 你觉得无聊，这个帮你缓解无聊就有价值。

人是价值的尺度。

借用 西西弗斯神话：

生命过程本身就是荒诞，可以自己在荒诞之中找点乐子。

世界上只有一个 Linus，成为历史上的人既需要实力，也需要运气。 大多数平凡的人，可以用技术工作来糊口，也可以通过摆弄程序解决些无聊的时光。 大多数人一辈子注定徒劳无功，但是可以找点事做，点缀自己有限的生命。

个人觉得有乐趣的东西，不会是生命解药，但是可以像是麻药，让你可以有那么一小段时间忘记漫漫人生荒诞痛苦。

windows 里用 WSL 跑 Ruby

Ractor 的目标就是利用多核。计算密集任务且任务之间不依赖可以跑满多核心。 虽然还没有正式，但是已经可以用了。我也试过能跑满。

文档：

• ruby3/ractor

Conf:

• Ractor Demonstration - Koichi Sasada
• Ractor report Koichi Sasada -ko1

Ruby 里面你可以选的有很多：

• 单线程中，自己手动调度的协程 Fiber
• 因为虚拟机锁，受限于同一个 CPU 核心的多线程 Thread。
• 完全利用多核 CPU 的——Ruby3 的 Ractor
• 多进程Process

收到礼物 感谢活动举办方，辛勤的工作人员

祝越来越好@baidingding

把线程方案那段注释去掉 98 行 :D

可以直接用。比如你有 10 个爬虫任务，丢给这个类。完全可以使用。并不是玩具代码。 :D

个人结缘 Ruby 的故事：曾经的老东家是 Ruby 起步，一路走到美股上市。虽然是前端岗，但是对每天合作的后端同学使用的这门语言其实是最熟悉的陌生语言。

后来有一个机缘巧合希望可以做一个轻量级的语言，了解到以 DSL 为特性的 Ruby。踏破铁鞋无觅处，得来全不费工夫。

初步了解 Ruby 之后，觉得设计性十分有趣。后来学习关于 Ruby 内部原理、元编程、设计模式……一发不可收拾。

Ruby 的内部相对于我经常用的语言 具有内在的设计一致性，最小惊讶原则，一致性的面向对象，吸取了 LISP 的动态性，但是又保持克制。我曾经幻想过有没有一个语言可以实现文学性编程的想法，Ruby 可以实现这点，可以设计出可读性出色的程序。我最喜欢的除了它内部还有他的标准库，我称之为 有求必应标准库。凡是我所想到的，皆有实现。从常见的线程，到内部数据库实现，还有分布式支持……

后来一段时间，我研究过 Ruby 的 Web 框架，浅尝辄止了 Rails，重点关注了 Rack、Sinatra、Roda，实现。可能来自于我对 微框架和自己掌控的偏好。我反而不熟悉 Rails，这是十分另类的。

Ruby 成了良师益友，可以学习她现存的资产，也可以使用助自己一臂之力。深入理解 Ruby 丰富的特性，当你遇到看到一些别的语言的特性，总能在 Ruby 中寻找到对应的存在。

现在 Ruby 是我的第二语言，我喜欢用它学习，实现原型，实现脚本解决我工作中的问题，做自己的网站，还有小游戏；偶尔工作中，我也会塞点 Ruby 的项目进去。 :D

我对 Matz 作者也很感兴趣，也喜欢读 Matz 的书。他是我比较喜欢的类型的程序员，爱表达自己的思考、细致、谨慎、思考全面，从他的文章可以看出他的思考。我很欣赏作者这样自省又对外有所思考的人。Ruby 对外有一种日式匠人打磨的感觉。

对 Ruby 的喜欢比较由内而外。也认可动态语言是一种趋势。靠近 LISP 的是正确的方向。

随缘写下故事。最后，Ruby 的闪光点一定会被欣赏的人看到。

计算机发展快 30 年了。低代码也不是新概念。

后台做做表单，固定的活动页面可以。但是如果是活动页，可是这种东西，往往没啥竞争力 —— 因为无聊，没有表现力。

如果做不到图灵完备，等于不算真正的低代码。只能算是 组件拼接器。 如果做到图灵完备了，那和写代码一样了，还不如写代码。与其交给运营、产品写。不如交给专业的人做专业的事情。

个人愚见，能解决重复的任务。但是重要任务，他就没有重复的。

产品是不断应对市场变化、竞争对手的。所以他必须不断与时俱进。总结就是没啥未来。毕竟历史上反反复复出现 N 次了，太阳下没啥新鲜事。

参考： Qt 有低代码编辑器，依然不如写代码好维护； 虚幻游戏引擎有蓝图，依然工程师需要写代码。

代码本身就是终极之道了其实。

也许是印度开发小哥删一半忘了

Ruby

https://runrb.io/

Rust 就很离谱。那么多基础设施工程师么

TheoremProving

不过进入陌生领域了，Mathematica 也有定义证明。我就贴上了，这部分没做过。没有发言权了。

https://reference.wolfram.com/language/guide/TheoremProving.html

默认没开。已经有了。

https://ruby-china.org/topics/36896

https://nithinbekal.com/posts/ruby-tco/

看看 Mathematica ? 不过我好久没用了，只在大学做实验用过。MA 里面不关心类型，而且帮助数学家们推演公式。先进的数学编程语言，是自己从头实现的。python 数学库和 MA 相比是个弟弟

潮流是个大摆锤，今天锤锤这，明天锤锤那。

静态型没啥未来。研究研究 SICP，抽象才是编程技术绝妙的地方。

比如你在书写数学，不会关心数字类型。未来的语言也不应该关心类型。这些都是底层的细节，应该被屏蔽掉。 今天之所以需要关心，还是迫于实现细节或者性能妥协。

动态语言依然是未来的方向。静态型的语言做做基础工具，会被当成汇编永远活在幕后。

emmm，这看起来很正常啊。

ruby 是动态语言，声明方法只会注册，真正执行的时候才会运行。

函数内返回函数，也是一个支持函数范式的特性。可以建立起函数式编程。py、js 里也是可以。

有意义。要不然 Ruby 的领域面就一直很狭隘，处在服务器侧的 web 领域（这只是个一个小小的地盘）。

拒绝 windows 等于拒绝了 —— GUI 程序、办公自动化、一大批新手玩家、外挂领域、等于拒绝市场上最大占比的操作系统。

ruby 能够在 win 上工作，终于 rb 可以和 python 一样也出 Excel 教程了！！！哈哈哈，与之一战