精华帖 (0) :: 良好帖 (18) :: 新手帖 (2) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-09-15
任何编程语言都可以做这种粘合,但是python/ruby更加有效率,面向对象的代码,更多的类库,当然能更好的完成粘合这个任务。
你说的“高负载长期运行”下的内存泄漏,我感觉是你走在ruby的前面了,或者说ror走在ruby的前面了,ruby还没有完善到可以应付你说的高负载长期运行的局面。这个现在最多小修小补,只有等ruby成熟了后,才能彻底解决。估计ruby要成熟估计比较漫长。这点python比ruby强。 |
|
返回顶楼 | |
发表时间:2008-09-16
java的初衷还是做嵌入式设备的程序呢,后来拿来做互联网,最后不也发展的很好嘛
|
|
返回顶楼 | |
发表时间:2008-09-16
jiorry 写道 ruby,python,java 各司其职,冲突不大。
我选择ruby 只是因为 我的项目里 ROR 是最合适的。 ruby 目前就是依靠rails框架才火热起来的,这是事实。 python是简练,可是其附加内容繁杂。 ubuntu上些东西 python定要优于ruby。 java就更不用说了,干啥都行,就是用的人多些。 他们都有自己互相的依赖和生存之道,各自也都能找到自己的位置。 还有,要冷眼看炒作。 google推了个浏览器,就大喊javascript是web第一。google当然不会在adobe的flex上投入了,更不会用silverlight。 flex,javascript,silver 他们也都有自己的市场。 adobe树大根深的,要搬动不容易。 silver 刚推出的时候我也赞叹功能的强大,热血澎湃的要用silver。 用上了才发现被忽悠了,开发起来很不顺手。玩一玩可以,要把项目扮过去,成本陡增。 这让我想起来BBC上说 中国要民主,自由,开放!!! “民主,自由,开放”很好听,但是如果真的那么使劲的做了,只会给中国带来更多的混乱。 非常棒的见解! 不人云亦云,客观看待事情的本质。欣赏这样的叙述方式。 |
|
返回顶楼 | |
发表时间:2008-09-16
对Ruby而言,由于C扩展造成内存泄露是很普遍的现象。如果C扩展很简单当然矛盾不突出,一旦涉及到大型的C扩展库,维护者很多时间都是花在和内存泄露做斗争。使用SWIG可以很大程度自动化内存管理,但是SWIG分装出来的接口比较死板,很多人还是愿意手工写C扩展,并持续与内存泄露斗争....
作为“粘合”语言,如果Ruby能够改进VM和C接口,使得外部与VM打交道更容易些,C扩展库的质量提高了,Ruby成为主流语言的机会还是很高的。 |
|
返回顶楼 | |
发表时间:2008-09-16
庄表伟 写道 如果你真的喜欢ruby,写rails的应用,不是一样在用ruby吗? 不同意该意见者,请重新阅读《ruby for rails》 |
|
返回顶楼 | |
发表时间:2008-09-19
纯粹用java 写console的工作好像也没有
|
|
返回顶楼 | |
发表时间:2008-09-19
这么多年没火自然有它没火的原因。
|
|
返回顶楼 | |
发表时间:2008-09-19
sword721 写道 这么多年没火自然有它没火的原因。
我不抢你钱包,自然有我不抢的道理,所以,就证明将来不会抢? 我抢了你钱包,也自然有抢你的道理. 所以,你就能找到接受被抢的理由, 平衡了? 这种逻辑,我认定为"愚昧哲学" 你不如直接把银行卡号密码公布出来吧. 我这个要求,也自然有我的道理. |
|
返回顶楼 | |
发表时间:2008-09-19
狗肉好吃,还很补,可是狗肉上不了正席。
|
|
返回顶楼 | |
发表时间:2008-09-19
kaven 写道 任何编程语言都可以做这种粘合,但是python/ruby更加有效率,面向对象的代码,更多的类库,当然能更好的完成粘合这个任务。
你说的“高负载长期运行”下的内存泄漏,我感觉是你走在ruby的前面了,或者说ror走在ruby的前面了,ruby还没有完善到可以应付你说的高负载长期运行的局面。这个现在最多小修小补,只有等ruby成熟了后,才能彻底解决。估计ruby要成熟估计比较漫长。这点python比ruby强。 我觉得你的这个说法有意回避了robbin所说的问题 A: 你觉得这件衣服怎么样? B: 袖口这里沾了一点灰 目前我在实际应用中也遇到这类问题,十分头疼,不单单是Rails的Plugins的问题,还有一些gem,都出现内存泄漏的问题 我曾经尝试使用Ruby对游戏服务器做包装,当实现10%功能时已出现了明显的内存泄漏,排查相当困难 |
|
返回顶楼 | |