瞎扯淡 我把我的一个 C 项目用 Ruby 重写了,感慨万千

laocainiao · 2019年04月21日 · 最后由 jjym 回复于 2019年05月06日 · 3153 次阅读

之前用 C 写的一个服务端的程序,用到的技术栈是 GLib、GStreamer、libsoup、sqlite、websocket,实现的功能有网络通信,语音播放等功能,服务器端数据库及文件管理,JSON API 等,断断续续花了一年多的时间,代码量 12000 多行。

前一段时间,我将 C 程序大部分功能都砍掉,只保留关键的部分,只保留语音播放和一些关键的网络通信等最基本的功能;

然后用 Ruby 重写了其中的 90% 的功能,C 程序间通过 TCP 实现进程间的通信,,用到的技术栈是 Eventmachine / Sinatra / Sequel 等,花了一个月。代码量 2000 多行。

所有这一切基本完成后,感觉良好,感觉之前都白忙活了,5 倍多的代码量,而且感觉实现的功能还不完善,最害怕有需求变动,现在轻松应对(但是表面上不能表现出来)

之前都是写完代码,然后 make 一下,嗯,没有报错,还不错,接着手工测测就 OK 了。

现在是写完代码,rake test 一下,嗯,0 failures, 0 errors,真香。

共收到 18 条回复
liuxufei 回复

对的,我后面用 Ruby 重写的时候,就是像素描一样,很快就搞定了. 我决定以后有业务逻辑方面的代码再也不会考虑使用 C/C++ 了,实在有 Ruby 搞不定的,我还会在 GEM 里 用 扩展来搞定。

我以前是 C 程序员,后来发现智商不够用,于是跑来写 WEB 了。😂

当初定技术栈的时候,为啥选 C?性能原因?

现在 Ruby 性能没啥问题了,比以前高多了。

这种服务端代码既有业务需求又有性能要求的场景,用 go 是不是更合适?

alucardpj 回复

根据大数据统计

80% 的 c/c++ 使用者觉得 go 好一些

30% 的 ruby 使用者觉得 go 好一些

因为 ruby 更接近人类语言, 写起来舒服。

alucardpj 回复

如果用 ruby 性能够了,为啥还要用 go

从技术角度做我们这种网络语音应用,用 C/C++ 没有什么大问题。团队其它成员(其实就另外一个小伙伴)是写 C/C++ 的,其它语言没有实战经验,他写好库函数成动态链接库 so,我直接用 c/c++ 调用即可,还能共享代码和人力资源。 搞到后面,老板越来越压缩时间,在好几个项目间辗转,我感到力不从心,老板说招人也迟迟不见动静,招来也不不能马上上手,遂萌生了调用 Ruby 大法的想法,一个人顶三。

上面说性能的一些同学,我想说一下,在小公司,就不要操心这个问题了,还是多想想开发效率问题,多为自己着想。

redvoilin 回复

用 Go、Rust 都是爱好,当然 Go 解决了 C++ 的存在的问题,但是 Go 对于 micro controllers 不利呀,把 unsafe 列为禁忌的语言,你看哪个 bootloader 不是 ld 占据固定某片区的。

如果谈爱好当然 including Ruby,其实很多项目如果有了 rb 根本就不需要 C 写得太多 code 了,而且更美观、简短和灵活,灵活我觉得是最重要的,这是能不能加速的重要条件,把 performance 交给 C,把 logic 交给 ruby。

写代码,ruby 和 C 更配哦

有了 mruby 这个小情人以后,Ruby 和 C 搭配很自然,真是用好极了,比 MRI Ruby 那样写 C 扩展或者用 FFI 不是一样的套路。在 mruby 中是以 C 为主,mruby 为配角, 很用 C 写的很繁琐的部分可以调用嵌入的 mruby 来完成。 有空写一篇。

不错,EventMachine 有点老了,https://github.com/socketry/async 推荐一下

jjym 回复

我有空看看。粗看了一下 async 是采用纯 Ruby 写的,而 Eventmachine 是采用 C++ 扩展的,是否有什么大不同吗?

laocainiao 回复

主要 EM 年久失修,async 还是活跃开发的

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册