[tferris]

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.

[venus]

And you deserve to lose those 50 points. Why do people still write silly comments like this?

1. Probably 75% of new startups are using rails, and rightly so. You'd need a good reason not to use it. "Rusty slow legacy systems" - what nonsense.

2. If there was a better language, they'd probably learn it? Or are you trying to insinuate Ruby programmers are dumb/lazy?

3. If you are blaming your slow web page on Ruby, you're doing it wrong.

[rbn]

I dont know about that 75%. Considering that more and more people are using Nodejs. Just take a look at some of the companies using Express. http://expressjs.com/applications.html

[tferris]

> 1. Probably 75% of new startups are using rails, and rightly so. You'd need a good reason not to use it. "Rusty slow legacy systems" - what nonsense.

75%? Evidence? You are the one who is talking nonsense, sorry to be direct and getting on Reddit level but you started.

> 2. If there was a better language, they'd probably learn it? Or are you trying to insinuate Ruby programmers are dumb/lazy?

Do I really have to tell you? Instead of doing some research Rubyists still defend their old tech (like you do now).

> 3. If you are blaming your slow web page on Ruby, you're doing it wrong.

Yes you are right, and now get back in your comfort zone and code some slow web services.

[mosselman]

Firstly (Disclaimer) I am a Rails developer, I choose to be one right now, until (if) I find that my efforts are better spent elsewhere.

I agree with tferris to some extent. Those arguments are nonsensical to say the least.

This might be a feeling, I am not one to shout random feeling-based percentages, but I feel that people, in general, not just HN, don't realise that you can just claim things in this way. 75%? Where does that come from?

Also, the second argument is complete rubbish. By this logic anything that the masses do is better? So Earth was flat at some point in time? And yes, I think that people ARE lazy, as we should be, why use a framework otherwise? But some people are just stuck in the before mentioned comfort zone. Evidence is the popularity of Rails clones in PHP (or at least attempts at). Why not just learn Ruby and use Rails? => Fear of learning new programming languages and being new at something?

Third argument is right to a certain extent. If you need to invest a lot of trouble to make some slow code (which Ruby tends to be) faster, at what point do you choose to just use something faster? Where is the line; break even point?

I use Ruby at the moment too, but you have to remain critical and even more so, you need to reflect on your own ways of reasoning.

[venus]

> By this logic anything that the masses do is better?

Yeah, I could have worded that better. The OP said:

  Why people still use Ruby?
  2. Because they do not want to learn new languages and can stay in their comfort zone

Which implies that a reason people are "still" using ruby is that they are too lazy to switch to one of the new, "better" languages or frameworks. I was just trying to point out, maybe they haven't identified that there's a better language or framework yet? I am not aware of any obviously superior alternative and if I found one, of course I'd start learning about it.

75% was a wild-ass guess which I nonetheless believe is pretty much right. But maybe it's 50%. Who knows. The point was, rails devs are not solely working to maintain "rusty slow legacy systems".

> I am a Rails developer, I choose to be one right now, until (if) I find that my efforts are better spent elsewhere.

Couldn't have said it better myself.

[i386]

Well you should use a framework not because you are lazy but because there are a million other actually important things you should be doing than implementing state for HTTP for the billionth time.

[mosselman]

Potato potato.

You are a 'glass-half-empty' interpreter of the word 'lazy'.

Easy syntax, DRY, etc. are things that are good because they limit you to waste time on trivial things, like you said. They stop you from reinventing the wheel.

I call that (positive) laziness. You can call it whatever you want of course. It still boils down to the same thing.

I have worked at places where programmers were willing to write thousands of lines of code, often copy-pasting big chunks and just replacing a few variable names. Needless to say, I didn't want to work there for very long. There is often no way to convince those kinds of programmers to stop and think about logic or technical design. They feel that they could just as easily write a few hundred lines again and again. Me, and my others, feel that you shouldn't repeat yourself in code and should limit your day-to-day efforts by writing reusable code, etc, etc. I don't need to tell you of course.

[revskill]

Do you mean PHP languague ?

[d4mi3n]

Having spent a good year at the 2012 batch at the 500 Startups office, I can safely say that the majority (>60%) of the guys I spoke with there were working off some sort of rails stack.

[venus]

> 75%? Evidence?

None really, just the startups at an incubator-type place near me. Might not be 75% but it's certainly a big chunk and probably the majority.

[timc3]

So no evidence whatsoever.

No java, JavaScript, python, php, perl, c++, c#, erlang?

[simonw]

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

[PommeDeTerre]

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.

[draegtun]

Also they don't get the attention the hot languages get.

However there are some Perl startups, for eg: Lokku, Blekko, Moonfruit, DuckDuckGo, CareerJet & Adzuna

[eCa]

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

[doktrin]

Why is this post at the top? It's nothing but flame bait. It consists entirely of feces-slinging, and not a single substantive topic is addressed.

[timc3]

I think asking the question why people use it is a good topic, it could have been asked in a better way

[tferris]

> It's nothing but flame bait

Why? I am damn serious about every point: Ruby/its entire ecosystem/Rails/DHH is outdated/becoming obsolete/so 2005.

[doktrin]

Repeating "x is so 2005" is not a discussion point.

Your original post, and every one since (including the multiple sets of edits you apply to each), consist of nothing but a daisy chain of mud slinging and ad-hominem attacks directed at other commenters.

You're a troll, plain and simple. Sorry for feeding you, but I simply think it's sad this unproductive rant has completely derailed the entire discussion here.

[kicktheshoe]

Repeating "x is so 2005" is not a discussion point.

I agree, just because something has been around a long time e.g. Unix/Linux doesn't mean it's bad.

If I had a buck for every time I heard a Rubyist say "Java is so 90's" ...

[judofyr]

And you backed it up with no facts what so ever.

[foz]

You don' know what you're talking about. I lead the web team for local.ch, we have 4mil unique clients a month and handle 10k requests per minute in peak traffic. Our site is developed in Ruby on Rails, with average response times from in the 150ms range. We replaced our legacy PHP system last year and will never look back. Ruby 2.0 will be our future, and I'm happy about that.

[pimeys]

We're having millions of unique clients per month and our peak traffic is above 200k requests per minute. Ruby delivers, although you need to be very careful what you deploy to the main app codebase. Especially to realize the speed differences between stuff like uniq vs. uniq! or the cost of creating new objects. It's enormous with big traffic.

There are some things I wouldn't do with Ruby here. Like some concurrent background jobs; better solution would be Clojure, Erlang or any language where the concurrency constructs are better thought and easier to manage. Although we're having threaded Ruby running, it's not very elegant and you can do pretty nasty bugs in there.

[kicktheshoe]

that's about 3.3k requests per second. How many hosts is that spread across?

[pimeys]

Maybe too many, I guess. Not giving any real numbers, but I suppose with JVM this could be much less. Oh hell, even with some refactoring here and there we reduced the overall CPU usage a lot. Like I said, with real traffic, the bang methods are a much better choice even though the functional programmer in me is against them.

[aegiso]

Great points. Speed and newness are paramount!

This is exactly why the most accomplished hackers write their web apps in SSE4.2 machine code.

[vidarh]

You're not having your app baked into ASICs?

[timc3]

Awesome idea ;-)

[creamyhorror]

You might as well ask why people still use Java. Because it works for their purposes, is popular (i.e. has market demand), and there aren't enough perceived incentives to move to a newer/better language yet.

I'd very much like to learn the next great framework and its language - I just haven't been convinced by any of the front-runners quite yet (especially in terms of ecosystem resources). When that happens, you can bet many coders like me will jump on it. Till then we'll just continue to work on our Rails apps.

[tferris]

> why people still use Java

I am not into Java but I'd rather prefer using Java the next 10 years than Ruby 1 month. At least I get a perfect language implementation (the JVM) with Java.

[vidarh]

> At least I get a perfect language implementation (the JVM) with Java.

I don't agree with you about the JVM, but you're clearly ignorant of Ruby if you're not aware that there's a Ruby implementation that runs on the JVM (JRuby).

[reinhardt]

Let me guess.. Node/Clojure/hip-language-du-jour-nobody-uses brogrammer?

Disclaimer: I am not a Ruby programmer.

[stiff]

Don't feed the troll, please...

[estavaro]

I have quite a bit of Ruby for the server-side. But on the client-side I've been using Dart instead.

While Dart could be good for the server-side too, as it's VM will be as fast as any other dynamic language VM out there and the language is still quite cool, on the server-side we get to choose the tools more freely so there are many options.

Then again, why would people use Dart or Ruby on the server-side if they could use Go instead?

Go and languages like it are more lower level and sometimes more demanding, making mixing and matching while programming harder.

Mixing and matching is a way of programming for today rather than for the future. Say, dealing with the issues as they present themselves rather than trying to go around them. Say, dealing with the UI as they are popular rather than doing things in an unusual way while trying to guess the future.

I really liked watching an Intel guy say that if your approach to parallelism isn't about sharing the load to over a hundred threads, then forget about guessing the future.

For now as in the past, people have been successfully using threads for doing what they were originally meant for as Guido Van Rossum explained in a recent video. Threads were meant for concurrent I/O work. Now people want to push them to doing more parallelism. Not sure how we are going to get there.

Because like supporting many GUI front-ends has taught us, getting the most out of GUI often means that you need to target them on a one-to-one basis. Creating programs that support 1 thread or 100 threads from the same codebase will be quite a challenge going forward. Because if you want most performance from just 1 thread, it could be that the program needed to be written one way. Whereas to make it better for 100+ threads, it could need to be written a different way.

So, why would people write Ruby? Because it works. The Internet is unreliable anyways. Depending on a central server is too all-eggs-in-the-same-basket for the Internet.

Also Ruby is getting more stable. Depending on new tech can lead you to unstable nightmares.

If you were worried about bigger codebases and still wanted a language like Ruby, I'd first recommend Dart than Go. But for its current stability concerns. It will hit 1.0 soon though.

[Skoofoo]

You have a valid question, you didn't have to ask it so sneeringly.

I am a fan of Ruby in big part because of how it handles objects. In Ruby, everything is an object. Objects' only public interface is their methods. These methods don't require a pair of parenthesis to call them, so you can call them as you would access a public variable in other languages. You can easily set up getter/setter methods for an instance variable via an "attr_accessor :instance_variable" call within the class definition, or you can define its "instance_variable" and "instance_variable=" methods yourself.

This combination of things is I think Ruby's killer feature and makes for a very elegant workflow. You should give Ruby a chance :)

[nilved]

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. :)

[rimantas]

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

[rimantas]

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.

[robryan]

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).

[Gigablah]

I don't know about Rails, but as a Symfony2 user, it's actually a bit on the slower side compared to other PHP frameworks.

But ~300ms server response times is nothing if your end user has to wait 5-6 seconds for the page to render due to suboptimal frontend code. Plus, throw in varnish/nginx microcaching and requests drop to ~10ms regardless of your framework.

[mtts]

> But ~300ms server response times is nothing if your end user has to wait 5-6 seconds for the page to render due to suboptimal frontend code.

True for a single request, but once you start getting lots of concurrent requests all those ~300ms server response times start adding up quite quickly.

When Twitter started out, their use of ROR wasn't a problem. Once the service started to become popular, however, it was.

[regularfry]

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

[jdale27]

I downvoted you for writing "loose" instead of "lose".

[tferris]

Thanks, corrected.

[tomstuart]

It's fun, it's clean, it's simple, and it works.

[yakiv]

I use Ruby some, but I'm not sure I'd describe it as clean exactly. I've used Python a bit recently and was struck by just how clean it seemed. (I'm not sure Python has anything that quite replaces blocks, though. I don't claim Python's all better than Ruby.)

[tomstuart]

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.

[simonw]

Amusingly, you could be talking about Ruby or Python on all of these points (if you swap swap "Enumerable" for "the iterator protocol").

[tomstuart]

Arguably so. :)

In my opinion Ruby pips Python to the post (however slightly) in each respect, but it's clearly a question of taste.

[_ZeD_]

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.

[estavaro]

Trying to guess how Python works is quite hard if you're used to Ruby and other languages closer to Java.

As I don't know much Python myself, it's hard to tell where Python fails the "everything is an Object" check. But in Python some legacy calls were more procedural than OO, like "len(o)" rather than "o.len". I think eventually Python got to support both approaches.

I think Ruby is all objects even in its C abstractions. In Ruby, people create classes and so on in the RubyC abstractions that are visible to the Ruby language too. Not sure how Python does those.

I know Python has reference counting for Garbage Collection, so there are differences to their approaches in that regard and more.

Like Guido Van Rossum said, from 10,000 feet both Ruby and Python are more alike than different. He was saying that people should appreciate them more even if they belong to the community of the other one. That the real enemy is languages like Java that switch around the priority by making code that compilers prefer rather than programmers prefer.

I think Python has a Functions legacy that could not be as OO as they would be in Ruby.

Right now I'm more "in love" with Dart than with Ruby. Ruby was my first real love though.

[_ZeD_]

Just as note: I don't really would call "len(o)" a "legacy call", as in "something it's here just for backward compatibility, but it's ugly and please don't use it".

It's more "the good way to do it" :D

len() is a perfect example of the duck typing and the "protocol-based" philosophy of python: its implementation it's something like

    def len(object):
        return object.__len__()

as in "just return the result of invoking the object method called __len__".

this lets you just call len() on every "len-able" object. They can be list, dict, custom objects... instead of the need to, I don't know, implements an explicit interface, or define a "getLength()", "size()", "length()", "length" (just an attribute, not a function to call), you can just define a "magic" (as in "normally you don't need to call this directly") method called __len__.

you can create your "not really a container, but it has a length!" object as something like

    >>> class C:
    ...     def __len__(self):
    ...         return 42
    ...
    >>> len(C())
    42

As indirect effect, it enables you to go on the functional-style approach... a simple

   map(len, list_of_lists)

it's more readable than

   map(lambda l: l.__len__(), list_of_lists)

(probably [len(l) for l in list_of_lists] it's more readable, but bear with me...)

I'm not really sure about the "ruby C abstractions": do you refer to the use of "object-like" structs used in the C sources of the "ruby MRI" implementation of "ruby-the-language"?

regarding the GC... I don't know, but why is the kind of the GC used by an implementation of the language (or the complete lack of a GC) relevant to the "everything is an object"?

just to be clear, I don't dislike ruby :) it's just that I don't find the "everything is an object" a way to discriminate between ruby and python.

[tomstuart]

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.

[yareally]

People program in what they know and what gets the job done in the most optimal way for them. Learning a new language without a good reason past certain users not liking it is silly.

Plenty of people criticize Notch for using Java in all of his games, but Notch gets things done. It's hard to ridicule someone making so many useful things (well you can, but most end up looking like jerks lacking tact). Might not be in the coolest or most efficient language, but the results speak for themselves.

People use x language because x gets things done for them, their business and it shows results. People that spend much of their day thinking about how they dislike a particular language and its users generally are not the ones being productive with their more enlightened language(s) of choice.

[army]

Yup, there's no reason why you can't be productive writing code in Java if if you're willing to get over the fact that you'll be writing more lines of code.

I've been implementing a compiler in Java (not my original decision, but I don't think it was a bad one) and, although its frustrating at times knowing that some list transformation would be a one-liner in other languages but five lines of Java, it hasn't actually proven to be a drag on productivity. You have automatic memory management, a reasonable selection of basic collections, a reasonable selection of abstraction mechanisms, the ability to implement things like immutable classes, etc, so there aren't any major obstacles to productivity.

A lot of times when writing new code I wish I had builtin tagged unions, since I have to do it manually with a class and an enum. But once I've actually implemented a tagged union, I don't find that future additions and maintenance work on the code actually take any extra time.

[thetron]

Because it makes me happy.

[sspiff]

You seem to think people should constantly jump ship and change languages/ecosystems. I used to do this, and the result is that you don't get results.

I still look at new developments, and toy with new technology and programming languages, but when I want to get shit done, I find there's little that defeats using plain "old" C, Ruby, Java or whatever else you would probably call outdated.

[norswap]

It is one of the most active eco-system out there, and gems are a breeze to install.

Ruby itself is quite flexible and easy to use although it does have quirks.

But yes, ruby is hellishly slow. I have not enough experience to speak about the legacy systems, though it would interest me to know about that. You do hear a lot of stories about switching from Ruby to Scala/Java/Clojure.

[Tomte]

Its language semantics are a sweet spot for me.

And in my kind of web applications I handle massive load via HTTP Caching, leaving your "fast" language without cache-aware architecture far behind, thank you very much.

[timc3]

And then then the fast lanugage implements caching.. Your first point is valid

[Tomte]

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.

[pifflesnort]

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 acceptable speeds at all.

[Tomte]

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.

[pifflesnort]

You don't implement HTTP caching, except in very specific cases.

You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.

[dasil003]

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

[obilgic]

I downvoted you just because of your anarchical attitude ... That is not the right way to start a healthy/useful discussion.

[tferris]

> That is not the right way to start a healthy/useful discussion.

Maybe you are right but I am just fed up that on HN the forefront of new tech still such old slow technology gets upvoted on a regular base mostly by people fearing their go to tech is vanishing away. Ruby/DHH/its entire opinionated ecosystem is so 2005.

[mitchty]

> is so 2005

So you have no actual quantifiable arguments and resort to this and ad hominem attacks on people that use a programming language? Not the best way to make your case.

[fwee]

Should we learn some 'new' and 'fast' language, then code slow service?

[MrBra]

Now tell me, did you initially learn to code just because you liked fast things? There is more to it.. it's sad when these "once-IT-lovers" forget about this part completely.

I believe that Ruby was born in the first place with a kind of a sentiment of not wanting at all to become the speed optimization guy if that ever means sacrificing the part in itself that allows for so much freedom and creativity! And I guess this is exactly how the community around it feels it.

You get the good milliseconds stats, plus money.

A Rubyist might respond with a bunch of more ms. here and there(for now); he gets the same money; he has much more fun.

Is it so hard to understand ?

Do you still enjoy programming like you did in the first days? If not, take a look at Ruby, seriously :)

Probably, better Ruby performance will come with time, but if Ruby will fail in the long term, then it will happen just because of a new more performant, but equally (or more) fun/smart language.

In conclusion I think that Ruby has the merit of having woken up the feeling that programming can always be as fun as the first days and.. that it doesn't have to transform you into a sad, dissociative geeky looking person anymore.. :P

No offense intended!.. :)

[tykko]

Ruby lovers are all about "feelings" and "style", they don't care if their language of choice is objectively worse than, say, Python or Lua.

Ruby truly is the Apple of the programming world.

[nsmartt]

I fought with Python for weeks before I picked up Ruby. It clicked perfectly and I've never had to fight with it.

I don't see how Python can be objectively better than Ruby.

I don't know enough about Lua to comment.

[VeejayRampay]

I really love the use of the word "objectively" in your sentence. It's totally irrelevant and has no ground in reality or the realm of logical reasoning. As such, it is in fact quite revealing of your true intent with this comment: riling people up and trolling.

Maybe you should think long and hard about why exactly Ruby (and Apple for that matter) makes you so mad that even though you don't use it or program with it, you have to come here on an article about a new release just to spit some venom even though the language itself doesn't impact your personal life in the slightest.

[revskill]

You're wrong. Do you know Ruby is the breed of so many developers (who has used other languages, too) ?. You should compare Ruby to open source philosophy, it's one of its implementation. Yes, if Ruby was dead, open source is dead too, i believe it !

[MrBra]

> Ruby truly is the Apple of the programming world.

No fucking way.