我听过，我之前还大量的写过 Erlang…要是 Elixir 不是依赖于 EVM 这么多，我就跳进去了…从这个角度还不如用 Clojure，虽说 Clojure 也是坑

#1 楼 @defmacro JVM 就库多点，BEAM 不差的

PS：我特喜欢李路同学的问题，我觉得 Ruby 的最大威胁是 HHVM

PHP 什么情况。。。

#3 楼 @defmacro PHP 这么多美刀涉及品味问题

#5 楼 @bugmenot 品味是另一个问题，跟 simplicity 没关系

#2 楼 @bugmenot 好吧那可能是我功夫还不到家…我用 Erlang 都是噩梦没有甜蜜…

#6 楼 @defmacro Tasty First XP

当然应该用 Erlang。我看目前知名的语言里面，也就 Erlang 能兼容 PHP 语法。

学洁同学的产品如果用户量超过一百万，如果还这样架构的话，就可以服众了。

否则有阳春白雪之嫌。

#10 楼 @xiaoronglv 这套架构搞得定，没有问题。

曾经跟学姐讨论过这个话题，换个角度来说，如果是 Rails，产品用户数量超过一百万应该怎么搞？无非是优化单机的吞吐量，以及水平扩展。而学姐介绍的这套基于 Cuba 的架构，单机处理能力比 Rails 高一个数量级，水平扩展的方式却是一样的。

#10 楼 @xiaoronglv #11 楼 @lgn21st

这是我们现在一个线上服务结果：

[4] pry(main)> User.all.size
=> 1494797

前端是 4 到 10 台（取决于 load 需求，我们的负载在一定范围内可以预测）基于 JRuby 的 Cuba app（是的，这套架构的另一个好处是 JRuby 无压力，只有 cutest 因为是基于 fork 不能跑，但是还有 protest），后端是一台 Redis 机器（这边我们使用 codis 部署，但是目前实际处理 Redis 请求的就一台 Redis），性能无压力。

PS：说句不好听的，要不是 @lgn21st 帮忙说情我真的懒得回。。。我在最开始就说了我不是来吵性能的，我也说了 Rails 做到这个性能也没问题。这里重要的是 Cuba 这套架构对代码本身结构的影响

#10 楼 @xiaoronglv 和用户量无关 而是业务场景有多复杂

#11 楼 @lgn21st @xiaoronglv 可是 100 万用户量根本不算什么啊

#1 楼 @defmacro 对，感觉优势是 BEAM，有点不舒服的地方也是 BEAM 。不过我还是入坑了

#12 楼 @defmacro 顺便问下 slides 什么时候有？

#17 楼 @xiaoronglv 理解错了，我以为你和回 cuba 的人是同一个……

一个系统有 100 万用户，日活应该只有 1-5 万左右，95% 以上是冷数据。

雪洁同学的系统是用来监测 5 万个设备，差不多 100% 都是热数据。

场景不太一样。

不过 PHP 再怎么样也脱离不了其模板语言的初衷，搞上一套 Restful 框架之后不但写起来和 PHP 本身的语言设计不但不很契合，甚至还需要在这么一门天生的模板语言里再搞一套模板渲染实在是非常奇怪。纵使是 Laravel 这样自称是非常简洁的框架 Controller 看起来也是非常丑陋的。而且这种简洁是不符合雪洁同学描述的 Simplicity 的标准的，这说起来也是有点过了。

不过，去评判一门语言的好坏还是要放在场景下面来说。一套监测系统确实使用 Rails 并不是好选择，可能太过于繁重并且大多数功能并不会被用到。Cuba 或者另一些更轻的框架确实更适合这样的项目。

不过从 Presentation 里看，雪洁同学对 Simplicity 的另一个说法还包括了框架实现的简洁，希望能知道框架的全部细节，而不是只知道怎么用，不喜欢黑盒。这一点我倒是觉得和 Simplicity 并不是有着直接的关系。