Live data from Hacker News

Ruby 2.0.0 Released

ruby-lang.org

181–190 of 303 posts

Re: Ruby 2.0.0 Released

#181
post #16
post #8

I guess, Rubinius is no longer relevant? I remember it was a very promising project back in 2008.

Evan Phoenix (the creator) left in 2012 to work for LivingSocial. EngineYard, his former employer, had been funding work on it last I heard, but there haven't been any releases since 2011. http://blog.fallingsnow.net/2012/03/28/a-new-door-opens/

> there haven't been any releases since 2011.

Every commit is a release of rbx. Yay continuous integration!

That said, there hasn't been a numbered release in a while, through there will be a 2.0.

Re: Ruby 2.0.0 Released

#182

Anyone have any thoughts on why python and ruby are so similar, yet so far apart? They are obviously very close, because people switch between them all the time. And they are compared on everything (languages features, libraries, tooling...). I think it's a healthy competitive environment.

The biggest difference is the communities surrounding each, and the impression each leaves on people. When I think of "Python", I think of a mature, helpful, experienced, talented, well-educated community. I can generally trust their advice, I can trust their code, and I can trust their technical decisions. It feels like collaboration is important and encouraged. The Ruby community, whether this is deserved or not, l…

As a former Python dev, I find the Ruby community to be just as positive an experience as the Python. Different, but just as positive.

Any community will have stratas of personality types that exist in various proportions:

* The loudmouth alpha types (DHH, Zed)

* The playful jesters (_why, Tom Preston-Warner) who are often evangelists

* The sharp-minded, code-focusing engineer types code (lots!)

* The newbies (lots, too!)

The Ruby community has been perceived as blighted with in-fighting, but it is, in my opinion, rather a case of certain people, the first type, trying to be public leaders, and failing at it. Those big sounds are just ill-considered publicity stunts. It's clear that DHH wants to be the Linus Torvalds of the Ruby community, blasting his way through perceived idiocy with profanity-filled speeches appealing to common sense and good engineering. Zed seems to want to be Jamie Zawinsky. Leadership does not come from being loud.

Ruby has its share of the playful and weird. Sometimes they give the impression of hyping something, because they bring with them their rosy-tinted version of the world where everything is fun and great. Sometimes they come across as glib and obnoxious because, well, they are, a bit. Overall I think they are an asset.

These two types are the people you encounter if you follow blogs and tweets, precisely because those two personality types depend on publicity. The Ruby community will certainly seem overrepresented by idiots if you go that route. But if you go on the Ruby mailing list you will see a different community, one that looks more like the Python people. Matz and many other core devs are conservative, highly technical, mature, and very helpful. There are also many low-visibility sub-communities that are very professional. My local Ruby meetup community in Oslo [1] is a wonderful bunch of highly technical, development-focused people who have none of the negative traits you describe. And if you go back to the question of what a community is supposed to provide -- help, insight, direction, ideas -- there are tons of great people.

That said, do I think the proportion of highly-skilled, high-technical is somewhat smaller in the Ruby community than the Python community? I do. Python has gained acceptance in more conservative, engineering/science/maths-oriented environments where Ruby has not yet reached, partly because of tools like SciPy. In fact, my feeling is that Python seems generally to attract a higher proportion of "engineer types" who are attracted by Python's rigidity (one way of doing things, etc.), compared to Ruby's often extreme malleability and laxness. This also means that the Ruby community is potentially missing out on some hard-core devs, and without support from the engineering/science/maths sphere it's never going to get things like SciPy.

And as for the newbies, Ruby has perhaps a bigger than usual share of inexperienced devs who are pollute the library space with lower-quality code. I blame this on the fact that Ruby is so simple to learn and has attacted many people through Rails, and this gives some devs a false feeling of confidence. I have had my share of time spent wading through other people's bug-ridden, ill-architected Ruby gems, but then if anything it's taught me to be careful.

