5 ms·
It seems sometimes like the only thing that has changed significantly in Ruby since I started with 1.8.4, ten years ago, is that it now has a real bytecode and
by duaneb 11y ago
It seems sometimes like the only thing that has changed significantly in Ruby since I started with 1.8.4, ten years ago, is that it now has a real bytecode and better garbage collection.
So sad to see a language stagnate like this.
- vezzy-fnord 11y agoSpeaking as someone who isn't much of a Ruby user, what do you expect to see? I mean, when you have Smalltalk-style messaging and metaprogramming, that's a relatively timeless and composable base.
- techscruggs 11y agoWhat exactly would you like to see?
- matthewmacleod 11y agoWell, that's not true. Ruby's changed massively since the 1.8 series. What are you expecting to see that you're not?
- bshimmin 11y agoI think "massively" is relative here. If you compare Ruby 1.8 and Ruby 2.2, they are very clearly the same language, but the latter with many pleasant and useful additions - the sort of iterative improvements, in fact, that Apple are so good at with their hardware (for the most part). If you compare JavaScript from the 1.6 era to today's ES6... they hardly look like the same language.
- duaneb 11y ago> Ruby's changed massively since the 1.8 series It was mostly syntactical, and it didn't do much to improve readability. I guess I was hoping to see functional improvements, where they address the pain points of ruby: performance, tooling, dependency hell, unicode support, lack of things like co-routines or generators, the ability to restrict access to internals.
- indspenceable 11y agoRe: Generators - I don't know why it's so hidden, but the Enumerator class allows you to make generators ``` enum = Enumerator.new{|y| a = 0; loop{y << a; a += 1}} enum.next => 0 enum.next => 1 etc ``` I believe this has existed since 1.8x
- rylee 11y agoIt's not "hidden" per se, it's the first SO result for googling "ruby generators".
- cremno 11y agoWhat makes you think they're hidden? Enumerator moved from stdlib to core in 1.9 and also calling #to_enum isn't needed anymore: enum = 0.upto(Float::INFINITY) enum.next # => 0 enum.next # => 1
- dragonwriter 11y ago> guess I was hoping to see functional improvements, where they address the pain points of ruby: performance, tooling, dependency hell, unicode support, lack of things like co-routines or generators Performance and Unicode other people have mentioned alreaedy, and have been areas of improvement. Explicit library support for semi-coroutines and coroutines was added in 1.9 via Fiber and Fiber::Core, and Ruby already had generator support in 1.8. So many of the things you say you were hoping to see have been addressed since 1.8, and at least one was already addressed in 1.8.
- sanderjd 11y ago> tooling, dependency hell I used Rails when it was still `config.gem` with no dependency resolution, and it was an absolute nightmare, so I think I know what you're talking about here. But then bundler came along and, well, completely solved the problem.
- djur 11y agoThe first "pain point" you mention is "performance" but earlier you were saying that the only major changes were a better GC and JIT? I don't see how that follows. What's odd is that "performance, tooling, dependency hell, unicode support, ... co-routines ... generators" reads like a list of things that have been worked on heavily since 1.8. Performance has been a major focus of every release since 1.9.1; integrating Rubygems considerably helped with tooling and dependency issues; encoding-aware strings were a major feature of 1.9; coroutines and generators can be implemented more effectively with 1.9's Fibers.
- rylee 11y agoWhat, precisely, are you looking for? The stdlib continues to grow and improve, MRI continues to get faster, we just got full native unicode support a while back, GMP usage in Bignum, refinements, symbol GC, compiling with jemalloc... and that's just stuff in 2.1 and 2.2.
- deleted 11y ago[deleted]