Ruby 2.1.0 preview1 released(ruby-forum.com)
ruby-forum.com
Ruby 2.1.0 preview1 released
https://www.ruby-forum.com/topic/4417257
61 comments
There is an ISO standard for 1.8.7 and RubySpec for all versions.
Not to be rude, but 1.8.7 is dead. RubySpec is first, not linked from [1] and second, just about completely inaccessible to someone not already familiar with Ruby. It's an executable specification, not a language reference manual. It's aims, structure, and information architecture are inappropriate for the purposes of a human with questions about the language, ala "what's the syntax and semantics for X in Ruby 2.0?" (for X = case, method definition, etc., etc.)
We're already starting to see third-party sources bitrotting. E.g. eigenclass' 1.9 pages are now gone. Without an authoritative source for "What's new in 1.9.x?" and later, this bitrot will get worse and make it needlessly painful for folks who still need to move 1.8 code (or brains...) to 1.9/2.0.
Part of my point is that the sources directly linked from ruby-lang.org are a mish-mash as well. There's virtually nothing authoritative, maintained by ruby-lang.org itself. The links at [1] are a mix of ok, good, and rather out of date. ruby-doc.org, not linked from [1] (wat.), is about as good as we've got for a standard reference. Sadly, it's missing the language reference piece and it's auto-generated information architecture sucks hard.
An example of that last point: hit [2]. What's above the fold? A useless list of files. Scroll down and you'll eventually get to the filterable lists of core classes and methods. Click on "Array"[3] and we actually get a nice summary doc with examples that walks us through this class.
For comparison, we'll go to the standard library[4]. Click on "net/http" in the left sidebar[5]. Instead of getting a nice summary page, instead we get an opaque class and method list. The reader is left to divine which, if any, link might provide some clues about the use and organization of this library. (Hint: it's "Net::HTTP", third from the top on the left.) If you already know which is the "main" class for this library, then you can usually guess right.
It's ridiculous for reference material to assume the user is already familiar with it in order to successfully navigate it. Again, other languages' library references do a much better job w.r.t. navigability.
Coda: I don't mean to harsh on ruby-doc.org too much; it's just a central example in the Ruby world. Nevertheless I feel the need to highlight how the Ruby community's disconnected, scattershot approach to documentation presents both a user education and a marketing problem.
[1] https://www.ruby-lang.org/en/documentation/
[2] http://ruby-doc.org/core-2.0.0/
[3] http://ruby-doc.org/core-2.0.0/Array.html
[4] http://ruby-doc.org/stdlib-2.0.0/
[5] http://ruby-doc.org/stdlib-2.0.0/libdoc/net/http/rdoc/index....
We're already starting to see third-party sources bitrotting. E.g. eigenclass' 1.9 pages are now gone. Without an authoritative source for "What's new in 1.9.x?" and later, this bitrot will get worse and make it needlessly painful for folks who still need to move 1.8 code (or brains...) to 1.9/2.0.
Part of my point is that the sources directly linked from ruby-lang.org are a mish-mash as well. There's virtually nothing authoritative, maintained by ruby-lang.org itself. The links at [1] are a mix of ok, good, and rather out of date. ruby-doc.org, not linked from [1] (wat.), is about as good as we've got for a standard reference. Sadly, it's missing the language reference piece and it's auto-generated information architecture sucks hard.
An example of that last point: hit [2]. What's above the fold? A useless list of files. Scroll down and you'll eventually get to the filterable lists of core classes and methods. Click on "Array"[3] and we actually get a nice summary doc with examples that walks us through this class.
For comparison, we'll go to the standard library[4]. Click on "net/http" in the left sidebar[5]. Instead of getting a nice summary page, instead we get an opaque class and method list. The reader is left to divine which, if any, link might provide some clues about the use and organization of this library. (Hint: it's "Net::HTTP", third from the top on the left.) If you already know which is the "main" class for this library, then you can usually guess right.
It's ridiculous for reference material to assume the user is already familiar with it in order to successfully navigate it. Again, other languages' library references do a much better job w.r.t. navigability.
Coda: I don't mean to harsh on ruby-doc.org too much; it's just a central example in the Ruby world. Nevertheless I feel the need to highlight how the Ruby community's disconnected, scattershot approach to documentation presents both a user education and a marketing problem.
[1] https://www.ruby-lang.org/en/documentation/
[2] http://ruby-doc.org/core-2.0.0/
[3] http://ruby-doc.org/core-2.0.0/Array.html
[4] http://ruby-doc.org/stdlib-2.0.0/
[5] http://ruby-doc.org/stdlib-2.0.0/libdoc/net/http/rdoc/index....
Though 1.8.7 was released more than 5 years ago (and the language has evolved a lot since then) and the RubySpec are usually not up to date, at least not documenting all the features as they come in (as Brian Ford and others have pointed out several times).
Not to be an ungrateful d*ck, I think the progress made is fantastic and supported by a bunch of extremely dedicated, talented and courageous people, but there is something of a void in terms of Ruby-as-formally-specified-language, hard to deny. But as usual, I guess it's hard to find the manpower, the time and the money to support such efforts.
Not to be an ungrateful d*ck, I think the progress made is fantastic and supported by a bunch of extremely dedicated, talented and courageous people, but there is something of a void in terms of Ruby-as-formally-specified-language, hard to deny. But as usual, I guess it's hard to find the manpower, the time and the money to support such efforts.
Yup. I totally agree with you, a formal spec would be great. But it's not in the cards, so we do the best with what we've got.
So what happened to refinements? They were given a warning in 2.0 because the other implementations warned that implementing refinements would lead to worse performance. Has that been fixed?
@headius was so kind to answer my question on Twitter: https://twitter.com/MSch/status/382065119515398144
I'm still waiting (4 years now) for method#to_source. sigh
http://bugs.ruby-lang.org/issues/2080
http://bugs.ruby-lang.org/issues/2080
I feel your pain, I (part)implemented a lambda parser that will spit out C-style expressions when given basic mathematical ruby expressions if that helps you: https://github.com/cronin101/HaDope/blob/master/lib/parsing/...
E.g. calling with ->(i){ i * (2 + i / 4) } returns 'x * (2 + (x / 4))'
E.g. calling with ->(i){ i * (2 + i / 4) } returns 'x * (2 + (x / 4))'
For what it's worth, if you're just looking to get at the innards of a method, Pry does this job admirably.
https://gist.github.com/cheald/6674718
https://github.com/pry/pry/wiki/Source-browsing
Or to get the source as a string:
https://gist.github.com/cheald/6674718
https://github.com/pry/pry/wiki/Source-browsing
Or to get the source as a string:
> require 'pry'
> Nokogiri.method(:HTML).source
=> " def HTML thing, url = nil, encoding = nil, options = XML::ParseOptions::DEFAULT_HTML, &block\n Nokogiri::HTML::Document.parse(thing, url, encoding, options, &block)\n end\n"Pry is awesome. You can even navigate your source shell-style and do all sorts of fancy things with it. Great little gem.
It's not perfect, but I've used sourcify [1] to get Proc#to_source. I would much rather see this built into ruby itself, since there are a bunch of tools I would build with it available, but this works fairly well in practice.
[1] https://github.com/ngty/sourcify
[1] https://github.com/ngty/sourcify
Ha! I have you beat! I've been waiting 7 years for to be able override autoload's require.
https://bugs.ruby-lang.org/issues/7716
In fact, after 10 years of dedication, b/c of this and a few other issues (and attitudes) I don't use Ruby any more.
https://bugs.ruby-lang.org/issues/7716
In fact, after 10 years of dedication, b/c of this and a few other issues (and attitudes) I don't use Ruby any more.
Autoload is fundamentally broken because it makes your app state nondeterministic by making state loading and logic interdependent.
I work on a large Ruby software project and we've had to move away from any autoload except for very specific cases for this reason- troubleshooting autoload bugs are the WORST.
Maybe this is the reason it hasn't been looked at.
I work on a large Ruby software project and we've had to move away from any autoload except for very specific cases for this reason- troubleshooting autoload bugs are the WORST.
Maybe this is the reason it hasn't been looked at.
I wish. There was a window of time when Matz said autoload would be deprecated. But he took that back after Yahuda (I think) addressed some threading issue. I agree with your assessment, but too many big names project use it --RubyGems, Psych, Rails, etc.
I wrote my one load system but have never been able to use it 100% with other projects b/c I could not override autoload require. Though I've begged for years Matz just keeps blowing it off.
I wrote my one load system but have never been able to use it 100% with other projects b/c I could not override autoload require. Though I've begged for years Matz just keeps blowing it off.
What language(s) did you move on to?
I am not 100% settled yet. I am evaluating Elixir and Go right now. There are things I like and don't like about both. I gave Haskell a shot but rejected it altogether --I have better things to do then stare at my monadic navel. But all those aside, I've concluded that the ultimate fallback is simply Javascript/Coffeescript --the syntax isn't as nice as Ruby, but you can't go wrong for interoperability. Oh, also [Crystal](https://github.com/manastech/crystal) looks very promising, but it's too immature as of yet.
Beyond that I've decide it's also time to step up work on my own language. Something I've always wanted to do for a while.
Beyond that I've decide it's also time to step up work on my own language. Something I've always wanted to do for a while.
Haskell does indeed look not at all like a language that one "gets" right off the bat, although statically typed monadic operations are, for me, a must have now -- transitioned from Groovy, a poor man's Ruby (as far as MOP is concerned), to Scala a couple of years ago.
Crystal looks pretty interesting, statically typed Ruby with extreme type inference. Of course that begs the question, why not JRuby?
As for JS/CS, I love me some coffeescript, just a drag to debug the fat fingered typos, indentation mishaps, etc. wtf is going on moments.
A TypeScript/Coffeescript hybrid would be truly awesome.
Crystal looks pretty interesting, statically typed Ruby with extreme type inference. Of course that begs the question, why not JRuby?
As for JS/CS, I love me some coffeescript, just a drag to debug the fat fingered typos, indentation mishaps, etc. wtf is going on moments.
A TypeScript/Coffeescript hybrid would be truly awesome.
You know what put me over the edge with Haskell? Monads were difficult enough, but one of the first things I wanted to do was randomly shuffle a list. That led me to this: http://www.haskell.org/haskellwiki/Random_shuffle. I knew right then that this was not the kind of language I was interested in.
As for JRuby, fair point, but I'd rather steer clear of Java as much as possible. I have to use Java for Android development and it makes me cry big hippo tears every day.
As for JRuby, fair point, but I'd rather steer clear of Java as much as possible. I have to use Java for Android development and it makes me cry big hippo tears every day.
Scala collections library covers pretty much everything you can think of, usually in a concise manner a la Ruby, Python, etc.
scala> Random.shuffle(List(1,2,3)) res7: List[Int] = List(2, 3, 1)
Scala-Android google group may be of interest: https://groups.google.com/forum/#!forum/scala-on-android
Obviously I've been converted to the static side, only client-side remains dynamic for me at present, and that's only because there's not yet a statically typed Coffeescript-like language available.
scala> Random.shuffle(List(1,2,3)) res7: List[Int] = List(2, 3, 1)
Scala-Android google group may be of interest: https://groups.google.com/forum/#!forum/scala-on-android
Obviously I've been converted to the static side, only client-side remains dynamic for me at present, and that's only because there's not yet a statically typed Coffeescript-like language available.
[deleted]
> Groovy, a poor man's Ruby (as far as MOP is concerned)
...and as far as its static typed mode introduced in version 2, written by only one person but bundled with the dynamic compiler as if it was part of the same software. is concerned. Grales doesnt use any of it and Gradle still ships with Groovy 1.x.
...and as far as a lot of other stuff about Groovy such as its lexer/parser imlemented in Antlr 2.7, two major releases behind Antlr 4, the latest version. is concerned.
...and as far as its static typed mode introduced in version 2, written by only one person but bundled with the dynamic compiler as if it was part of the same software. is concerned. Grales doesnt use any of it and Gradle still ships with Groovy 1.x.
...and as far as a lot of other stuff about Groovy such as its lexer/parser imlemented in Antlr 2.7, two major releases behind Antlr 4, the latest version. is concerned.
I spent the better part of 6 months in pure Groovy, getting my feet wet on the JVM, was quite enjoyable to hack around in, the syntax is nicely terse.
The lack of static typing became an issue when I spent 6 months in the underworld (aka Grails in the v1.3 days) attempting to decipher voluminous stack traces whose origins lay somewhere deep in 10 layers of Grails MOP, far from one's reach.
Anyway, I was frustrated with Grails, deeply so; one day on the Grails user group someone mentioned Scala. Had no idea what that was, checked it out, bought the stairway book, started hacking around in the REPL and was quickly sold.
The lack of static typing became an issue when I spent 6 months in the underworld (aka Grails in the v1.3 days) attempting to decipher voluminous stack traces whose origins lay somewhere deep in 10 layers of Grails MOP, far from one's reach.
Anyway, I was frustrated with Grails, deeply so; one day on the Grails user group someone mentioned Scala. Had no idea what that was, checked it out, bought the stairway book, started hacking around in the REPL and was quickly sold.
What have you used Ruby for in these 10 years?
Among other things http://github.com/rubyworks.
It changed from 2.0.0 to next minor. And this is 2.1 already.
What is the course of this delay?
What is the course of this delay?
> What is the course of this delay?
Is there a patch?
Is there a patch?
How about method(:methodname) returning the actual method object instead of a newly instantiated wrapper class containing the method metadata?
irb(main):001:0> RUBY_VERSION
=> "2.0.0"
irb(main):002:0> class Foo; def hello; puts "hello"; end; end
=> nil
irb(main):003:0> X = Foo.new.method(:hello)
=> #<Method: Foo#hello>
irb(main):004:0> X.class
=> Method
irb(main):005:0> class Bar; define_method(:hello, &X); end
=> #<Proc:0x007f93d087a2d8 (lambda)>
irb(main):006:0> Bar.new.hello
hello
=> nilTime for some Benchmarks. Ruby 2.1, JRuby 1.7.5 and the Duke Nukeum Rubinius 2.0.
Non-Blocking IO with out raising an exception is a notable new feature. The Improvements to Garbage Collection is also pretty huge.
The 128bit number support is cool, I mean if you want to work with Quadruple-precision floating-point numbers... I know I do.
The 128bit number support is cool, I mean if you want to work with Quadruple-precision floating-point numbers... I know I do.
Where do you find out about the non-blocking io?
I suppose he refers to this...
* IO
* IO
* extended methods:
* IO#seek supports SEEK_DATA and SEEK_HOLE as whence.
* IO#seek accepts symbols (:CUR, :END, :SET, :DATA, :HOLE) for 2nd argument.
* IO#read_nonblock accepts optional `exception: false` to return symbols
* IO#write_nonblock accepts optional `exception: false` to return symbols
Wasn't there an overwhelming negative feedback for refinements? What was the rationale for still going ahead with them?
Matz has said we're getting them, so we're getting them.
Sure, he's the benevolent dictator (and the creator of language, itself), but he would've explained himself somewhere. About the benefits of refinements and how to deal with the downsides. Any links?
If you've got the patience, https://bugs.ruby-lang.org/issues/4085#note-95 is the ruby-core discussion. It really does boil down to "Matz says so."
> Wasn't there an overwhelming negative feedback for refinements?
IIRC, there were concerns about the performance impact and maybe some other issues of the semantics of refinements -- particularly from maintainers of other Ruby implementations -- which is why there were originally marked "experimental". I believe that those have been addressed with input from the other implementors in 2.1.0.
IIRC, there were concerns about the performance impact and maybe some other issues of the semantics of refinements -- particularly from maintainers of other Ruby implementations -- which is why there were originally marked "experimental". I believe that those have been addressed with input from the other implementors in 2.1.0.
Even then, a lot of us think the feature is absolutely terrible, performance was just one of the worst parts.
List of new features:
http://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_fil...
Is there more detailed changes description?
Closed tickets in bugtracker:
http://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_fil...
http://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_fil...
A list of language and library changes in this release. It does not include some things like the GC and method cache changes.
https://github.com/ruby/ruby/blob/v2_1_0_preview1/NEWS
https://github.com/ruby/ruby/blob/v2_1_0_preview1/NEWS
From the link:
The notable changes are:
* VM (method cache)
* RGenGC
* refinements
* syntax
* Decimal Literal
* Frozen String Literal
* def's return value
* Bignum
* 128bit
* GMP
* String#scrub
* Socket.getifaddrs
* new Rubygem
The notable changes are:
* VM (method cache)
* RGenGC
* refinements
* syntax
* Decimal Literal
* Frozen String Literal
* def's return value
* Bignum
* 128bit
* GMP
* String#scrub
* Socket.getifaddrs
* new Rubygem
I think def's return value means returning symbol rather than nil?
I've been waiting for it for ten years, I had almost forgotten why I wanted it in the first place :)
So, this would mean that
private def foo
end
will now work?
private def foo
end
will now work?
Yes. And it is somewhat surprising. Matz must have rejected this idea a dozen times. It was certainly one of the oldest feature requests around. Hard to imagine what must have changed his mind. I've rarely seem Matz change his mind.
I seem to recall the issue was more with returning UnboundMethod objects than with symbols, but possibly what's changed is the fact that now symbols can be GCed?
Please tell us, what's the use case ?
It would allow you to do a number things. For instance: `memo def foo` to transform a method into a memoized version.
Could somebody elaborate on "new Rubygem"?
I remember reading a while back that Ruby was going to make an effort to separate stdlib components from the language, which I think is pretty exciting.
The more boring side of this would be a newer version of RubyGems.
I remember reading a while back that Ruby was going to make an effort to separate stdlib components from the language, which I think is pretty exciting.
The more boring side of this would be a newer version of RubyGems.
Changelog just means newer version of Rubygems, but with following new features:
1. Rubygems now has a dependency resolution mechanism similar to Bundler.
2. Rubygems has something called StubSpecification which means that complete gemspec of all the gems need not be loaded when using rubygems now. The idea is, we just need dependency from gemspec. Author name, URL etc are irrelevant details which used to get loaded before. So this should make it bit lightweight.
1. Rubygems now has a dependency resolution mechanism similar to Bundler.
2. Rubygems has something called StubSpecification which means that complete gemspec of all the gems need not be loaded when using rubygems now. The idea is, we just need dependency from gemspec. Author name, URL etc are irrelevant details which used to get loaded before. So this should make it bit lightweight.
"Rubygems now has a dependency resolution mechanism similar to Bundler."
That's a shame, because bundler is a fail. Ok, anger aside, if I had a $ for every time json has been a dep resolution blocker on bundle install, or chef, or net-ssh, Id be rich.
That's a shame, because bundler is a fail. Ok, anger aside, if I had a $ for every time json has been a dep resolution blocker on bundle install, or chef, or net-ssh, Id be rich.
That's not a Bundler fail, that's a gem packaging fail.
Yes and no. Yes, the problem is heightened by people specifying version patterns when they probably don't have to.
However, when you get a bundle install conflict error about json, one gem needing a higher version, and one needing a lower version... adding json to _my_ Gemfile/gemspec to fix it when I'm not using json directly is also not the right answer. Sometimes, even that doesn't work at all.
However, when you get a bundle install conflict error about json, one gem needing a higher version, and one needing a lower version... adding json to _my_ Gemfile/gemspec to fix it when I'm not using json directly is also not the right answer. Sometimes, even that doesn't work at all.
Still not Bundler's fault -- it can't install both versions. At any rate, versioning is a hard problem.
Even if you could install both, it would not fix anything since only one version can be loaded.
That's not why this is a shame. This is a shame because given the same Gemfile, bundler and rubygems do different things.
This is an area where so many other languages like Python[1], Go[2], etc. get it right. The only semblance of an online language reference is a version of the Pickaxe book that was already out of date back when Rails was a screaming v1.0 newborn.
[1] Python language ref: http://docs.python.org/3/reference/index.html
[2] Go language ref: http://golang.org/ref/spec