Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 2.0.0 Released

ruby-lang.org

Post reply on HN
Print view View original

201–210 of 303 posts

Re: Ruby 2.0.0 Released

#201

Post by __david__ »

noelwelsh wrote: post #83

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…

Your argument has this implicit assumption that, all things being the equal, people will choose node.js and Python over Ruby. I don't think this assumption is valid in the slightest and I think it's just showing your own bias.

Of the three I think Ruby is the better language. I still like Perl though, so what do I know. :-)

Re: Ruby 2.0.0 Released

#202

Post by whalesalad »

PommeDeTerre wrote: post #112
smnrchrds wrote: post #85

Earlier quoted context omitted.

> I just think it will slowly become less relevant. That's true for virtually anything. Do you think C/C++ or Java or JS will be mainstream 30 years from now. They will be in the same situation FORTRAN is today: important because of lots of legacy code, but not a viable choice when starting a new project. Of course some of them will never die. LISP comes to my mind. :-)

C and C++ will very likely still be "mainstream" 30 years from now. Essentially every important piece of software today, from operating systems to programming language implementations to server software to applications, is written in one or both of them. All of these systems are not just going to go away. C is over 40 years old, and C++ around 30, yet in that time nothing has come along that can compete with them. So…

Go is making a strong go at it. No pun intended.

Re: Ruby 2.0.0 Released

#204

Post by bitcrusher »

ww520 wrote: post #174
army wrote: post #153

Earlier quoted context omitted.

You seriously would turn down a good job or other opportunity if the only downside was having to write in a whitespace-sensitive language? Most of the good developers I know have their preferences for sure, but can be productive in all sorts of languages.

There are plenty of other good jobs that don't require Python. He has already said others like it but it doesn't work for him personally. Why beat it over his head for your preference?

Because sometimes, assertions seem to be so absurd, that they require clarification. If someone said, I would NEVER program in Ruby, because Hash Rockets, I would ask the same question.

Re: Ruby 2.0.0 Released

#205

Post by steveklabnik »

tjlivesey wrote: post #197
steveklabnik wrote: post #173

Earlier quoted context omitted.

I maintain rails-api, and both Yehuda and I have commit to Rails. I just want to mention that while Ember + Rails will be a potent combo, Ember will work great with non-Rails backends as well, and rails-api will work great with other frameworks too. That said, we're working really hard to make sure that Rails 4 + rails-api + Ember 1.0 is a fantastic experience, so watch that space for sure.

Thanks for all the hard work Steve. I have been waiting for ember 1.0 to really give it a proper go but I'm looking forward to it. It seems like a slightly steeper learning curve than something like backbone but I'm sure it will do more for you once you get to grips with it.

The peepcode on Ember is really worth the $12, it's a great introduction. I really believe in what Ember is doing quite a bit.

As far as Ember vs. Backbone, it's like Rails vs. Sinatra: Backbone is 'easier' but then you have to write a ton of stuff yourself. Ember has more going on, but you write a lot less code.

But where Ember really shines is the way it deals with URIs and routing. I think it's super far ahead of other JS frameworks in this respect, and I hope routing.js sees some pickup.

Re: Ruby 2.0.0 Released

#206

Post by __david__ »

AlexanderDhoore wrote: post #24
Goranek wrote: post #13

Earlier quoted context omitted.

I'm a huge Python fan and there is nothing in the world that would force me to switch to Ruby =P

That's exactly what I mean. People feel very strongly for one or the other. Yet, even you, can't deny that they are very similar! Compare them to Java, Lisp, C, Go, Haskell, Perl,...

Actually, I'd lump Perl in with Python, Ruby, and Javascript. They're all at about the same "power level" and have more or less the same built-in types and language features. They all have their own personality but if you only know 1 of the 4 you're still perfectly capable of writing any program that will be more or less equivalent to someone writing the same thing in one of the other 3.

Re: Ruby 2.0.0 Released

#207

Post by [deleted] »

vidarh wrote: post #111
noelwelsh wrote: post #83

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…

As a Ruby user that finds Rails annoying and not something I like working with, I don't think that's all that relevant. A lot of people have come to Ruby because of Rails, but a lot of Ruby people dislike Rails too. There's a plethora of web frameworks for Ruby that have sprung up exactly because of people who want to use Ruby but don't like Rails. In terms for barrier to entry with Python, the issue is that a lot of…

[deleted]

Re: Ruby 2.0.0 Released

#208

Post by [deleted] »

noelwelsh wrote: post #83

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…

[deleted]

Re: Ruby 2.0.0 Released

#209

Post by erikpukinskis »

grey-area wrote: post #116

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…

I like the idiom of mixed named and not named parameters in Ruby. You don't really need names for implied, required parameters. Consider:

    protagonist.throw(potato, :force => 3, :at => zombie)
In this case a call to :throw without an object to throw is nonsense. Throw is a transitive verb, and the parameter is implied. On a throw method, the parameter is obviously the thing being throw'ed.

On the other hand, the optional parameters are totally obscure, and need to be named.

Similarly:

    justice.join_in_matrimony(jay, bob)
The two unnamed parameters here are the things being join_in_matrimony'ed.

In other words: unnamed parameters are for direct objects, named parameters are for adjectives and prepositions.

Although arguably the Rubyish thing to do with prepositions is chain them:

    protagonist.throw(potato, force: 3).at(zombie)

Re: Ruby 2.0.0 Released

#210

Post by Tomte »

pifflesnort wrote: post #137
Tomte wrote: post #58

Earlier quoted context omitted.

The language does not implement caching. Your application architecture needs to take server caching into account. And in my experience, devs who focus so much on the "fast language" part, do so, because they don't actually know much about caching. And no, this statement is not universally qualified.

With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy. However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve…

I don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.
Post reply on HN