或缺少的？

timers

利用 current-ruby 的 Concurrent::ScheduledTask，activejob 的 async_adapter 用的就是这个。

jruby 的话，有 TimerTask

不过我没做过测试，不知道这些解决方案的精准度、容错之类的怎么样。

不考虑性能，ruby 写数学方面的东西，也不见得有优势。机器学习的语言，需要的是数学语言，而不是自然语言。R 也慢，但用的人还是很多，一部分原因是它的语法适合。

ruby 不单单是没有优化的问题，面向对象本身就快不起来。

没有没有，我就是随便搞搞。

我还有一些问题没搞清楚

哈，已经有两个主题了 下次活动预约个 nio 优化网络请求的主题。

看了一遍Strikingly 团队 2017 技术展望，粉丝面圣式跪求微服务方面的分享。

微服务应该有好多东西要做。。。通信、拆分、分布迁移啥的。。。RoR 似乎不是很赞同微服务，ActionCable 直接 load 了一个 app，这种感觉也挺好的。

Ruby 生态统一，哦，要除了并发这一块。。。n 多的 gem 啊。

连多个数据库挺容易的，原理大家已经给出了，可用的工具是 multiverse

但问题是，真的需要换数据库吗？uber 数据库就换来换去的 https://eng.uber.com/mysql-migration/

还要考虑这个技术方案，是否可行。假设是分模块迁移，如果模块和模块之间的表有 join 的话，这个方案不行。项目模块划分不清才是最大的问题，模块划分请了，其他的都是小问题。

最后也是最重要的，原有问题到底出在哪？没有具体问题，技术连存在的意义都没有。技术过时，显然不是一个问题。.net 还过时能，但性能吊打 n 多框架。

autoreload 引起的吧？

那美好的仗我已经打完了，应行的路我已经行尽了，当守的道我守住了。

从此以后，有公义的冠冕为你留存。

都依赖线程、并发模型。问题是其线程，线程会死，那就需要 monitor，死了、重启，需要重启 timer。这么多 timer 要怎么调试、管理。一个 timer 死了，其他 timer 要不要一起死。。。

想用 Erlang 了。。。

A language that doesn’t affect the way you think about programming is not worth knowing. --- Alan Perlis

学 java。这几门区别不大，面向对象语言，部分函数式支持。学一种，其他的语言撸起来也不会难。 而 java 是唯一的静态语言，并且应用更广。web，科学计算，并发都没问题。 如果再学一门，学 Erlang，原因是函数式编程 + 并发。Clojure 也有函数式，也有并发，但却没有在两方面给出完善的解决方案。

需要解决的问题，决定需要使用的语言。而不是所掌握的语言，决定了能解决的问题。学一门语言，之后需要用什么语言，学什么语言。这里不考虑个人喜好问题，如果考虑喜好的话，ruby 是最舒服的。

多数的问题是和语言无关的，比如网络，数据库，哪门语言不会遇到这些问题？反而是这些问题更不好掌握，更需要学习。

可能跟 C 有关，https://stackoverflow.com/a/20000236/2477886

不过看样子，这个问题应该是解决了。。。

用 julia

哈哈，原来是想收邮件，那可以建一个 Email 机器人，发给这个机器人的邮件就能发到讨论组里啦！

（借楼主的宝地，体验一下做销售的感觉，昨天体验了产品经理，楼主不要打我 ）

楼主，Rollbar 有 webhook 吗？有的话需要 BearyChat 机器人吗？这样异常消息就能推送到您的小组里啦！

计算机技术一直在发展，语言怎么可能成熟。Ruby 也一直有更新。

Clojure 就很成熟，就不怎么更新，你想要啥，一个宏就可以了（我是来黑 Clojure 的）。

以为你们要做更深入的讨论呢，没下文了。。。

就算是黑 Ruby，只要有理有据，也是件好事啊。

倒是有点期待楼主能比较下 Ruby 和 Erlang 的并发，比如并发模型、语法、性能、处理异常、面向对象怎么做并发的（function programing 是靠传参）。

感觉也可以优化下搜索

看个人选择吧？觉得值就值。 用了 ruby 也不见得一点不优化。

异常处理感觉像 Erlang ……

么么哒就不要了，有机会的时候倒是会试试。

gits 应该要吧， 或者这个 gem https://github.com/syedmusamah/grape_on_rails_routes ？（这个 gem 我没用过）

哈哈，想知道有没有人真的在生产环境这么搞过！

小专栏 看起来有很多人在用

https://gist.github.com/oivoodoo/5089237

不是很好用，到至少能用。

RoR 程序员要保证好学习时间，不能写完业务，就不学习了。

团队开发是多个人，每个人可能擅长解决不同问题，把问题就给擅长的人。

重框架 vs 不用框架

RoR 功能全，文档丰富，Google 可以解决大多数问题。

不用框架，从代码组织，到功能，都是黑盒，重复工作、复杂度就不说了，出了问题，代码从都看到尾，debug 到吐血，半天修个屁大点 bug，死的新都有。

RoR 复杂是复杂了点，但一般出问题了，大体能猜到。没框架，出了问题是真不少猜。