Hacker News Reader

Comment by yesimahuman | Hacker News Reader

Born again Java fan here. I took a diversion into languages like Python (which I still heavily use), but now I wish I had just used Java in the first place. Once you turn a program from a 2 hour long run-time down to < 10 minutes (my Lucene vs PyLucene experience), you don't really see the benefit of using Python anymore. Plus I've realized that I prefer static typing.

View on HN

Speed is a bad reason to choose Java or other less expressive languages. There are many more expressive languages with speed comparable to Java, including but not limited to Haskell, Common Lisp, Scheme, Clojure, Scala and several ML variants. Some of these run on the JVM and some offer static typing. It looks as though Psyco and LuaJIT compare well to Java in microbenchmarks as well.

>* including but not limited to Haskell, Common Lisp, Scheme, Clojure, Scala and several ML variants *

Any non-FP languages?

Most languages that I would designate as "expressive" allow FP, but not all require it. Common Lisp isn't very functional; it doesn't even do tail-call elimination by default. It's idiomatic to use a fairly imperative style in CL. Scala allows FP, but also has OO that's fairly similar to Java with less boilerplate. Lua allows FP, but an imperative style is idiomatic (it doesn't even have map/reduce/filter built-in).

Edit: BigForth is an implementation of Forth that seems to be pretty close to Java in speed. Forth is not a functional language. D is a fast language intended as a C++ replacement. Despite looking a bit like C++ or Java, it can be quite a bit more terse than either. D 2.0 adds quite a bit of FP support to make concurrency and parallelism easier, but you can still write C in D if you so choose.

I was not aware that D and Lua had the JVM as targets.

You only asked for non-FP languages, not non-FP languages with the JVM as a target. There's a Lua implementation for the JVM called kahlua. It appears to be in a fairly early stage of development and may not be fast or suitable for production use. As far as I know, there is not a D compiler for the JVM.

Groovy appears to be potentially as fast as Java. It can call Java easily, which means you always have the option to rewrite something that's too slow in Java itself.

Thanks again. Apologies if my terseness meant a loss in clarity. I thought the JVM was implicit in the thread and that you were listing languages with the JVM as targets (also my mistake as I see that you were not exclusively listing those, guess I should refrain from posting till I've had more sleep).

I usually throw the search engine up as a rest service, and keep the web app in ruby on rails. Best of both worlds.

The benefits of dynamic languages are not their speed, its the rapid prototyping and interactivity they provide once the prototype has been designed it can be implemented for speed in any lanuage providing the features you need.

Well, then I disagree that after two years of really using Python for everything, that I've been much more productive than with Java. I bet I spent a good chunk of that time debugging errors at run time which would have been caught at compile time with Java.

Of course that is a non-scientific anecdote and there are times that the REPL is just awesome (especially for web app development).

This has been my experience too. Currently I like Python for quickly banging out web apps, and Java for building the back end stuff.

Sure, Java has some baggage, but it has a lot of benefits too, such as much better tools for deployment, performance profiling, libraries galore, the JVM, and more. I find it's often the best tool for the job when there's heavy lifting to be done.

I guess this is the reason why Scala gets a lot of attention: same speed as Java (on JVM), fully compatible with Java, it has static typing, and it's productive like RoR or Python.

BTW, both the Java (javac) and Scala compilers were written by the same person.

I have not read where Scala is the same speed, citation?

its not real "proof", but check out the Computer Language Benchmarks Game: http://shootout.alioth.debian.org/

So if that isn't 'real "proof"' what would be 'real "proof"' ?

Implementation + problem specific.

Languages aren't fast, code + data + implementation combinations are.

The language and its implementation will limit the efficiency of the end-result (the running code).

The current Google Go compiler implementation produces slow code, but there's a potential to make it as fast as C. The JavaScript implementation can be made better, but it will never be close to C.

Scala running on JVM will produce similar efficiency to Java. On multicore the Scala compiler will likely produce a faster code by default, but that advantage can be matched in Java with extra work.

Scala running on .NET will likely perform similar to C#.

Now it's up to the developer to create efficient source code for the given language. It is possible to write slower code in C than in JavaScript, but the focus should be on "normally".

Normally Scala gives you the same end-result with less work than Java. There are exceptions.

More: http://www.scala-lang.org/node/25 (Look for "Scala Compiler Performance")

An older measurement: http://fupeg.blogspot.com/2008/06/scala-vs-java-performance....

You seem to have encrypted your comment - please decrypt so we can understand and evaluate the point you wish to make.

Scala is as fast as Java because similar code in both languages compile to the exact same bytecode.

With type specialization in Scala 2.8 it will be even faster than Java in some cases.

Reply on news.ycombinator.com