[1] http://irb.no/

Re: Ruby 2.0.0 Released

#183
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…

Ruby doesn't have an equivalent of Perl's 'local'.

Re: Ruby 2.0.0 Released

#184

Earlier quoted context omitted.

Totally agree about refinements. Hopefully the community pushes back enough on that experiment so it gets deprecated and removed. A better design approach to achieve this effect is wrapper objects (similar to jQuery and Underscore.js) where I can add functionality to existing objects. Ruby has everything we need for this already, and makes it quite easy to do.

but ruby culture is already one of modifying builtins, so using wrappers while arguably better, does not solve the issue which refinements solve.

There's been a substantial retreat from modifying builtins in library code in the last 1-2 years anyway.

Re: Ruby 2.0.0 Released

#185

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…

Mixing keyword and non-keyword arguments isn't entirely ugly. It is in the "foo" case since "foo" is deliberately meaningless, but when there's one principal argument and the other arguments tweak or override the method's behavior, it's fine.

Re: Ruby 2.0.0 Released

#187
post #19
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…

I like writing Ruby and the speed isn't at the point where it makes a difference. A much better argument would be pointing out the tens of serious security vulnerabilities this year. :)

So, which Ruby security vulnerabilities were announced in 2013? I'll settle for ten instead of "tens".

Re: Ruby 2.0.0 Released

#188
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.

This is one: http://news.ycombinator.com/item?id=4461427

Re: Ruby 2.0.0 Released

#189
post #68

Earlier quoted context omitted.

The unfortunate thing is that there really isn't a tradeoff if you build your elegant and simple DSL on top of a set of API primitives that give you access to low-level behavior. Look at Hibernate. As of the last time I used it (admittedly, several years ago), it was almost impossible to run raw queries against the underlaying database and get back simple result sets as arrays of tuples. You had either the abstractio…

Sorry, but Hibernate has been far superior to ActiveRecord from day one. ActiveRelation is very similar to the criteria api, but it still uses string parsign. HQL is awesome. That said, I haven't done Java for 3 years and am a 100% rubyist (and some lua) The developments of rails are good. But they are simply all the stuff that maturing platforms will need. Rails is becoming JEE, but in a more developer friendly way.…

Keep in mind that I'm not an ActiveRecord fan; the internal architecture drives me nuts, but I do like that I can use SQL when I want to, without ActiveRecord getting in the way.

Here's the first Google hit I came across when looking to use PostgreSQL fulltext searches under Hibernate:

https://forum.hibernate.org/viewtopic.php?p=2447426

That's 50+ lines of code, plus some XML configuration, spread over four files, to perform a highly database-specific task that could have been better handled in raw SQL in a single line of code.

Also if I remember correctly, Hibernate, like DataMapper, requires that you specify your field types in the code, which makes migrations (updates to the DDL) a royal pain in the ass, and migrations are an important task in the operational lifecycle of an application.

I'm a big believer in having sole sources of truth, and so I treat the database as the only source for information about the structure of the database -- I don't want to have to specify that information in two places, where it can get out of sync.

Now, it's been years since I touched Hibernate, and it's probably gotten better. But from what I can tell, the above issues are design decisions; part of a conscious effort to hide the internals of the database from the developer, no matter the cost.

This is why people claim that ORM is an antipattern. Because, while an ORM solves 90% of your problems, for that remaining 10%, nothing beats being able to talk directly to the backend.

Re: Ruby 2.0.0 Released

#190

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…

The pure JS front-end approach has its advantages, but it adds a lot of complexity for advantages that don't necessarily matter. Oftentimes if not always, you get better results by rendering the HTML server-side rather than client-side.

I'm more worried about Javascript. Unlike Ruby, which has genuine advantages separate from Rails, Javascript is almost entirely propped up by its status as the only language available for DOM manipulation. Once it loses that footing, it's not a very viable language in and of itself.

Post reply on HN