As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to write a backend system for a web site (it'll be a custom search-style service). It needs to be highly concurrent and fast. Given my wish for concurrency, I was planning on using a functional language such as Haskell or Scala.
However, speed is also a priority. http://benchmarksgame.alioth.debian.org results appear to show that Java is almost as fast as C/C++, Scala is generally pretty good, but Haskell ranges from slower to a lot slower for most tasks.
Does anyone have any performance benchmarks/experience of using Haskell vs Scala vs Java for performing highly concurrent tasks?
Some sites I've seen suggest that Scala has memory leaks which could be terrible for long running services such as this one.
What should I write my service in, or what should I take into account before choosing (performance and concurrency being the highest priorities)?
Thanks
This question is superficially about performance of code compiled with GHC vs code running on the JVM. But there are a lot of other factors that come into play.
People
Is there a team working on this, or just you?
How familiar/comfortable is that team with these languages?
Is this a language you (all) want to invest time in learning?
Who will maintain it?
Behavior
How long is this project expected to live?
When, if ever, is downtime acceptable?
What kind of processing will this program do?
Are there well-known libraries that can aid you in this?
Are you willing to roll your own library? How difficult would this be in that language?
Community
How much do you plan to draw from open source?
How much do you plan to contribute to open source?
How lively and helpful is the community
on StackOverflow
on irc
on Reddit
working on open source components that you might make use of
Tools
Do you need an IDE?
Do you need code profiling?
What kind of testing do you want to do?
How helpful is the language's documentation? And for the libraries you will use?
Are there tools to fill needs you didn't even know you had yet?
There are a million and one other factors that you should consider. Whether you choose Scala, Java, or Haskell, I can almost guarantee that you will be able to meet your performance requirements (meaning, it probably requires approximately the same amount of intelligence to meet your performance requirements in any of those languages). The Haskell community is notoriously helpful, and my limited experience with the Scala community has been much the same as with Haskell. Personally I am starting to find Java rather icky compared to languages that at least have first-class functions. Also, there are a lot more Java programmers out there, causing a proliferation of information on the internet about Java, for better (more likely what you need to know is out there) or worse (lots of noise to sift through).
tl;dr I'm pretty sure performance is roughly the same. Consider other criteria.
You should pick the language that you know the best and which has the best library support for what you are trying to accomplish (note that Scala can use Java libraries). Haskell is very likely adequate for your needs, if you learn enough to use it efficiently, and the same for Scala. If you don't know the language reasonably well, it can be hard to write high-performance code.
My observation has been that one can write moderately faster and more compact high-performance parallel code in Scala than in Haskell. You can't just use whatever most obviously comes to mind in either language, however, and expect it to be blazing fast.
Scala doesn't have actor-related memory leaks any more except if you use the default actors in a case where either you're CPU-limited so messages get created faster than they're consumed, or you forget to process all your messages. This is a design choice rather than a bug, but can be the wrong design choice for certain types of fault-tolerant applications. Akka overcomes these problems by using a different implementation of actors.
Take a look at the head-to-head comparison. For some problems ghc and java7-server are very close. For equally many, there's a 2x difference, and for only one there's a 5x difference. That problem is k-nucleotide for which the GHC version uses a hand-rolled mutable hashtable since there isn't a good one in the stdlibs. I'd be willing to bet that some of the new datastructures work provides better hashtables than that one now.
In any case, if your problem is more like the first set of problems (pure computation) then there's not a big performance difference and if its more like the second (typically making essential use of mutation) then even with mutation you'll probably notice somewhat of a performance difference.
But again, it really depends on what you're doing. If you're searching over a large data set, you'll tend to be IO bound. If you're optimizing traversal of an immutable structure, haskell will be fine. If you're mutating a complex structure, then you may (depending) pay somewhat more.
Additionally, GHC's lightweight green threads can make certain types of server applications extremely efficient. So if the serving/switching itself would tend to be a bottleneck, then GHC may have the leg up.
Speed is well and good to care about, but the real difference is between using any compiled language and any scripting language. Beyond that, only in certain HPC situations are the sorts of differences we're talking about really going to matter.
The shootout benchmark assumes the same algorithm is used in all implementations. This gives the most advantage to C/C++ (which is the reference implementation in most cases) and languages like it. If you were to use a different approach which suited a different language, this is disqualified.
If you start with a problem which more naturally described in Haskell it will perform best in that language (or one very much like it)
Often when people talk about using concurrency they forget the reason they are doing it is to make the application faster. There are plenty of examples where using multiple threads is not much faster or much much slower. I would start with an efficient single threaded implementation, as profiled/tuned as you can make it and then consider what could be performed concurrently. If its not faster this more than one CPU, don't make it concurrent.
IMHO: Performance is your highest priority (behind correctness), concurrency is only a priority in homework exercise.
Does anyone have any performance benchmarks/experience of using
Haskell vs Scala vs Java for performing highly concurrent tasks?
Your specific solution architecture matters - it matters a lot.
I would say Scala, but then I have been experimenting with Scala so my preference would definitely be Scala. Any how, I have seen quite a few high performance multi-threaded applications written in Java, so I am not sure why this nature of an application would mandate going for FP. I would suggest you write a very small module based on what your application would need in both scala and haskell and measure the performance on your set up. And, may I also add clojure to the mix ? :-) I suspect you may want to stay with java, unless you are looking at benefiting from any other feature of the language you choose.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Java is slow.
That's more than an "urban legend", it seems to be a fact. You don't use it for live-coding because of latency and you don't use it for clusters/parallel computing. There are thousands of benchmarks out there, specially "Java vs C# vs C++".
http://benchmarksgame.alioth.debian.org/
According to the above site, not only is Java performance almost as good as C (far from the rest), but Scala and Clojure (both functional languages which runs on the JVM) both have a better performance that OCaml, Erlang.
And there are a lot of "Java is faster then X" out there, also (for instance, a question here on SO: Java Runtime Performance Vs Native C / C++ Code?).
So Java seems to be fast, for certain cases. Can someone explain why?
Why is it that bytecode might run faster then native code, in some cases, given dynamic code (Scala, Clojure) and garbage collection? How come if it is faster, there is still latency?
It seems to be a contradiction here, can someone shed light?
In the book masterminds for programming, James Gosling explained:
James: Exactly. These days we’re
beating the really good C and C++
compilers pretty much always. When you
go to the dynamic compiler, you get
two advantages when the compiler’s
running right at the last moment. One
is you know exactly what chipset
you’re running on. So many times when
people are compiling a piece of C
code, they have to compile it to run
on kind of the generic x86
architecture. Almost none of the
binaries you get are particularly well
tuned for any of them. You download
the latest copy of Mozilla,and it’ll
run on pretty much any Intel
architecture CPU. There’s pretty much
one Linux binary. It’s pretty generic,
and it’s compiled with GCC, which is
not a very good C compiler.
When HotSpot runs, it knows exactly
what chipset you’re running on. It
knows exactly how the cache works. It
knows exactly how the memory hierarchy
works. It knows exactly how all the
pipeline interlocks work in the CPU.
It knows what instruction set
extensions this chip has got. It
optimizes for precisely what machine
you’re on. Then the other half of it
is that it actually sees the
application as it’s running. It’s able
to have statistics that know which
things are important. It’s able to
inline things that a C compiler could
never do. The kind of stuff that gets
inlined in the Java world is pretty
amazing. Then you tack onto that the
way the storage management works with
the modern garbage collectors. With a
modern garbage collector, storage
allocation is extremely fast.
Fast JVMs use Just-In-Time (JIT) compilation. The bytecode gets translated into native code on the fly at run time. JIT provides many opportunities for optimization. See this Wikipedia article for more info on JIT.
JVM's come in many flavours!
The fastest ones compile byte code to native code on the fly, based on performance characteristics being collected. All this require extra memory, so they buy speed at the cost of memory. Also, top speed takes a while to reach, so the benefit does not show for short-lived programs.
Even so, the JamVM interpreter (which is tiny compared to the Oracle JVM) still reaches a top speed of a reasonable fraction of the compiled JVM's.
Regarding garbage collection, the speed again comes from having plenty of memory available. Also the true benefit come from the removal of responsibility from the code to keep track of when an object is not in use anymore. This result in simpler, less error prone programs.
Well this is an old argument. Almost all prevalent as Emacs and VI.(but definitely not as old). I have seen lot of c++ developers providing lots of arguments on why most of the performance benchmarks (especially mentioning how java is as fast as c++__) is skewed and to be honest they have a point.
I do not have enough knowledge or time to go deeper in to how Java could be as fast as C++, but the following are the reason why it could be...
1- When you ask two very capable developers to write code in Java and C++ for a real world problem (same problem), then I would be surprised if java performs faster than C++. C++ when well written uses a fraction of memory Java will use. ( Java objects are slightly more bloated).
2- Java is inherently meant to be a simpler language and it was written to make sure that sub- optimal code is hard to write. By abstracting memory management and also by handling low level optimization, its easy to write good code in Java than c++. (this I believe is the most important thing.... Its difficult to write bad code in Java).On the flip side a good C++ developer could handle memory management much better than automatic GC in java. ( Java stores everything in heap, so uses more memory... )
3- Java compiler has been improved consistently and ideas like hotspot has proved to be better than marketing term. (when JIT was introduced, it was just a marketing term.. according to me.. :))
4- Ergonomics or tailoring the settings based on the underlying operating system parameters makes java handle variation better. So in some environments, its not hard to imaging Java performing as good as C++.
5- Opening up high level concurrency and parallelism api's for java developers also is a reason. Java concurrency package is arguably the easiest way to write high performance code that could leverage today's multi processor environments.
6- As hardware as become more and more cheaper, developer competency has become a bigger factor and that's why I believe that lots of c++ code in the wild is probably slower than Java.
Java Byte code is much easier to optimize than most native opcode. Because the byte code is restricted, and you can't do some dangerous things, you can optimize more fully. Take pointer aliasing, for instance. http://en.wikipedia.org/wiki/Pointer_aliasing
In c/c++ you can do
char[] somebuffer = getABuffer();
char* ptr = &someBuffer[2];
memcpy(ptr, somebuffer, length);
this makes it difficult to optimize in some cases, because you can't be sure what is referring to what. In Java this kind of thing is not allowed.
in general the code mutations that you can perform on a higher level of abstraction are much more powerful than can be had on object code.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I know embedded C is used for micro-controllers along with other languages. but what if the control was from a PC, well I had two possible candidates (java and c++)
Java is simple and easy also Developer friendly when it comes to threading or GUI, but of course C++ is so much better performance (I know computers getting faster, and performance depend on good Algorithms ) but the compilation makefiles, shared-library and cross compiling wastes lots of time caring about technicalities when I should be working on other Important issues.
But still I've faced something like Const references which java doesn't support and force you to use clone() or copying and when that came to arrays it was a giant mess,
NOTE: I'm going to use reverse kinematics and maybe Neural network for pattern recognition. which requires tons of Calculations. but as I said I care also about the whole life cycle of the project (speed of development, performance , user friendliness and quick deployment)
I'm swinging between languages and i'm planning for long term learning process so I don't want to waste that in the wrong language or let's say (without asking) so please help and I hope this question won't be considered subjective but a reference.
cheers
Why you eliminated C?
Why do you think java has worse performances then c++? Some things are as good as c++, and it is easy to use java program on different platforms without much hassle.
Just pick the language you feel comfortable and you have most experience with, and go with it.
Personally I would lean toward C++. Java has a garbage collector, which can put your app to sleep at random. In C++ I have to collect my own garbage, which gives me an incentive to generate less of it. Also C++ allows macros, which I know have been declared a bad thing by Java-nistas, but I use as a way of shortening the code and making it more like a DSL. Making the code more like a DSL is the main way I shorten development effort and minimize introducing bugs.
I wouldn't assume that Java is inherently slower than either C++ or C. IME slowness (and bigness) comes not from how well they spin cycles, but from the design practices that they encourage you to follow. The nice things they give you, like collection classes, are usually well-built, but that doesn't stop you from over-using them because they are so convenient.
IME, the secret of good performance is to have as little data structure as possible (i.e. minimal garbage), and keep it as normalized as possible. That way, you minimize the need to keep it consistent via message-waves. To the extent the data has to be unnormalized, it is better to be able to tolerate temporary inconsistency, that you periodically patch up, than to try to keep it always consistent through notifications (which OO languages encourage you to do). Unless carefully monitored, those make it extremely easy to introduce performance bugs.
Here's an example of some of these points.
I wouldnt worry too much about performance at first - write the code in whatever language you feel comfortable in and then refactor as necessary.
You can always use something like JNI to call out to c/c++ if needed, although the performance gap between Java and c/c++ is nowhere near what it was...
Depending upon your circumstance, Java is no more quick to deploy than is C++. This mainly boils down to: are you guaranteed the same environment in your testbed that you are in production? With all of the modern additions to C++, there is little cause to suggest that Java is easier on the developer unless you are still new to the C++ language.
That aside, you have performance concerns. Unless it is a real-time system, there's no reason to eliminate any language just yet. If you code your Java intelligently (for instance, do your best to avoid copying objects and creating garbage in the most-used sections), the performance differences won't be seriously noticeable for a compute-bound process.
All told, I think you are focusing too much on textbook definitions of these two languages rather than actual use. You haven't really given any overriding reason to choose one over the other.
Java is a bit more portable, but as far as I know the only real factor for something like this is personal preference.
It would really help if You described Your problem in greater detail.
You are willing to use IK, that might suggest some robotic arm manipulation. What it doesn't say are your real time requirements. If it's going on a class-A production line it'll be hard to get away with garbage collected language.
Java is great. There are some very mature NN libraries (Neuroph, Encog) which could save You a lot of coding time. I don't know of any IK library, but I'm sure there also are at least good matrix manipulation libraries to help.
The Garbage Collection in Java is getting better and better. The latest one (G1) is a lot better than anything else, but even with it the best You can get is soft real time. So You can't expect pause-free run.
On the other hand You also might want to look at some dedicated environments - Matlab toolboxes for robotics and artificial intelligence. I think that would yield fastest prototypes.
If it's going on production than You are pretty much stuck with C or C++.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Are there any tests that compare Javascript's performance with Java's?
UPDATE: Since everyone is asking why the hell this question, here is some context :)
As you all know - I hope - Javascript nowadays doesn't only reside in the web client but also in the web server with node.js.
It could also be run in mobile phones and dekstops with appcelerator and phonegap.
It could also be used substantially in the web browser to make the user experience first class like with desktop applications.
But Java could do these things too, running applets on the web client, and on mobile phones. It's also a language for the backend with many frameworks to choose between.
Since each one of them could almost/entirely replace each other in the mentioned area, I want to know the performance difference between them, for every case I described:
Client: Java Applets vs Javascript
Server: Java EE vs Javascript with Node.js + Express
Mobile phones: Java ME vs Javascript with Phonegap / Appcelerator
Desktop: Java SE vs Javascript with Phonegap / Appcelerator
I hope the context is more clear now.
Java and JavaScript are both programming languages. Programming languages are just a bunch of abstract mathematical rules. Programming languages aren't fast. Or slow. They just are.
The performance of an application has nothing to do with the language. The most important factor is the application architecture. Then comes algorithmic efficiency. Then micro-optimizations. Then comes the quality of the compiler/interpreter. Then the CPU. Maybe a couple of other steps in between. The language, however, doesn't directly play a role. (And of course if you're talking about benchmarks, then also the particular benchmark plays a role, as well as how well implemented the benchmark is, how well run it is, whether the guy who performs the benchmark actually knows something about benchmarking, and even more importantly statistics. Also, the precise definition of what you actually mean by "fast" is pretty important, since it can also have significant influence on the benchmark.)
However, the language might indirectly play a role: it is much easier to find and fix performance bottlenecks in 10 lines of highly expressive, clear, concise, readable, well-factored, isolated, high-level Lisp code, than in 100 lines of tangled, low-level C. (Note that those two languages are only examples. I don't mean to single any one language out.) Twitter, for example, have said that with a less expressive language than Ruby, they wouldn't have been able to make such radical changes to their architecture in such a short amount of time, to fix their scalability problems. And the reason why Node.js is able to provide such good evented I/O performance is because JavaScript's standard library is so crappy. (That way, Node.js has to provide all I/O itself, so they can optimize it for evented I/O from the ground up. Ruby and Python, for example, have evented I/O libraries that work just as well as Node.js and are much more mature ... but, Ruby and Python already have large standard libraries, including I/O libraries, all of which are synchronous and don't play well with evented libraries. JavaScript doesn't have the problem of I/O libraries that don't play well with evented I/O, because JavaScript doesn't have I/O libraries at all.)
But if you really want to compare the two, here's an interesting datapoint for you: HotSpot, which is one of the more popular, and also more performant JVM implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, HotSpot didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
V8, which is one of the more popular, and also more performant JavaScript implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, V8 didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
Given that the two are more or less the same, we can expect similar performance. The only difference is that HotSpot has over a hundred engineers working on it for 15 years, whereas V8 has a dozen engineers working for less than 5 years. That is the only difference in performance. It's not about static vs. dynamic typing (Java is statically typed, but most JVMs and certainly HotSpot make no static optimizations whatsoever, all optimizations are purely dynamic), compilation vs. interpretation (HotSpot is actually interpreted with an additional JIT compiler, whereas V8 is purely compiled), high-level vs. low-level. It is purely about money.
But I am going to bet that for every pair of Java and JavaScript implementations where the Java implementation is faster, I can find another pair where the JavaScript implementation is faster. Also, I can probably keep the pair and just use a different benchmark. There's a reason the call the Computer Languages Benchmark Game a "game": they even encourage you right on their own page to play around with the benchmarks to make any arbitrary language rise to the top.
I only have an anecdote to add: I've recently reimplemented a Java calc server (finance) in Javascript (nodejs v0.6.8). WRT development time, the Javascript implementation was a breeze compared to the original Java implementation with far fewer lines of code. It was a breath of fresh air, really.
The Javascript-based server is able to calc through 2.4k trades/sec whereas the Java server handles 400+/sec on the same hardware using less memory. I wouldn't attribute the speed increase to raw V8 vs. Java 7 performance but rather to the implementation. The Javascript implementation uses far fewer data structures, does an order of magnitude fewer method calls and takes a more straight-forward and terse approach.
Needless to say, I'm very happy with the performance of node.js. And this, coming from someone who was Java only for many (9) years.
Here are some tests comparing Javascript (V8) and compiled Java:
32 bit
64 bit
They indicate that Java is generally faster1. However, if you dig around with those pages and the linked resources, you will notice that it is very difficult to compare like with like.
Interestingly, Javascript does significantly better than Java (under certain conditions) for the "regex-dna" benchmark. My guess is that this is because the Javascript regex engine is faster than the Java regex engine. This is not entirely unsurprising, given the importance of regexes in typical Javascript applications.
1 - Strictly speaking, you cannot say that language X is faster than language Y. You can only compare specific implementations of the respective languages. And the site I linked to is clear about that ... if you care to go in via the front page. However it is not entirely unreasonable to generalize from specific datapoints ... and the apparent of absence of contradictory datapoints ... that Java is typically faster than Javascript in computationally intensive tasks. But the flip side is that that kind of performance is often not an objectively important criterion.
Java, obviously.
Programmers love to compare execution speed like some sort of pissing content. It is just one metric, and the majority of the time, not the most important one by a long shot. Java is a language that has a mix of being fast enough for almost anything, but high enough level that you get stuff like GC, which you don't usually get in similar languages. Javascript is a dynamic closure language that is great for getting stuff done quickly (and for FP programmers stuck in an OO world ;-) ). There isn't much in the way of intersection in the spaces where either would be appropriate.
I'll stop pontificating now
EDIT: to address the edit in the post
Due to the way one writes idiomatic javascript (functions composed of functions), it lends itself surprisingly well to asynchronous programming, probably better then any other language of similar popularity. Node.js shines when it comes to a huge amount of short connections, so javascript is a really great fit for that sort of thing.
While node.js is absolutely drenched in awesome, being the new hotness really doesn't mean it is the best at everything, no matter what the hype says. If a java app is replaceable by node, chances are java wasn't really appropriate in the first place.
Probably not, but it doesn't really matter.
Prior to Google Chrome's JavaScript JIT, Java would win over JavaScript as soon as the problem got big enough to overcome the load time.
Java should still roundly trounce JavaScript due to integer vs. float math. No matter how good the JIT it can't really make up for this.
WebAssembly will turn this on its head anyway.
http://benchmarksgame.alioth.debian.org/u64q/javascript.html
(Remember to look at the cpu column as-well-as elapsed secs).
According to the above link JavaScript as reality stands now is much slower for almost everything.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Which language is faster for web, Java or PHP?
It is a difficult one to answer as in theory Java should be faster:
it's precompiled, any trivial algorithim will run faster in Java than PHP and there has been a vast amount of work done to optimise Java from improving the code, standard libraries, to JIT compilers, etc.
PHP is loaded and interpreted every time if you're not using the Zend optimiser, objects are intialised on every execution, even the most trivial string varaible is actually a complex object with many methods to support.
The problem is that in practice PHP sites seem to run faster using fewer resources.
I think this is because PHP developers take a more straightforward approach to design and don't get lost trying to implement exotic design patterns and implementing endless pointless abstractions.
Speed doesn't matter
in most cases.
Processing is cheap. Code in what you're comfortable with. Writing proper code goes much further for speed then choosing a language. Solid coding conventions and design plan will also help more.
Best answer I could find
"stuff to consider:
Java web applications are compiled
to bytecode. Even JSPs, which are
compiled at runtime. This is an
advantage over most uses of PHP,
where the Zend Optimizer is not in
use.
Data can be cached in a live servlet
instance - no direct/easy way of
doing this in PHP to my knowledge
(there is only ever a single
instance of a servlet/JSP in memory)
If anybody knows how to cache data in PHP without resorting to ugly
hacks, please enlighten me!
Java applications tend to be
n-tiered, which generally results in
a more maintainable application at a
slight performance penalty. This
probably sounds trollish, but
honestly: even within Java itself
direct use of JDBC will always be
faster than going through three
layers of objects to the database.
But is an n-tiered Java application able to hit the database sooner than an uncompiled, hacked-up monolithic PHP script? I don't think there's an answer to that question.
All that said, I'm working on an n-tiered MVC framework for php 5 (it's called Pure (http://www.sf.net/projects/php-pure)), so my PHP applications are generally n-tiered too. I'll worry about speed when and if it becomes an issue. For now, it's definitely not an issue."
courtesy of krumms
Speed aside, I believe the performance of Java is better than PHP. But developing a project in PHP is faster.
Can't answer this question with one or the other unless you define what you want to measure the speed of.
Some things are much faster in PHP (in a native function for example), other things are much faster in Java.
The intent of each language is substantially different from the other, so if you're debating over which to use for a particular task, you should generally based the decision on that task (and how well suited each language is to it) rather than performance.
For raw performance of code written in the language (as opposed to simply calling code in the standard library), Java will probably run faster than PHP as an extremely general rule. If that matters, chances are that PHP just isn't very well suited to the task at hand.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I am a beginner to Ruby. I've heard the following complaints about Ruby, and was hoping the Stack Overflow community could address each point raised.
Common complaints about Ruby that I've heard:
Ruby is slower than Java
Ruby is not statically typed
It's not suitable for large projects
Given these admittedly opinion based statements, how is Ruby 'better' than Java? and will Ruby ever be a widely used language both by businesses and individuals?
Ruby is slower than Java to run but faster to write, or read. Which is more important to you? I don't know any company in the world who'd pass if given the opportunity to (say) cut their dev time in half at the cost of doubling their hardware.
Ruby is not statically typed, but neither are Python, Perl, Lisp, shell scripts, etc. Is this really a problem for you? I'm sure you could find just as many people in dynamic languages who would complain that Java, C#, C++, etc., are statically typed. We've no lack of examples of systems built on dynamic languages.
I'll agree that Ruby isn't suitable for large projects, but neither is any other language we have today. The state of software engineering is pretty clear to me: nobody can reliably build large systems well. At least Ruby makes your large projects smaller in lines-of-code, which makes them (somewhat) more manageable. It's syntactically richer so you can say (something closer to) what you mean. It's faster to write so you'll find out quicker if you're going down the right path or not.
If these are the best arguments against Ruby, then Ruby is doing better than I'd thought.
Ruby's speed has greatly increased in the latest version. Though in older versions Ruby is slower than other scripting languages.
For some purposes, Ruby is too slow in operation. For others, it's fast enough.
For some purposes, Java takes too long to develop.
For some applications, static typing is unnecessary, for others it's highly desirable.
The size of the project is largely irrelevant.
In some ways, Java is better than Ruby, in other ways Ruby is better than Java. Anyone who maintains that one is "better" in any circumstance probably doesn't know enough about either to hold a valid opinion.
And what about JRuby?
I think it's fairly well-documented by now that Ruby is "popular". Not as "popular" as Java, C++ or C, for example, but popular nonetheless.
See
http://www.langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
The answer to the question "which language is better, this or that?" is always subjective. Sure, objectivity is valid and you can somehow reach a conclusion about a language being better for X task/project.
However, even then, if your team is happy with some other language that is not the first choice for a certain task/project, but the work can be done anyway... a wise team will choose the language that makes them happy because their productivity will also be greater.
Concluding, no one can tell you his choice is better than your choice. They can try to persuade you, but if for some reason X language makes you more excited, they cannot do anything about it.
Having said that: Ruby 1.9+ has improved a lot as far as performance is concerned. If you ask me, my biased opinion is choose Ruby because I like it. But if you wanted an unbiased opinion, we would have to discuss more aspects and examine what exactly you want to do with the language/framework etc.
I advise you to try both languages and then decide which you think is best.
Ruby is a popular language already :)
I don't agree with you on "We should always think about the performance" and "ruby is better than java". On some project, code readability may be more important than performance. Think of optimized C++ code which no one can read and maintain for example. And there is no perfect proof that "Ruby is better than Java". Where did you take that information ?
how is Ruby 'better' than Java?
It's not, and Java isn't 'better' than Ruby. Both have their pros and cons, and it depends on your project; what is the best tool for that job.
Depending on what you need to do.
We expect our code to run for decades. Staying with pure Java means that we are pretty certain that the technologies will stay "in fashion" and that future colleagues can maintain the code. Going for the language of the day, will eventually mean that you will have programs written in languages which have gone out of fashion and therefore is more difficult to maintain.
"Pure java" basically means we are staying with the standard Java Runtime, and implementations of Sun specifications (like JavaServer Faces). It is not as boring as it sounds :)