TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ruby 3x3: Matz, Koichi, and Tenderlove on the Future of Ruby Performance

215 点作者 potomak超过 8 年前

9 条评论

technion超过 8 年前
Half of the Ruby that I write is not web applications - it&#x27;s scripts that configure servers, import and export data, optimise a manual process, etc. Ruby is perfectly performant in those scenarios.<p>It&#x27;s become a horrible meme I can run a script that reformats a 30 line CSV file the way I want it in 0.05s and someone will almost certainly lean over and say &quot;Ruby is too slow, you really need to upgrade to &lt;x&gt;&quot;. Or the intranet application I wrote in Sinatra last year for a total of four users, where all I got questions about how it could be usable without &quot;asynchronous&quot;.<p>That said, I don&#x27;t understand Ruby&#x27;s performance position. IBM released a preview of their JIT implementation over a year ago, with much fanfare. By many accounts, it held major practical improvements. Since then, I haven&#x27;t heard a thing about it, and the Ruby team seem to be spending years talking about implementing the same thing.
评论 #12932844 未加载
评论 #12933004 未加载
评论 #12931916 未加载
评论 #12932855 未加载
iagooar超过 8 年前
Too little, too late.<p>Disclaimer: I&#x27;m a Ruby developer.<p>Making Ruby 3 times faster is not going to save it. It&#x27;s just way, way behind the raw performance of other programming languages. Also, with the arrival of new, modern programming languages, there isn&#x27;t that many productivity reasons anymore to justify the poor performance and lack of sane concurrency.<p>I love Ruby, the programming language, but I kind of start seeing that others haven&#x27;t been idle and there are some growing ecosystems that can soon leave Ruby behind. It kind of feels like Perl back in the day: it was still a good programming language when it started losing ground.<p>We, Rubyists, have seen a lot of talented people leave both the Ruby and Rails core teams. You see them go to other, younger communities, making them bloom. In the meantime, the Ruby ecosystem seems stale and lacking fresh ideas.<p>The other problem is that there is not a single company that will throw as much money as it takes to improve the language, as happens with JavaScript, Python or PHP.<p>I am not trying to say that Ruby or Rails are a thing of the past and shouldn&#x27;t be used. They are still great tools and put in the right hands can give your company &#x2F; project huge productivity and more-than-acceptable performance. But there is a time for everything, and I think that the golden years of Ruby are gone.
评论 #12932293 未加载
评论 #12930716 未加载
评论 #12931973 未加载
评论 #12932872 未加载
banachtarski超过 8 年前
The decision to avoid LLVM (for JIT) due to its lack of age&#x2F;maturity strikes me as extremely odd. I can&#x27;t think of a piece of technology that has as much universality, buy-in, functionality, and compatibility.
评论 #12930570 未加载
评论 #12930333 未加载
评论 #12929306 未加载
评论 #12929277 未加载
dorianm超过 8 年前
For those who want ruby-like syntax and native performance, there is crystal: <a href="https:&#x2F;&#x2F;crystal-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crystal-lang.org&#x2F;</a>
评论 #12932434 未加载
rrradical超过 8 年前
I could be reading the tone of the interview wrong, but it seems like there&#x27;s a weird sort of anti-intellectualism bent to the Ruby community.<p>In the middle, there&#x27;s this exchange:<p><pre><code> Jonan: So you would just use pointers to point to those immutable objects? Koichi: Yes. Also, I want to note that immutable doesn&#x27;t mean frozen object. Frozen objects can contain mutable objects. So I mean those immutable objects which only contain children that point to immutable objects. Jonan: So if we had a nested hash, some large data structure, we would need to freeze every object in that in order to reference it this way. Is there a facility in Ruby right now to do that? I think I would have to iterate over that structure freezing objects manually today. Matz: Not yet. Jonan: So there might be? Matz: We need to provide something to freeze these objects. Aaron: A deep freeze. Matz: Yes, deep freeze. Jonan: Deep Freeze is the name of this feature maybe? I think that would be an excellent name for it. </code></pre> So yes, they all agree that Ruby&#x27;s current &#x27;frozen&#x27; feature doesn&#x27;t grant real immutability guarantees.<p>But then at the end...<p><pre><code> Jonan: OK. So then, a friend asked me when I described guilds, he writes a lot of Haskell, he asked me when we are we going to have &quot;real immutable objects&quot;, and I don&#x27;t quite know what he means. Is there some distinction between an immutable object in Ruby and an immutable object in a different language that’s important? Matz: For example in Haskell, everything is immutable, it’s that kind of language, everything is immutable from day one. Jonan: Yes. Matz: But in Ruby we have mutable objects, so under that kind of situation we need a whole new construct. Aaron: Frozen objects should really be immutable. It&#x27;s really immutable. Jonan: OK. Aaron: I don&#x27;t... Jonan: You don&#x27;t know what this person who air-quoted me &quot;real immutable&quot; was saying? Aaron: Yeah I don&#x27;t know why they would say &quot;real immutable&quot;. Jonan: Should I unfriend him on Facebook? I think I&#x27;m going to after this. Matz: At least tell him if you want &quot;real immutable&quot; go ahead and use Haskell. Jonan: I think that&#x27;s an excellent option, yeah. Aaron: You just to need to say to them quit &quot;Haskelling&quot; me. Jonan: I should, I’ll just tell them to quit &quot;Haskelling&quot; me about immutable objects. </code></pre> I get that they are joking a bit, but do they really not understand that the Haskeller is referring to the lack of deeply immutable objects? The hostility seems a bit weird to me, given that languages like Haskell push forward our understanding of the usefulness of things like immutability, which then get absorbed into other languages (like Ruby, clearly).
评论 #12926074 未加载
评论 #12926203 未加载
评论 #12926188 未加载
评论 #12927917 未加载
评论 #12929737 未加载
评论 #12928206 未加载
评论 #12931187 未加载
kyledrake超过 8 年前
TLDR: There isn&#x27;t an actual plan to make Ruby 3x faster, it&#x27;s just a bullshit number Matz made up to be cute. Instead there will be some marginal improvements here and there, as per usual.<p>Some vague references to the idea of building a JIT are discussed. Rubinius already does this, but they apparently long ago decided that Rubinius doesn&#x27;t exist, so I guess that&#x27;s off the table.
评论 #12931432 未加载
ksec超过 8 年前
We keep seeing discussion like this and yet we haven&#x27;t seen much improvement. They used to joke about only those company making money are Rails. So why haven&#x27;t Github, Shopify, Twitch, Groupon or others pour any resources in ?<p>Ruby is slow, at least from a Web Development perspective, Rails is VERY slow. So both together combined makes things a little bit bad.<p>Look at the boring stack from StackExchnage<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12790650" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12790650</a><p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;Nick_Craver&#x2F;status&#x2F;790527231600787456" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;Nick_Craver&#x2F;status&#x2F;790527231600787456</a><p>Any Rails Shop would be happy if they could hit 3x those numbers even with caching.
评论 #12929617 未加载
评论 #12930157 未加载
DamnYuppie超过 8 年前
I am not sure it doesn&#x27;t make sense for them to just move over to JRuby and have them all focus their efforts their.
评论 #12925974 未加载
评论 #12925966 未加载
评论 #12926480 未加载
andy_ppp超过 8 年前
I see no reason to not just move to Elixir at this point for 10-20x performance increase and the tools to build distributed systems at your fingertips.
评论 #12925944 未加载
评论 #12926448 未加载
评论 #12926549 未加载
评论 #12928385 未加载
评论 #12929890 未加载
评论 #12936896 未加载