Re:Apache loses Java showdown vote to Oracle
by dkarl on Tuesday December 07, 2010 @05:13AM
(#1978595)
C is another Blub, so you aren't contradicting my point, but I would say that the reason C isn't a good replacement for Java is that C has no support for garbage collection. C and Java both have a large amount of valuable, working code that programmers can utilize from other languages, but a language written on top of C has to accept that whenever a C library is used, someone must deal with C memory management, either the programmer who writes the bindings or every programmer who calls the bindings. They may have to deallocate memory and they may have to reason about the lifetime of memory deallocated by library code. Scala programmers can call Java code with no such worries. If they wrap a Java API in a Scala API, it is only for style and convenience. A Scala programmer would not use a C library lightly, certainly not without bindings that ensured memory safety, and writing such bindings would require a lot of care.
The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code.
Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance.
P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.
The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code.
Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance.
P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.