> So your argument as such says nothing about JVM jon-bot: yes it does, look at those numbers here: ... goswin-bot: no it doesn't because: ... startup time ... hotspot ... server ... jon-bot: moron goswin-bot: liar
So far the typical java-shootout pattern. Maybe another approach would be to compare the JVM and the CLR in the realworld. I think it's interesting that on the ms-windows platform .net is used for everything with great success: - desktop apps (mostly .net: windows forms, wpf / c++ is dying) - web apps (mostly .net: asp.net / asp and com are dead) - backend services (c++ and .net apis: sharepoint, ... / dcom is dying) Compared to that I think the jvm is only succesful when it comes to 'backend services', which often play an important role in big and often technically conservative companies. There are (great) desktop and web apps in java but they require much more expertise then the clr equivalent, they are fewer and often more expensive. That means on the linux platform we have the following situation: - desktop apps (highly fragmented/diversified) - web apps (highly fragmented/diversified) - backend services (c++ and jvm) I think it's safe to say that on the linux platform we have NOTHING COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't java doesn't fill this gap? My guess is that: For desktop and also web apps startup time, memory usage and ease of deployment are too important that most developers are happy with the compromises that the jvm offers. So they do : - use php, ruby, perl, python even for huge applications (without typechecking at compiletime) - write all sorts of extensions in c to speed up: XS, cython, ... (yuck) - write all sorts of bindings to c libraries: PyGtk, ... (yuck) With the result of fragile desktop apps and bad scaling web apps and the consequence that we use a lot of time of hack around those problems. I think something like the clr would be a huge progress first and foremost for the linux programmers. Maybe Ocaml could play an important role of providing a slick api, because of its strength when it comes to language implementation (compilers), so we would have: gil ( gnu intermediate language, a bytecode ) gilrt ( gnu intermediate language runtime, a jit based vm) - the gilrt written in c or c++ - an Ocaml binding to the gilrt - different language implementations gPython, gRuby, gC, gJava (Language to gil compilers written in Ocaml) Or maybe that's just crazy talk ... ben - On Fri, May 14, 2010 at 5:17 PM, Goswin von Brederlow <goswin-...@web.de> wrote: > Jon Harrop <jonathandeanhar...@googlemail.com> writes: > >> Xavier Clerc wrote: >>> Limiting myself to the JVM... >>> Moreover, at least Scala and Bigloo deliver excellent performances. >> >> I have benchmarks where the JVM is well over 10x slower than .NET. So I do >> not regard any JVM-based language as "high performance". >> >> Cheers, >> Jon. > > You can pretty much write a benchmark for any 2 languages that > specifically targets the weekness of one and the strength of the other > showing that one is better than the other by a wide margin. You can > usualy reverse the argument with a different benchmark. > > So your argument as such says nothing about JVM, just something about > your benchmarks. > > MfG > Goswin > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
