Barrapunto

• ¿Recolección de basura automática?

  También están disponibles en C++ recolectores tipo mark & sweep como el de Java, pero nadie los usa porque es mucho más eficiente gestionar la memoria en la pila, o usar conteo de referencias para la memoria reservada en el heap.

• ¿Código seguro que no da cores ni fallos de segmentación?

  Qué mas da que el programa salga por un fallo de segmentación, que salga por una excepción no capturada tipo java.lang.NullPointerException o java.lang.IndexOutOfBoundException. Bueno, la verdad es que con un core puedes usar el depurador y examinar todo el proceso. En java y en c# te tienes que conformar con la traza de llamadas. Los programas en C# petan y salen con excepciones igual que el resto de los programas. No hay magia, si el programa está mal el runtime no puede hacer nada por corregirlo. Cuando Java chequea el límite de un array o si un puntero es nulo, está replicando el trabajo de algo que ya hace el sistema operativo, y que además lo hace por hardware usando la MMU del micro.

• ¿Velocidad?.

  Venga ya, todos lo hemos visto. Pero en cualquier caso, todos los lenguajes una vez compilados son prácticamente igual de rápidos, la diferencia está en las optimizaciones que sea capaz de hacer cada compilador, no en el lenguaje en sí. Las máquinas virtuales de Java y Mono están escritas en C, por algo será.

Lo único que no tiene discusión es la portabilidad. Pero entonces, ¿para qué C# si sólo funciona en Windows y a medias en Linux?.

Pero bueno, tampoco quiero provocar un flamewar, que cada cual use el lenguaje que quiera, pero hoy por hoy las estadísticas de sourceforge son aplastantes, el rey siguie siendo el C, con C++ comiéndole terreno progresivamente.

Lo único que quiero es que la gente reconsidere el C++ ahora que hay un estándar, pero usándolo bien, con la STL, con smart pointers, y con namespaces, porque el C++ estándar es el gran desconocido de la gente que ha estado usando C++ durante 10 años sin un estándar, y que creen conocer un lenguaje que en realidad ha cambiado mucho.

• Recolección de basura: Hace tiempo que se sabe que, en programas no triviales, un buen recolector de basura es MÁS eficiente que gestionar la memoria "manualmente" mediante refcounting o similares.
  
  
  
  • Se evita el tener que manipular contadores de referencias.
  
  
  • En los momentos en que sobra memoria no se pierde tiempo liberando memoria. Se pueden ajustar los momentos en que salta el recolector para optimizar el tiempo de respuesta.
  
  
  • Y, sobre todo, todo el código de gestión de la memoria está concentrado en unas pocas líneas y esto es mucho mejor de cara a la caché.
  
  Todo esto hace que en la actualidad no tenga mucho sentido gestionar la memoria "a mano" salvo en aplicaciones de tiempo real, e incluso hay trabajos que pretenden acabar con este último feudo de los mallocs/frees.
  
  
  • Sobre el chequeo de límites y de referencias nulas: En la práctica, esto no provoca deterioro en el rendimiento, porque la mayoría de las veces estos chequeos son eliminados por el compilador al ver que no son necesarios. Por ejemplo, en un bucle for que recorre un array, lo más normal es que los chequeos simplemente no se hagan. Sólo se harán en situaciones donde el resultado sea impredecible en tiempo de compilación (dinámica), con lo cual tenemos las ventajas obvias de seguridad y los inconvenientes simplemente no se notan.
  
  
  
  • En velocidad, hace tiempo que Java supera sobradamente a C++, principalmente debido a las ventajas de la compilación dinámica (JIT, Hotspot...) que permite hacer optimizaciones con mucho más conocimiento que las que hace un compilador de C++. (Véase por ejemplo http://www.kano.net/javabench/). Y encima todas estas ventajas todavía no están explotadas de todo, queda mucho más por hacer que hará que Java sea *significativamente* más rápido que cualquier lenguaje estáticamente compilado en el futuro, ya que en éstos hay menos campo de trabajo al tener menos información en el momento en que compilamos.
  
  
  En resumen, ahora mismo no hay muchos motivos para elegir un lenguaje tipo C/C++ sobre uno tipo Java, salvo si (1) estamos haciendo el kernel de un sistema operativo, (2) trabajamos contra código legacy, (3) queremos presentar un ejecutable pequeñito y nos fastidia tener que distribuir u obligar a bajar la JVM, o (4) simplemente nos gusta más/tenemos más experiencia en ese lenguaje.
  
  La velocidad, desde luego, ha dejado de ser un motivo. Vivan las VM's.

Hombre, para empezar me gustaria destacar que Icaza no defendió en ningún momento C# ni ningún otro lenguaje, precisamente Mono (bueno, y .NET) se hizo con el objetivo de poder desarrollar APIs en cualquier lenguaje y utilizarlas desde cualquier otro lenguaje, con lo cual permite usar el más apropiado para cada tipo de problema(o el que mejor se te dé).

Respondiendo más directamente a tus puntos, creo que: