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.
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.
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.
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.
No java, JavaScript, python, php, perl, c++, c#, erlang?
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.
However there are some Perl startups, for eg: Lokku, Blekko, Moonfruit, DuckDuckGo, CareerJet & Adzuna
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.
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.
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
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.
Why? I am damn serious about every point: Ruby/its entire ecosystem/Rails/DHH is outdated/becoming obsolete/so 2005.
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.
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" ...
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.
This is exactly why the most accomplished hackers write their web apps in SSE4.2 machine code.
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.
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.
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).
Disclaimer: I am not a Ruby programmer.
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.
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 :)
(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).
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.
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.
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.
* 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.
In my opinion Ruby pips Python to the post (however slightly) in each respect, but it's clearly a question of taste.
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.
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.
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__()
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
map(len, list_of_lists)
map(lambda l: l.__len__(), list_of_lists)
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.
Switching those function calls around reminds me of Delphi. When I first learned about Python, those calls reminded me of Delphi which I had used more. But once I learned Java, my frame of mind went from function(object) to object.function. With Ruby I found it quite intuitive. Now all languages work better if they approach things the way Java and Ruby do because of familiarity. That's why I like Dart for what it's worth.
Regarding C extensions of Ruby, they are like OO in C. Not sure how Python does it by default. But in Ruby all C extensions have a OO flavor. The first major book about Ruby writes about them: http://www.ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.h...
I think if you're counting references in the GC perhaps your C extensions are not very OO yet. In Ruby as in Java, the GC is an abstraction over reference counting. I think reference counting is often said to lead to more predictable performance at the cost of increasing the maintenance burden.
So again, not sure where Python is not "Objects all the way down." But Ruby has had the OO philosophy from early on. I think the Ruby OO approach started with the OO of the C extensions and went from there. Unlike Python that had a stronger procedural influence. The gap has closed since, but in Python a class is not written like this yet:
class InRuby
def aMethod
end
end
class InDart {
aMethod() {}
}in python a class is written as
class InPython:
def aMethod(self):
pass
regarding the C extensions... I didn't really needed to write one, but from http://docs.python.org/3/extending/extending.html#a-simple-e... I see
static PyObject *
spam_system(PyObject *self, PyObject *args)
...
I honestly have no idea on how is (or if it has some meaning) to extend python in rpython on pypy, but in this case I assume there are some objects involved :D
In Python I've seen Python users discourage the use of classes. I haven't seen the same distrust of classes in Ruby for instance. It's as though Python has unresolved OO issues. Python could take pride in being "multi-paradigm", whereas languages like Ruby and Dart could take pride in being more OO.
Regarding the C extensions of Ruby, I think the bottomline is that from int, to booleans, to null, to classes, everything is considered OO even in the C code. So common functions can be applied to them even from C, say like Polymorphism would in other languages. From the primitives on up everything is like a high level Ruby. As Python is more "multi-paradigm" perhaps some of its C extension features aren't as OO as Ruby's are.
Funny though that those C extensions that make Python and Ruby so popular end up making other implementations of those languages that target other runtimes incompatible as they don't have access to those C extensions. So even in that regard they are similar.
Say we can't find anywhere in Python where Objects don't exist. Then welcome on board of true OO. Now show OO some love and stop discouraging the using of classes. Maybe drop the "multi-paradigm" approach. I know though that like JavaScript, sometimes you have to live with the shortcomings of the programming language in its support of OO. So while JavaScript could be said to have Objects everywhere, and it truly does, writing classes in JavaScript is not a settled issue. That's why I like Dart instead:
class A {
var aList = ['a', 'aa'];
get length => aList.length;
}
class B {
var aList = ['b', 'bb', 'bbb'];
get length => aList.length;
}
class C extends A {
var aList = ['c', 'cc', 'ccc', 'cccc'];
}
printIt(o) {
print("${o.aList}: ${o.length}");
}
void main() {
printIt(new A());
printIt(new B());
printIt(new C());
}
[a, aa]: 2
[b, bb, bbb]: 3
[c, cc, ccc, cccc]: 4You're correct - we can't find a place in Python where Objects don't exist. Python and Ruby are exactly same in this.
>>Then welcome on board of true OO. Now show OO some love and stop discouraging the using of classes.
What do you mean by true OO?
It does not matter if you "love" objects or not. You can't write in python without OO. Every python module is an object, defs and vars - members of object. (Even classes and other modules are members of module object).
Yeah. You are right about the fact that a possible "convention" would be to call .len, not .__len__ but you are forgetting 20+ years of backward compatibility.
I don't know when len() was introduced, and I'm not sure it's initial implementation was a simple "return object.__len__()" (or an equivalent...). What I know is that an explicit len function helped to hide the eventually different implementation details, and allowed the developers of the containers go crazy with attributes.
Moreover, with a len(obj) function and a obj.len() "public" method, you have two ways to do it.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!.. :)
Ruby truly is the Apple of the programming world.
No fucking way.
I don't see how Python can be objectively better than Ruby.
I don't know enough about Lua to comment.
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.