Java, en general, es excelente. En especial desde la version 7. Es MUY rapido ahora - osea, como maquina virtual y en comparacion con otras maquinas de su rango, pero no para GUIs o apps intensivas numericas-.
"controlar los dispositivos, tipo puerto serie, sockets tcp/ip" es algo que se puede en casi todo. No para drivers de bajo nivel o que esten en el kernel.
Un problema de mucha gente, que no ha trabajado en diversos lenguajes/entornos es que tienen una vision limitada de que significa "rapido" "desempeño" y cosas por el estilo.
Una maquina virtual (VM) en muchas ocasiones hace codigo mas rapido y/o eficiente (rapido<>eficiente) que el que manualmente hace un programador promedio en un lenguaje como C/C++, porque tiene acceso a mas informacion sobre el entorno/tipos de datos/heuristica/patrones de acceso/etc y por ende, puede habilitar formas mas eficaces de operar.
Si buscan "python/ruby/php/haskell/java/lua" faster than C/C++ veran que encontraran muchos ejemplos. Haskell es uno que particularmente vence a muchos programas en C/C++:
http://paulspontifications.blogspot....er-than-c.html
(Noten, que es posible hacer el codigo C MAS rapido. Pero eso requiere un programador MAS experto, mientras que una engine como esta NO).
Un ejemplo radical es
http://luajit.org/. El java VM es considerado *hoy* como una maquina muy eficiente. La de .NET no esta para nada mal, y honestamente, desde la version 4 .NET ha dejado de ser una "burda" imitacion a Java (y en algunos aspectos, mejor que Java 7).
Esto se entiende en el momento que uno piensa como hacer un lenguaje de programacion. Y cuando se aprende que hace o no rapido ciertas cosas:
https://speakerdeck.com/alex/why-pyt...cript-are-slow
Hagan de cuenta que un VM/Runtime es como hacer un programa de facturacion: Automatiza procesos manuales que hace el usuario, en este caso, el usuario es el programador!
Asi que, es mas probable que el programador "promedio" realmente escriba codigo terrible. Es algo que se ve todo el tiempo.
Por ejemplo, una de las razones por las cuales los programas de contabilidad "se mantienen" en desempeño no es porque esten muy bien programado (cosa que muchos aqui atestiguamos) sino que el *engine de base de datos* "cubre" los problemas debido a que es un runtime/VM muy eficaz, que incluso en motores como sql server o postgres (y otros) hace analisis especializes que re-escriben las consultas en base a los planes de ejecucion.
Si aceptamos que un motor de BD es rapido, tenemos que aceptar lo mismo de otras VM. Porque una BD:
1- No tiene manejo manual de memoria
2- No permite hacer nada a bajo nivel
3- Y maneja un tipo de programacion (declarativa) que *facilita* las optimizaciones programaticas... este punto tiene ventaja contra los lenguajes procedurales donde es mas facil embarrarla
El grado de cada runtime/VM en cuanto a lo eficiente varia entre uno y otro, pero es una falsedad creer que porque
tiene runtime, es
lento. Recuerdo que en su epoca, Foxpro es lo mas rapido que habia. Rapido, si hablabamos de base de datos. Y en foxpro no se hacia nada a "bajo nivel" pero barria con todo. TODO, era increible.
El problema de Java/.NET no es su VM en si, sino la GUI. En esa area son fatales. Es donde se nota la "lentitud". Son un bodrio. Es su punto debil.
Tambien, y esa es la razon ppal porque la que, aunque reconozco las ventajas de java, no me gusta ni programaria en eso, es porque la cultura, idiosincracia, librerias, comunidad y forma de trabajar en si es muy "burocratica". Con .NET es igual. No me parecen que sean una eleccion buena para equipos de trabajo pequeños y/o individuos.
Para estos, lenguajes como python, ruby, php, foxpro, delphi tienen la ventaja. No es tanto porque sean "rapidos" (me consta lo lento de ciertas apps hechas en delphi para contabilidad) sino mas bien que tiene un diseño que es mas acorde a la forma de trabajar de los que no somos una empresa grande.
Osea, y esto es importante, la forma de "pensar" de un programador de Java conlleva a que terminen haciendo cosas "lentas". Mucha vuelta, mucho uso de XML y cosas que son lentisimas, mientras que uno aprende en otros lenguajes a hacer cosas mas simples y directas.
La forma de pensar y de hacer las librerias tiene un efecto inmenso en el desempeño total de un sistema.
Pero, por ejemplo, si uno coje .NET/Java y desecha la forma de trabajar burocratica y toma una ruta mas agil, con librerias acordes, la cosa cambia mucho.
Un ejemplo en java es lo que hacen con
http://clojure.org/. La gente que coje clojure es del
mismo tipo de los que usan python/ruby: Equipos agiles, pequeños, startups. Gente que NO elige "java el lenguaje con sus vainas enterprise" pero que no les importa usar "java, el runtime muy eficiente" pero con una comunidad que es agil y un lenguaje acorde.
Obviamente, hay cosas, como manejo de numeros y asuntos de bajo nivel donde C/Pascal tienen ventaja. Basicamente, no por su lenguaje, sino porque estan hechos para esas labores, y sus librerias trabajan en conjunto.
UN ejemplo de contraste, con python -que es lento numericamente- es cuando se junta con
http://www.numpy.org/ y de pronto, resulta tan o mas rapido que si esos calculos estuvieran hechos en C.
Osea, el uso de estructuras de datos y algoritmos hace la gran diferencia, mas que los lenguajes.
(Aunque al final, las VM estan hechas en C o similar, asi que....)