Live data from Hacker News

Ruby 2.0.0 Released

ruby-lang.org

121–130 of 303 posts

Re: Ruby 2.0.0 Released

#121
post #103
post #71

Earlier quoted context omitted.

Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing. I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember w…

There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl:

  sub withCamelize (&) {
      my ($thunk) = @_;
      local *{'String::camelize'} = sub { ... };
      $thunk->()
  }

  sub camelize_and_join {
     my ($str_ary) = @_;
     withCamelize {
        join ', ', map { $_->camelize } @$str_ary
     }
  }
So you can probably already accomplish the same with Ruby's equivalent of 'local' for dynamic scoping.

Re: Ruby 2.0.0 Released

#122
post #10

Today, I'll lose at least 50 karma points, but it's worth: Why people still use Ruby? 1. Because they get dream day rates for maintaining rusty slow legacy systems 2. Because they do not want to learn new languages and can stay in their comfort zone 3. Because they think it's still 2005 and nobody cares about slow server response times And now Ruby lovers, click on downvote or give your reasons why you still use Ruby…

Tell me what you are so bitter about. How has ruby wronged you?

Re: Ruby 2.0.0 Released

#123

I do wonder about the long term success of Ruby. Rails is easily the most visible project for Ruby. Rails is big, and all that code represents a high barrier to entry for any framework in a different language that wants to compete. However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion). Ruby also has utility for doing…

>However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion).

I agree with this but I think there is a place for a javascript framework tied fairly closely to Rails. Possibly ember.js since the attitude towards both seems similarly opinionated and Yehuda Katz is one of the ember team. The Rails API gem accommodates this quite nicely as well although one of the benefits of Rails' modular design is that you can lose lots of the stuff you don't need if you are only building a REST API. Maybe this is the future of Rails?

Re: Ruby 2.0.0 Released

#124
post #69
post #47

Earlier quoted context omitted.

So no evidence whatsoever. No java, JavaScript, python, php, perl, c++, c#, erlang?

My hunch is that it's pretty rare to see a new startup using Perl, Erlang, C++ or even Java.

It depends a lot on the business and the sector. Serious startups in fields like biotech, nanotech and finance are still very commonly using languages like C, C++, Java and F# for new projects.

These are companies creating software that'll likely still be around and in use 10 or 20 years from now, rather than web startups who will likely not survive more than a couple of years, or will rewrite their software time and time again using whatever the current over-hyped language/platform of the day is.

Re: Ruby 2.0.0 Released

#125
post #88

Earlier quoted context omitted.

Cleanliness is subjective, but: * Everything is an object, without exception. * The object model is pleasingly orthogonal and its behaviour is easy to understand and predict once you know how it works. * The syntax is high on alphanumerics and low on punctuation. * Most of the core library method names strike a good balance between brevity and clarity. * `Enumerable` is simple and powerful.

I am a pythonista by hobby... and I've seen many times in these too many ruby / python comparison, that only in ruby "Everything is an object, without exception." but... I cannot find a "thing" that isn't an object, in python neither... care to tell me, or point to a link regarding to, what is the difference in this context between the two languages? Just an example or something like that. Thanks.

I wasn't trying to compare Ruby and Python (I'm not a big Python user); I was just explaining why I said Ruby was "clean". As simonw observed, all of these points arguably apply to Python too.

Re: Ruby 2.0.0 Released

#126

There are some nice features here: Keyword arguments, which give flexibility to API design This looks good to replace all those options hashes in rails for example, though I wish they'd made it an all or nothing thing, apparently you can still do this: def foo(x, str: "foo", num: 424242) i.e. use some named and some unnamed in the same method which looks ugly. Module#prepend, which is a new way to extend a class Comp…

Module#prepend doesn't look too bad from me from a complexity perspective - inheritance in Ruby boils down to two parallel trees: One of the inheritance chains, and one of the method lookups. Really we're dealing with a single tree of "actual" inheritance, with some of them being "hidden" in some contexts. It gets a bit complex if you want to do meta-programming or do something that depends on the inheritance hierarchy, but mostly it behaves the way people expect in regular use.

Refinements, on the other hand, looks brain-damaged to me. I see the rationale, but the outcome looks more complicated and error-prone than the situation it is trying to address...

And it looks like the type of thing that will "infect" other code, just like C++ code for a while got infections of throw specifications on member functions, that then got propagated all over the place and cause major pain every time you tried to modify code. Until most people stopped using them much again except in very limited circumstances.

Re: Ruby 2.0.0 Released

#127
post #44

Earlier quoted context omitted.

People still write PHP and it is even slower. And who writes web services in pure Ruby? The response speed depends very little on the language used.

Is that actually true that PHP is slower? Say something like Symphony2 vs rails for a reasonably complicated app. Is there much out there in terms of benchmarks? (I think we are both coming from that it really doesn't matter most of the time side but would be interesting to know if PHP is actually slower).

> Is that actually true that PHP is slower?

Yes, the VM itself is not fast. However, a lot of it is just a thin shim over a C call, so whether you're going to be bottlenecked by it is going to depend on what you're doing.

Re: Ruby 2.0.0 Released

#128

Earlier quoted context omitted.

What do you mean by "so far apart"?

I think they are very different too... I just can't explain how or where. Some people SWEAR by one of the two, and refuse to use the other. That's pretty harsh for languages that similar. There must be a reason... (The simplicity vs elegance argument makes sense) Edit: I think I mean the communities are far apart.

I picked Ruby because it was sufficiently different from C and C++ to be interesting. I got to write much shorter code, for example.

I stay away from Python because it is similar enough to not give me any great benefits over Ruby, while it has some warts (to me) such as the whitespace handling, that makes it uninteresting because it is so similar that the payoff in accepting what I consider warts is too small to warrant it.

I'd have been a lot more willing to ignore the things I don't like about Python if the differences in other areas were major.

Re: Ruby 2.0.0 Released

#130
post #103

Earlier quoted context omitted.

There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl: sub withCamelize (&) { my ($thunk) = @_; local *{'String::camelize'} = sub { ... }; $thunk->() } sub camelize_and_join { my ($str_ary) = @_; withCamelize { join ', ', map { $_->camelize } @$str_ary } } So you can probably…

Wow, that reminds me of the classloader magic Eclipse/OSGi does so that plugins that depend on different versions of the same library can work together in the same JVM.
Post reply on HN