Ruby 2.4.0-preview1 released(ruby-lang.org)
ruby-lang.org
Ruby 2.4.0-preview1 released
https://www.ruby-lang.org/en/news/2016/06/20/ruby-2-4-0-preview1-released/
46 comments
> The truth of it is, is that once you've picked up Ruby, nothing feels quite as nice as a scripting glue language.
I today agree. Ruby is amazing as a light scripting language - heck, I think it's pretty great as an all-around language, but quick glue scripts are where it really shines.
I wouldn't be sad to see it fade in popularity if it weren't for the fact that the language(s) and/or ecosystems eclipsing it are so, well, lame. For a profession that demands so much careful, reasoned thought software engineers as a whole can be incredibly irrational.
I today agree. Ruby is amazing as a light scripting language - heck, I think it's pretty great as an all-around language, but quick glue scripts are where it really shines.
I wouldn't be sad to see it fade in popularity if it weren't for the fact that the language(s) and/or ecosystems eclipsing it are so, well, lame. For a profession that demands so much careful, reasoned thought software engineers as a whole can be incredibly irrational.
> the language(s) and/or ecosystems eclipsing it are so, well, lame. For a profession that demands so much careful, reasoned thought software engineers as a whole can be incredibly irrational.
How do you reconcile an unsupported "lame" without being "irrational"? Do you have technical reasons they're lame?
How do you reconcile an unsupported "lame" without being "irrational"? Do you have technical reasons they're lame?
Haha, good point.
I don't have time to go into much depth right now, but basically the ascendent languages don't seem to offer many compelling technical advantages. For example, I've yet to hear a compelling reason why JS makes a better serverside language than Ruby for most use cases. To be fair, Node and some of the JS libraries for a long time offered advantages over the Ruby ecosystem for things like websockets (EventMachine used to swallow stack traces in a really annoying way). But that has more to do with the ecosystem than the languages themselves.
I think part of the problem had to do with how dominant Rails was/is in Ruby. I wish a framework that better catered to emerging app design trends had gotten traction in Rubyland in, say, 2012.
As for specific complaints about JS, well, it's a perfectly fine language, but I don't think it's an improvement in any way over Ruby. It has a number of quirks and compromises - prototype inheritance, basically no support for modules, clumsy typing, to name a few - which people have been patching over and working around in lots of different ways over the years. You end up with a forest of different solutions to things that wouldn't have been a problem in other languages. Now some fairly dramatic changes are being introduced, which is probably good, but it means the ecosystem is even more complicated. Working with the JS ecosystem feels like working with a poorly maintained legacy codebase - there are lots of places where people have come up with workarounds to things that shouldn't have been a problem in the first place; it makes you tired just thinking about all the mental energy spent solving all the little unnecessary problems.
I don't have time to go into much depth right now, but basically the ascendent languages don't seem to offer many compelling technical advantages. For example, I've yet to hear a compelling reason why JS makes a better serverside language than Ruby for most use cases. To be fair, Node and some of the JS libraries for a long time offered advantages over the Ruby ecosystem for things like websockets (EventMachine used to swallow stack traces in a really annoying way). But that has more to do with the ecosystem than the languages themselves.
I think part of the problem had to do with how dominant Rails was/is in Ruby. I wish a framework that better catered to emerging app design trends had gotten traction in Rubyland in, say, 2012.
As for specific complaints about JS, well, it's a perfectly fine language, but I don't think it's an improvement in any way over Ruby. It has a number of quirks and compromises - prototype inheritance, basically no support for modules, clumsy typing, to name a few - which people have been patching over and working around in lots of different ways over the years. You end up with a forest of different solutions to things that wouldn't have been a problem in other languages. Now some fairly dramatic changes are being introduced, which is probably good, but it means the ecosystem is even more complicated. Working with the JS ecosystem feels like working with a poorly maintained legacy codebase - there are lots of places where people have come up with workarounds to things that shouldn't have been a problem in the first place; it makes you tired just thinking about all the mental energy spent solving all the little unnecessary problems.
[deleted]
I agree. I am happy writing code in Ruby: NLP stuff, Sinatra light weight web apps, and short text handling utilities.
I also use Haskell, Java, Common Lisp, and Clojure (and Python for machine learning libraries) but I am happiest working in Ruby.
I also use Haskell, Java, Common Lisp, and Clojure (and Python for machine learning libraries) but I am happiest working in Ruby.
How do you do NLP stuff in Ruby? I thought Python was the go-to dynamic interpreted language for that work what with recent efforts by SpaCy and of course NLTK modules and Sci.py and Num.py ? What do you know that I don't. I'd love to be able to do stylometrics/topic-modelling/part-of-speech analysis/word vectors/… in Ruby -- please show me the way :)
I have a live demo: http://kbsportal.com
Edit: however, stick with Python for deep learning NLP, and NLTK works well and is exceedingly well documented.
Edit: however, stick with Python for deep learning NLP, and NLTK works well and is exceedingly well documented.
Thanks!
> how it can make a strong niche for itself besides Rails.
You anwered your own question ;-) Ruby works great for static (web)sites including books, presentations, etc and for all kind of "text" and "small data" processing. Not sure if Jekyll is already the "new Rails" - for example, I've put together a Jekyll theme site called Dr. Jekyll's [1] listing more than 100+ themes. I've also started a bookshelf (imprint) called Yuki & Moto Press [2] for books on Ruby published with Jekyll (and Octobook). Cheers. [1] http://drjekyllthemes.github.io [2] http://yukimotopress.github.io
You anwered your own question ;-) Ruby works great for static (web)sites including books, presentations, etc and for all kind of "text" and "small data" processing. Not sure if Jekyll is already the "new Rails" - for example, I've put together a Jekyll theme site called Dr. Jekyll's [1] listing more than 100+ themes. I've also started a bookshelf (imprint) called Yuki & Moto Press [2] for books on Ruby published with Jekyll (and Octobook). Cheers. [1] http://drjekyllthemes.github.io [2] http://yukimotopress.github.io
Elixir is simply the first language since Ruby to really care about code beauty and UX of the language, libraries and ecosystem.
I can't recommend Phoenix and Elixir enough.
I can't recommend Phoenix and Elixir enough.
elixir looks awesome, but there's no need to overstate its case - tons of languages really cared about beautiful code and a pleasant ecosystem. clojure was perhaps the best in that respect; there was a lot of effort made to have consistent and pretty libraries. f# seems like it's shaping up nicely too, though it still has some rough edges (but then again, so does ruby!). pyret does "beautiful code" even better than ruby does; if it had a good command line implementation and ecosystem it might have been my new favourite scripting and general-purpose language by now. elm puts a lot of love and effort into both the language and the libraries, and in particular has some of the most user-friendly error messages i've ever seen. and that's just the languages i'm familiar with; i'm sure others can chime in with lots more.
This sentiment is being repeated over and over and one can't help but notice it. But I'm really really really reluctant to switch from Ruby for yet another language/ecosystem unless it were to something industrial-strength like Haskell. What is so amazing about Elixir?
As a long time Rubyist here's a brief rundown of the features Elixir has that made me reach for it with increasing frequency:
* Pattern matching: http://elixir-lang.org/getting-started/pattern-matching.html
* Guard clauses in function definitions: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* Macros: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* The |> operator: http://elixir-lang.org/getting-started/enumerables-and-strea...
For me those really are the killer features for Elixir. I know most people will point to Elixir's support for concurrency and the whole GenServer thing that it gets from Erlang when discussing why Elixir is interesting. And those aspects of the language/ecosystem really are awesome. But being able to nearly eliminate explicit conditionals with guard clauses is just so damn cool I can barely stand it. And the |> operator is something I desperately wish Ruby had. I like Elixir a lot because it seems to put a huge emphasis on making my job as a programmer suck less without sacrificing other things in the process.
* Pattern matching: http://elixir-lang.org/getting-started/pattern-matching.html
* Guard clauses in function definitions: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* Macros: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* The |> operator: http://elixir-lang.org/getting-started/enumerables-and-strea...
For me those really are the killer features for Elixir. I know most people will point to Elixir's support for concurrency and the whole GenServer thing that it gets from Erlang when discussing why Elixir is interesting. And those aspects of the language/ecosystem really are awesome. But being able to nearly eliminate explicit conditionals with guard clauses is just so damn cool I can barely stand it. And the |> operator is something I desperately wish Ruby had. I like Elixir a lot because it seems to put a huge emphasis on making my job as a programmer suck less without sacrificing other things in the process.
Try Phoenix with Elixir. Really similar to Rails with Ruby on the surface, and surface similarities are all you will really worry about for static pages.
Views (called Templates in Phoenix) are compiled as strings and cached by the CPU automatically so you get really nice scaling out of the box, with no effort on your part.
Views (called Templates in Phoenix) are compiled as strings and cached by the CPU automatically so you get really nice scaling out of the box, with no effort on your part.
It's similar to Rails in Rails' ideas, but not in its ecosystem. The most powerful thing of Rails is not MVC, or convention over configuration, but the vast, vast ecosystem.
For static pages that is kind of irrelevant though.
> I thought it'd be worthwhile to move to a new framework just so I don't have to juggle so many languages on a daily basis.
That's actually a big reason we use Clojure at work for our web app: the only language we use is Clojure, from beginning to end.
That's actually a big reason we use Clojure at work for our web app: the only language we use is Clojure, from beginning to end.
Honest question: how can you stand the JVM start up time and the terrible stack traces?
I find myself wishing there were a clojure not on the JVM (or on javascript)...pretty much I think I'd be happier with another lisp, but I'm not sure.
I find myself wishing there were a clojure not on the JVM (or on javascript)...pretty much I think I'd be happier with another lisp, but I'm not sure.
Good question.
At the beginning of my work day, I open Emacs with Cider installed, and start a JVM inside there using Cider (M-x cider-jack-in), and do all my work in the same JVM all day.
Because we make heavy use of immutability, it's easy to completely tear down all our existing namespaces and the single global variable representing the app, reload all namespaces and their functions, recreate a new app instance, and start it. And I bound all this to Cmd-R in Emacs.
So any time I make a change to our web app during development, I just hit Cmd-R and it reloads the entire app in about 0.2 seconds. I don't even notice it, honestly.
This is better than what we used to do, which was to poll the disk for changes to any files, and reload them when they've changed. That was much harder on the disk, and half the time I'm saving, I'm not ready for its code to be reloaded yet anyway.
For tests, we just use Cider's built-in features, which let us either run the tests whose code changed, or all tests, depending on what we want to test.
At the beginning of my work day, I open Emacs with Cider installed, and start a JVM inside there using Cider (M-x cider-jack-in), and do all my work in the same JVM all day.
Because we make heavy use of immutability, it's easy to completely tear down all our existing namespaces and the single global variable representing the app, reload all namespaces and their functions, recreate a new app instance, and start it. And I bound all this to Cmd-R in Emacs.
So any time I make a change to our web app during development, I just hit Cmd-R and it reloads the entire app in about 0.2 seconds. I don't even notice it, honestly.
This is better than what we used to do, which was to poll the disk for changes to any files, and reload them when they've changed. That was much harder on the disk, and half the time I'm saving, I'm not ready for its code to be reloaded yet anyway.
For tests, we just use Cider's built-in features, which let us either run the tests whose code changed, or all tests, depending on what we want to test.
thanks for the write up, real work examples are so useful!
JVM startup time is kind of annoying, but doesn't seem like a very big problem. You can use drip or nailgun to avoid dealing with it most of the time.
That's definitely on my list, at least to learn it for expanding my knowledge of language design. It's hard to imagine moving away from Python and all of its scientific packages.
(I really do hope I never have to build another full-stack web app, either in Rails, Django, or whatever...unless it's to put food on the table)
(I really do hope I never have to build another full-stack web app, either in Rails, Django, or whatever...unless it's to put food on the table)
I can relate. As I find myself doing more front-end work, it seems natural to be using JS on the backend as well, but I simply don't enjoy it as much. Not just the language, but the design and UX of all the popular libraries as well.
nice, what's keeping http://www.isrubyfastyet.com/ from updating the charts to > 2.2?
The author might be waiting for ruby 3:
The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2 https://news.ycombinator.com/item?id=10600017
The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2 https://news.ycombinator.com/item?id=10600017
I can only assume it's been abandoned https://github.com/brianhempel/isrubyfastyet/issues/18
http://www.isrubyfastyet.com/latest.log
I agree with you. The latest "nightly" log was taken in January 2015.
I agree with you. The latest "nightly" log was taken in January 2015.
[deleted]
Check out RubyBench. https://rubybench.org
I am still surprised by this behavior change from 2.2.3 to 2.3.0 (and also present in 2.3.1 and 2.4.0):
$ ./ruby -e "puts RUBY_DESCRIPTION ; rand(BasicObject.new)"
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]
-e:1:in `rand': undefined method `begin' for #<BasicObject:0x007fe0be4cb548> (NoMethodError)
from -e:1:in `<main>'
$ ./ruby -e "puts RUBY_DESCRIPTION ; rand(BasicObject.new)"
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]
-e:1:in `rand': undefined method `respond_to?' for #<BasicObject:0x007fa2d719bf78> (NoMethodError)
from -e:1:in `<main>'
I think you're looking in the wrong place, `BasicObject` has no `respond_to?` so you'd need to trace the `rand_random` execution to see what ends up calling `respond_to?` on your `BasicObject` instance. Poking through github I'm guessing it's `rb_funcallv_public` but I may be missing something(s).
But that's just it; I would have thought the NoMethodError would have been around the missing "respond_to?" - like it was in 2.2.3 - not around a missing "begin".
Like @tvon, I'm not up to digging through the code, but I'd guess it's falling through to eventually make an unconditional call to http://ruby-doc.org/core-2.3.0/Range.html#method-i-begin.
That's exactly right; but that's happening because vm_respond_to is returning true on a nil method entry. It's a puzzler...
I assume you mean at https://github.com/ruby/ruby/blob/v2_3_0/vm_method.c#L1915-L.... Agreed it's weird that rb_respond_to will now return true for objects where respond_to is undefined. Though I guess I can see upsides to doing so, and it would require something pretty weird to result in "wrong" behavior.
Yup that's the code that I'm wondering about.
The case I ran into was in a Rails 4.1 app where ActiveSupport::Duration (which subclassed BasicObject) was used like this: "rand(10.minutes)". That raised an exception in 2.3.0 but worked fine in 2.2.3. The fix was simple - "rand(10.minutes.to_i)". But still, I don't understand it.
The case I ran into was in a Rails 4.1 app where ActiveSupport::Duration (which subclassed BasicObject) was used like this: "rand(10.minutes)". That raised an exception in 2.3.0 but worked fine in 2.2.3. The fix was simple - "rand(10.minutes.to_i)". But still, I don't understand it.
Heh...I also ran into an issue with ActiveSupport::Duration, though in my case when passed as the only argument to a method with a signature along the lines of `f(time = 30, [star][star]options)`, with the error involving #to_hash. Since newer versions of ActiveSupport fix it, I didn't look into it too careful (just called #to_i). I'm glad you did!
Ah ha! It was a Ruby bug... longer writeup here:
http://thomasleecopeland.com/2016/06/26/basicobject-is-a-ran...
http://thomasleecopeland.com/2016/06/26/basicobject-is-a-ran...
Yeah sounds like in the same ballpark. David Stostik did a nice writeup of the oddities of ActiveSupport::Duration 4.1 here http://www.bnjs.co/2015/01/14/rails-date-class-durations-and....
I'm surprised that I haven't seen anything about that respond_to? change in the blogs; maybe I've just missed it. I might blog this, although I hate ending a post with "gosh I don't know about this one". Makes me feel like I haven't done all my homework.
I'm surprised that I haven't seen anything about that respond_to? change in the blogs; maybe I've just missed it. I might blog this, although I hate ending a post with "gosh I don't know about this one". Makes me feel like I haven't done all my homework.
As someone that really appreciates overlayed comparative graphs has anyone visualised some common benchmarks yet
*edit: interesting HN site bug, I hit edit to update some autocorrect mistakes and rather than updating my comment it added a fresh one - but not the second time. Interesting.
*edit: interesting HN site bug, I hit edit to update some autocorrect mistakes and rather than updating my comment it added a fresh one - but not the second time. Interesting.
That is fast, I barely started using 2.3.0 in my projects. Not following closely what is added but have impression that rate of change in ruby land is picked up significantly.
They're on a predictable cycle: minor version release every December 25. (so 2.4.0 final will be released December 25, 2016; which is why they're calling it "early" as the many features may need more testing)
[deleted]
I used to do Ruby because of Rails work...now I do my work exclusively in Python and Node. I thought it'd be worthwhile to move to a new framework just so I don't have to juggle so many languages on a daily basis. Lektor (Python) is exciting and I'll check it out as a way to build client sites...but it's not quite as flexible as Middleman (to be fair, Lektor is very new)...Pelican looks good as well...but for now, I think Middleman hits the perfect spot for speed of deployment and hackability (it recently extricated itself from sprockets so that you can incorporate webpack.js or whatever asset build system you like), even accounting for Middleman's and Ruby's slow speed of execution versus the hugely popular Hugo (static framework in Go)
The truth of it is, is that once you've picked up Ruby, nothing feels quite as nice as a scripting glue language. I haven't kept up much with updates to the language...all I know is that yesterday, I finally updated my Ruby environment manager (rbenv)...it had been 2 years...and changed my system Ruby to 2.3.1 (from 2.1.5)...I had to update a few version numbers for dependencies, but otherwise, all of my old projects worked with barely a hitch...and it took me no time to get into writing custom plugins for my next Middleman site.
It does seem that the excitement over Rails and Ruby has ebbed, if you look at Github stats and Stackoverflow's latest survey. I am curious to see where the language can go from here, or how it can make a strong niche for itself besides Rails. but of all the "old" languages that I sometimes have to come back to, Ruby has been the most welcoming.