你这么说倒是也有可能，我并没有直接测原贴的那个，但是 uuid 里确实有可能塞时间的

因为 UUID type 1 里包含时间戳信息了，于是乎就可以从中提取时间信息。

比如刚随便找了个网上的 demo

刚搜了下，其实也有人问的 https://stackoverflow.com/questions/43751943/how-to-convert-timeuuid-to-timestamp-in-ruby

另外 Ruby 的 SecureRandom.uuid 是 type 4，是不包含时间信息的

去年尝试过防弹咖啡，声称可以代餐了，不过后来没坚持下去

那些都没有 ESS 自带的完备，另外首先需不需要那么高的技术指标本身就要商榷，我想不到什么场景需要这么大的数字要求，一般数据库能支持的无符号 bigint 才大概 20 位，另外 msgpack 的 integer 最大也是 8 bytes，就算 mruby 支持，不再搞点 trick 还是不行。

沙箱一定要支持 Decimal 是为了算钱用的。

另外做映射并不是不能做，mruby 端的序列化、反序列化要在 C++ 的部分实现，ESS 的沙箱一部分测试不开源的（用了 Shopify 系统的源码做用例），改出来了也不好测试

大 Integer 变浮点数，这个没研究过，mruby 一些行为跟 MRI 不同，主要是面向性能和内存消耗考虑的，毕竟 mruby 可以跑在单片机上

mruby 没有 BigDecimal 类型，mruby Number 和 Float 的长度限制定义在 mruby 源码的常量里，Shopify 实现的 mruby-mpdecimal 的最大长度应该受 mpdecimal 这个 c 库的限制

离后端失业还远，起码先推波助澜一下呀

Shopify 已经基于 mpdecimal 给 mruby 做了一个了，ESS 还有我的 ScriptCore 都内置，但是因为无法直接映射，所以使用的时候得做手动处理一下

mruby 没有内建 BigDecimal 类型（MRI 这个是标准库的一部分），当然可以实现一套，但是缺点是无法跟 MRI 的 BigDecimal 做直接映射

MRI 不好裁剪，mruby 的标准库的粒度细多了，比如元编程在 mruby 里都是一个 gem

看好那个，当然能让这套成立感觉最重要的还是 GraphQL，目前也有类似的后台服务了，比如 https://graphcms.com/

这些都跟 JIT 没啥关系，都是不同的 Ruby 实现，JRuby 也不能说失败，至少 ELK 套装的 L 就是 JRuby 实现的。

IronRuby 坑了很可惜，本来这个是作者赌气的产物（根据一些资料的八卦，当时有人提出 .Net 上不可能实现高效的动态语言的虚拟机，作者不服不仅要试试而且要用大家公认不快的 Ruby 来，这个计划的最终产物并不是 IronRuby 而是 .Net 平台上非常重要的组件 动态语言运行时 DLR）

这次 mjit 能成还是因为路子太野，传统的 JIT 的设计需要投入很多精力，对实现者的知识要求也很高，MRI 没有 Google 这样大厂的资源支持（毕竟 JS 的 JIT 可以直接用在浏览器中，这样他的价值无比的高），所以很多人尝试过，结果都坑掉了...

我软牛逼！

你可以直接删了 assets 目录吧，这个应该无伤大雅的，要是原理的话可以看一眼 rails new 那部分的源码，没准这个可以算是 bug

支持！已入手！

Gitlab 给 Devise 加二步验证搞得还是很 tricky 的，不过 Gitlab 的那部分代码还是挺值得借鉴的，OTP 和 U2F 都实现了而且被检验这么久

可以升级，但一些情况下会报 warning，2.6 的兼容性改进的提交已经合并进 5-2-stable 分支了，估计老外过完节回来就会发新版

Kokubun anticipates that the --jit option will eventually be removed and the JIT will be enabled by default. Given that the goal of implementing a JIT in the first place was to speed up Ruby for the most common use cases, it's not likely to happen before the JIT is able to at least match existing Rails performance. Despite those challenges, Kokubun anticipates that the new JIT could become the default as soon as Ruby 2.7.

2.7 就要把 JIT 做成默认启动，这是很大勇气啊

splat operator 有一种翻译是打散 效果在控制台敲一下就懂了

[1] pry(main)> [*0..5]
=> [0, 1, 2, 3, 4, 5]

所以 Rails 也没有干掉 Assets Pipeline 啊... 现在也是支持 ES 6 的，还是够用的。

但是不用 Webpack 就彻底没法跟“现代”前端玩耍了

也可以啊。。。币市无情人有情。。。

0x66D33780a14C64b42Ea8628f476BF0D64A60517a

再多说一句。。。我还掌握着表达式引擎和工作流，Hooopo 有一套 GraphQL 的最佳实践，但我们没钱。。。大佬们可以投资我俩 。。。

其实这套架构是推翻了好几次设计的产物... @hooopo 灵感大爆发，应用层有我的虚拟模型把动态表单抽象成结构化的 ActiveModel 对象，这是数据库层的动态视图...

这套方法和动态表单结合在一起就不一样了，表单系统光收集数据没有意义，收集出来的数据需要做搜索、做统计、做分析才有意义（BI），而这些是 NoSQL 的弱项，生态没有关系型数据库丰富。而 PG 可以说兼顾了关系型数据库的结构化

首先他提出了一套存储结构的设计能够让用户定义的动态表单转换成标准的 PG 视图，这时候首先可以像一般的 SQL 表一样去查询、使用 PG 生态下的 BI 工具，甚至可以使用 Active Record 来用 Rails 的方式使用虚拟表（视图），能够被 AR 包装后，便可以利用 Ransack、Blazer 瞬间搭建出高级搜索和 BI 系统，这些都是 Rails 生态下的产物，于是又有了超高的可定制性...

并且 PG 提供的能力可以尽可能的保证如此灵活的设计下有空间进行优化

其实是这样的，去年 k0kubun 有请愿过 Rails team 考虑设置最低版本到 2.5，MJIT 基于 2.5 的字节码设计所以相容，这样未来 MJIT 调教完成，Rails 6 项目可以直接升级 Ruby 而不用担心回归问题。当时 Rails team 比较保守没有同意，最近刚刚做出了最低为 2.5 的改动，那么正和 JIT 开发者的意，其次使用 2.5 消除了很多 workaround 和 ActiveSupport 里实现的增强方法，并且比如 2.5 优化了 block 调用，重构一些瓶颈（比如 write_attribute）可以利用优化带来接近 10% 的性能改善

你要读过 webpacker 源码就知道其实那玩意只是做了个 webpack 跟 rails 的桥接，另外在 webpack 还没领悟约定优于配置的时候引入了一套默认实践，没了

webpack 本身就很麻烦，webpacker 起码不会比标准的 webpack 难用

都有了啊

早发布了，不过没作为默认栈，其实也没必要，因为如果你用 vue react 没必要用，stimulus 更多是用于遗留的场景或者是轻量场景

注册一周以后应该就可以了