#18 argumento falaz no, ¿si realmente C++ fuera tan malo como dice este artículo como es posible que sea un lenguaje elegido para motores de bases de datos, navegadores web, sistemas operativos, máquinas virtuales, videojuegos, motores gráficos...? Según la teoría de este artículo todo eso debería cambiar a todos los lenguajes que dice que son mejores que c++... pero a la hora de la verdad parece que el rendimiento de C++ es mucho más potente de lo que dice en el articulo... ya sólo decir que en C++ no hay concurrencia y que esta pensado para monothreading... si ya hasta el STL de c++11 en adelante existe el std::thread y std::mutex...
El artículo es de alguien que no tiene ni idea de C++... si según el artículo es tan malo no se como se usa en todas las aplicaciones básicas y donde se requiere potencia y eficiencia desde sistemas operativos, videojuegos, motores de bases de datos, navegadores web, etc...
Me pregunto cuál es su solución tan novedosa para reemplazar las excepciones...
Nowadays there are much better mechanisms of error handling. Possible errors should be type-checked at compile-time. Languages that do not use exceptions by default will be ranked higher.
#16 Utilizar las excepciones como flujo de control de errores deja de ser excepcional.
Mi preferencia por los "Códigos de error" frente a las excepciones se basa las siguientes premisas:
- Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
- Las excepciones rompen la estructura del código al crear múltiples puntos de salida invisibles que dificultan la auditoría.
- Si no se dispone de recolector de basura con las excepciones es fácil producir "fuga" de recursos, especialmente si el lenguaje no tiene "comodines" para utilizarlos en todas las salidas del bloque. Ejemplo de asegurar una ejecución en todas las salidas en golang: https://www.digitalocean.com/community/tutorials/understanding-defer-in-go-es
- Las excepciones utilizan generalmente mas recursos que los "códigos de error". https://trinket.io/python3/671103b72b https://gist.github.com/mattwarren/e3cdd278ba9c2cad03cc6b53ce6d47f6
Las excepciones tienen ventajas y en ciertos lenguajes son el único mecanismo para controlar los errores, como reportar errores a constructores. No es el caso de rust o golang. El tratamiento de errores en rust es desde mi punto de vista de lo mejor para realizar código seguro.
Una ventaja de las excepciones es que son ideales para crear código inseguro que ignore muchos errores.
#21Utilizar las excepciones como flujo de control de errores deja de ser excepciona
Ese argumento es bueno.... . Si les llamamos "avisos" deja de existir ese "problema". Habrá que proponer un cambio de nombre....
Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
FALSO. Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el compilador te OBLIGA a que hagas algo al respecto y no te permite dejar el resultado de la llamada "a lo que salga", como ocurre con los códigos de error. Por otra parte el tratamiento de errores es muchísimo más sencillo y el código producido mucho más claro y legible.
Las excepciones rompen la estructura del código al crear múltiples puntos de salida invisibles que dificultan la auditoría.
También lo hace un tratamiento de errores con códigos de error. Si un método o función te devuelven -1 indicando que funcionó de pena y todo se puede ir al garete.... qué haces en la instrucción siguiente ? Los puntos de salida no son "invisibles". O resuelves el problema si es asunto de tu método o la relanzas al llamante si debe ocuparse él. Simple y limpio.
Si no se dispone de recolector de basura con las excepciones es fácil producir "fuga" de recursos, especialmente si el lenguaje no tiene "comodines" para utilizarlos en todas las salidas del bloque. Ejemplo de asegurar una ejecución en todas las salidas en golang: www.digitalocean.com/community/tutorials/understanding-defer-in-go-es
#23Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el compilador te OBLIGA a que hagas algo al respecto y no te permite dejar el resultado de la llamada "a lo que salga", como ocurre con los códigos de error.
====== test.cpp ==== #include
#include
using namespace std;
No soy experto en C++, pero en Java a no ser que sea una unchecked exception estas obligado a tratarla, de un modo u otro.
Si el C++ no lo hace el problema no es de la gestión de errores mediante excepciones. Por cierto, si gestionas el error con códigos de retorno el problema es el mismo
#25 Como dije, no uso C++, pero parece ser que precisamente los streams no lanzan excepciones y es necesario gestionar los errores mediante el valor de retorno...
#33
Hombre esa comparativa dice que Go viene usando el doble de RAM en prácticamente todas las pruebas... incluso hay una que usa un 5 veces más....
¿No es en la columna que pone "mem" ?
Y en cuanto a velocidad de ejecución bastante más lento. En reparto de trabajo entre CPU si que están parejos... esperaba mucho más de Go en eso.
Me dan exactamente igual las opiniones de Linux Torvalds. ¿Eres capaz de razonar por qué es mejor el tratamiento de errores con valores de retorno en lugar de con excepciones es "mejor"?. Torvalds es de mucho de quejarse, aunque finalmente tenga que reconocer que "es lo mejor que tenemos, pero aún así es una mierda" (frase que me acabo de inventar, por supuesto, pero no me extrañaría que estuviera cerca de la realidad).
#29 Todo depende de los entornos de los que estemos hablando. Cada cosa tiene su nicho.
Los contenedores no se usan "para paliar los problemas de dependencias", tienen otras enormes ventajas mucho más allá de eso, y desde luego tienen muchos menos problemas de seguridad que una aplicación monolítica ejecutada en el propio sistema.
Y otra vez estamos hablando del tiempo que ahorra el desarrollador frente a la calidad y velocidad del sistema desarrollado en explotación. Da igual que tarde 5 minutos que 20 si se hace de modo automático. Lo realmente importante es el rendimiento y requerimientos de la aplicación final. Y de todos formas estamos hablando de entornos de compilación, no de caracterísiticas del lenguaje, que es de lo que iba el tema.
Desconozco completamente Go, pero lo que expone la comparativa en numerosos apartados está profundamente equivocado (como el tema de las excepciones, por ejemplo).
Me ha gustado el artículo, aunque difiero en muchas cosas .....
No veo ningún inconveniente a la gestión de errores con excepciones, por ejemplo. Me parece un gran avance.
Tampoco veo ventajas en los objetos inmutables en aplicaciones "normales" que superen los inconvenientes.
Valorar la velocidad de compilación igual que la de ejecución me.parece directamente una idiotez.
#38 Pues depende lo que se quiera gastar en hardware y de la tarea a realizar.
Que no se me entienda mal. No estoy criticando a Go, seguro que es un gran lenguaje y tiene su nicho, como todos. Pero algunas razones para poner unos lenguajes por encima de otros del artículo me parecen profundamente equivicadas.
Go sera un gran lenguaje. Pero prefiero un Kernel de Linux en C.
#24 Ciertamente estoy un 2% mas cerca de los 100MB que usted.
Esta claro que usted enlaza en "dinámico". Las ventajas del estático en mi caso es un despliegue muy sencillo y carente de contratiempo.
Por ejemplo, un aplicativo con servidor http/s, tls, cliente postgresql, plantillas html, traducciones, validaciones de formularios, etc se queda el binario en 16 MB. La compilación de todo tarda 2 segundos y los únicos requisitos de este binario para funcionar son: https://github.com/golang/go/wiki/MinimumRequirements
#27 La unica ventaja del enlace estatico es la no dependencia de librerías externas. Y tiene muchos inconvenientes, como el parcheo de bugs o el uso de RAM.
#28 Usted conoce como son los usos modernos, para paliar los problemas de las dependencias en los despliegues se utilizan contenedores que tienen los mismos o mayores problemas de mantenimiento y seguridad.
Con Go actualizar todas las dependencias y generar un nuevo binario puede llevarte entre 2 y 5 minutos en proyectos grandes (siempre utilizando librerías nativas en GO, no enlazando a librerías C), un tiempo similar a actualizar las librerías de todo el sistema si hablamos de "Como Unix".
Pocos proyectos de entidad en java tendrán un proceso de actualización de dependencias y/o generación de binarios tan rápido.
La compilación cruzada no esta totalmente disponible desde todos los orígenes a todos los destinos. Por ejemplo para darwin solo es posible desde darwin, ya sabes usted como las gastan los manzanos.
#30 Estas comparando un lenguaje de máquina virtual contra un lenguaje compilado. No es una comparación justa. Si comparas con lenguajes "de su segmento" como C/C++ te encontrarás con un uso de RAM muy superior a veces más del 100% superior.
#35 Dudo que pueda dejarlo en 1kb como estático. Eso solo lo creo posible en asm y utilizando solo llamadas al kernel.
Deben ser proyectos con muchas librerías incluidas o una cantidad importante de símbolos.
Es el precio a pagar por disminuir las dependencias. ¿Pero eso influye en el rendimiento?
#37 Sería increíble que con el recolector y el "runtime" ocupara menos el binario de Go.
Las realidades que no le voy a discutir son:
Compilación rápida != optimización extrema
Recursos con recolector > recursos sin recolector
Tamaño binario estático > tamaño binario dinámico
Pero lo interesante creo que es:
¿afecta negativamente el tamaño del binario en sus proyectos al rendimiento, a las funcionalidades?
¿son tamaños inasumibles?
Why is C++ so bad? In my opinion, the biggest reason is its age. C++ was designed long ago, in 1979. At that time the designers lacked experience and had no idea what to focus on. Ahi dejé de leer
Creo que estamos ante el típico programador al que solo le importa su tiempo, y no el de sus usuarios. Decir que C++ es lento, o que el “startup time” de Go, con sus binarios de 100MB, su modelo de inicialización y su runtime, es mejor que C++.
Creo que en general solo ha leído un poco sobre los lenguajes que compara y se ha montado su película. Sobra teoría y falta experiencia en este artículo.
#8 Si. Eso me llamó la atención. Que valore el "tiempo en compilar" y la velocidad de ejecución o el uso de RAM le de igual...
Debe ser de esos programadores de "si te va lento, compra una máquiina más potente" de hoy en día. Tenemos ordenadores órdenes de magnitud más potentes para hacer lo mismo a la misma velocidad.... Si se optimizara como antes....
Comentarios
C++ ¿El peor?
¿Javascript mejor que C#?
A la hoguera con el articulista.
#3 Yo no estoy de acuerdo, pero esta bien expuesto. Merece una lectura
un hipster que acaba de descubrir la programación funcional, y cree que los demás son idiotas. Me aburro.
#6
Es un modo de verlo, si.
#18 argumento falaz no, ¿si realmente C++ fuera tan malo como dice este artículo como es posible que sea un lenguaje elegido para motores de bases de datos, navegadores web, sistemas operativos, máquinas virtuales, videojuegos, motores gráficos...? Según la teoría de este artículo todo eso debería cambiar a todos los lenguajes que dice que son mejores que c++... pero a la hora de la verdad parece que el rendimiento de C++ es mucho más potente de lo que dice en el articulo... ya sólo decir que en C++ no hay concurrencia y que esta pensado para monothreading... si ya hasta el STL de c++11 en adelante existe el std::thread y std::mutex...
#19 Si. Es un argumento falaz. Que lo use mucha gente, o "los mejores" no demuestra absolutamente nada.
No dicenen ningún lado que en C++ no haya concurrencia. Solo que no es un lenguaje diseñado con SMP en mente. Y tiene razón.
El multiproceso existe desde siempre en C y en C++, pero NO es lo mismo.
El artículo es de alguien que no tiene ni idea de C++... si según el artículo es tan malo no se como se usa en todas las aplicaciones básicas y donde se requiere potencia y eficiencia desde sistemas operativos, videojuegos, motores de bases de datos, navegadores web, etc...
#7 Ni de Java... Pero te has marcado una falacia de campeonato.
El expone su criterio, y lo hace bastante bien, aunque en algunos ejemplos se ve que tiene ideas preconcebidas falsas
#14 Falacia para nada, C++ es el mejor lenguaje de programación de todos los tiempos a pesar de sus detractores y haters...
#17 Ahi no entro. Pero el argumento que das para sostener esa afirmación es falaz.
Artículo malo malo. Pero bueno creo que criticar a C++ debe tener su público.
#5 No. El articulo no es malo. Otra cosa es que no estes de acuerdo.
Yo no lo estoy, por ejemplo
Me pregunto cuál es su solución tan novedosa para reemplazar las excepciones...
Nowadays there are much better mechanisms of error handling. Possible errors should be type-checked at compile-time. Languages that do not use exceptions by default will be ranked higher.
#1 ¿Tratar los errores cuando se producen?
Dejarlos para las excepciones generara estructuras "try" de errores procrastinados curiosas y para, mi gusto, mas difíciles de auditar.
#2 Volver al chequeo del valor de retorno de toda la vida?
No, gracias.
Las excepciones te permiten tratar el error donde debe tratarse
El compilador te avisa. Si el programador quiere ser un incompetente no existe ni existirá en la tierra un lenguaje que lo evite
#2 Los errores no "se dejan para las excepciones", los errores se notifican para que sean tratados donde correspone.
#16 Utilizar las excepciones como flujo de control de errores deja de ser excepcional.
Mi preferencia por los "Códigos de error" frente a las excepciones se basa las siguientes premisas:
- Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
- Las excepciones rompen la estructura del código al crear múltiples puntos de salida invisibles que dificultan la auditoría.
- Si no se dispone de recolector de basura con las excepciones es fácil producir "fuga" de recursos, especialmente si el lenguaje no tiene "comodines" para utilizarlos en todas las salidas del bloque. Ejemplo de asegurar una ejecución en todas las salidas en golang: https://www.digitalocean.com/community/tutorials/understanding-defer-in-go-es
- Las excepciones utilizan generalmente mas recursos que los "códigos de error".
https://trinket.io/python3/671103b72b
https://gist.github.com/mattwarren/e3cdd278ba9c2cad03cc6b53ce6d47f6
Las excepciones tienen ventajas y en ciertos lenguajes son el único mecanismo para controlar los errores, como reportar errores a constructores. No es el caso de rust o golang. El tratamiento de errores en rust es desde mi punto de vista de lo mejor para realizar código seguro.
Una ventaja de las excepciones es que son ideales para crear código inseguro que ignore muchos errores.
#21 Utilizar las excepciones como flujo de control de errores deja de ser excepciona
. Si les llamamos "avisos" deja de existir ese "problema". Habrá que proponer un cambio de nombre....
Ese argumento es bueno....
Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
FALSO. Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el compilador te OBLIGA a que hagas algo al respecto y no te permite dejar el resultado de la llamada "a lo que salga", como ocurre con los códigos de error. Por otra parte el tratamiento de errores es muchísimo más sencillo y el código producido mucho más claro y legible.
Las excepciones rompen la estructura del código al crear múltiples puntos de salida invisibles que dificultan la auditoría.
También lo hace un tratamiento de errores con códigos de error. Si un método o función te devuelven -1 indicando que funcionó de pena y todo se puede ir al garete.... qué haces en la instrucción siguiente ? Los puntos de salida no son "invisibles". O resuelves el problema si es asunto de tu método o la relanzas al llamante si debe ocuparse él. Simple y limpio.
Si no se dispone de recolector de basura con las excepciones es fácil producir "fuga" de recursos, especialmente si el lenguaje no tiene "comodines" para utilizarlos en todas las salidas del bloque. Ejemplo de asegurar una ejecución en todas las salidas en golang: www.digitalocean.com/community/tutorials/understanding-defer-in-go-es
#23 Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el compilador te OBLIGA a que hagas algo al respecto y no te permite dejar el resultado de la llamada "a lo que salga", como ocurre con los códigos de error.
====== test.cpp ====
#include
#include
using namespace std;
int main () {
ofstream f("test.txt");
f
#25 Prueba en Java.
No soy experto en C++, pero en Java a no ser que sea una unchecked exception estas obligado a tratarla, de un modo u otro.
Si el C++ no lo hace el problema no es de la gestión de errores mediante excepciones. Por cierto, si gestionas el error con códigos de retorno el problema es el mismo
#25 Como dije, no uso C++, pero parece ser que precisamente los streams no lanzan excepciones y es necesario gestionar los errores mediante el valor de retorno...
Aunque se pueden habilitar.
https://stackoverflow.com/questions/10337915/ofstream-exception-handling
#33
Hombre esa comparativa dice que Go viene usando el doble de RAM en prácticamente todas las pruebas... incluso hay una que usa un 5 veces más....
¿No es en la columna que pone "mem" ?
Y en cuanto a velocidad de ejecución bastante más lento. En reparto de trabajo entre CPU si que están parejos... esperaba mucho más de Go en eso.
Me dan exactamente igual las opiniones de Linux Torvalds. ¿Eres capaz de razonar por qué es mejor el tratamiento de errores con valores de retorno en lugar de con excepciones es "mejor"?. Torvalds es de mucho de quejarse, aunque finalmente tenga que reconocer que "es lo mejor que tenemos, pero aún así es una mierda" (frase que me acabo de inventar, por supuesto, pero no me extrañaría que estuviera cerca de la realidad).
Yo si te puedo dar razones de lo contrario.
#29 Todo depende de los entornos de los que estemos hablando. Cada cosa tiene su nicho.
Los contenedores no se usan "para paliar los problemas de dependencias", tienen otras enormes ventajas mucho más allá de eso, y desde luego tienen muchos menos problemas de seguridad que una aplicación monolítica ejecutada en el propio sistema.
Y otra vez estamos hablando del tiempo que ahorra el desarrollador frente a la calidad y velocidad del sistema desarrollado en explotación. Da igual que tarde 5 minutos que 20 si se hace de modo automático. Lo realmente importante es el rendimiento y requerimientos de la aplicación final. Y de todos formas estamos hablando de entornos de compilación, no de caracterísiticas del lenguaje, que es de lo que iba el tema.
Desconozco completamente Go, pero lo que expone la comparativa en numerosos apartados está profundamente equivocado (como el tema de las excepciones, por ejemplo).
Me ha gustado el artículo, aunque difiero en muchas cosas .....
No veo ningún inconveniente a la gestión de errores con excepciones, por ejemplo. Me parece un gran avance.
Tampoco veo ventajas en los objetos inmutables en aplicaciones "normales" que superen los inconvenientes.
Valorar la velocidad de compilación igual que la de ejecución me.parece directamente una idiotez.
Un articulo muy interesante, si.
#38 Pues depende lo que se quiera gastar en hardware y de la tarea a realizar.
Que no se me entienda mal. No estoy criticando a Go, seguro que es un gran lenguaje y tiene su nicho, como todos. Pero algunas razones para poner unos lenguajes por encima de otros del artículo me parecen profundamente equivicadas.
Go sera un gran lenguaje. Pero prefiero un Kernel de Linux en C.
Si es por eso...:
$cat 100mb.c
#include
void main(void) ">
$gcc 100mb.c -o 100mb
$./100mb
Hola Mundo
$ls -ltra 100mb
rwxrxr-x 1 xavi xavi 16600 dic 12 21:01 100mb#24 Ciertamente estoy un 2% mas cerca de los 100MB que usted.
Esta claro que usted enlaza en "dinámico". Las ventajas del estático en mi caso es un despliegue muy sencillo y carente de contratiempo.
Por ejemplo, un aplicativo con servidor http/s, tls, cliente postgresql, plantillas html, traducciones, validaciones de formularios, etc se queda el binario en 16 MB. La compilación de todo tarda 2 segundos y los únicos requisitos de este binario para funcionar son: https://github.com/golang/go/wiki/MinimumRequirements
#27 La unica ventaja del enlace estatico es la no dependencia de librerías externas. Y tiene muchos inconvenientes, como el parcheo de bugs o el uso de RAM.
#28 Usted conoce como son los usos modernos, para paliar los problemas de las dependencias en los despliegues se utilizan contenedores que tienen los mismos o mayores problemas de mantenimiento y seguridad.
Con Go actualizar todas las dependencias y generar un nuevo binario puede llevarte entre 2 y 5 minutos en proyectos grandes (siempre utilizando librerías nativas en GO, no enlazando a librerías C), un tiempo similar a actualizar las librerías de todo el sistema si hablamos de "Como Unix".
Pocos proyectos de entidad en java tendrán un proceso de actualización de dependencias y/o generación de binarios tan rápido.
Pudiendo generar los binarios cuasi-simultáneamente para varias plataformas.
https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63
#28 En cuanto al uso de RAM, juzgue usted:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html
#30 Estas comparando un lenguaje de máquina virtual contra un lenguaje compilado. No es una comparación justa. Si comparas con lenguajes "de su segmento" como C/C++ te encontrarás con un uso de RAM muy superior a veces más del 100% superior.
#32 ¿esta usted seguro?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html
Podemos venirnos arriba y rememorar las "llameantes" opiniones de Linus Tolvards en LKML sobre las excepciones en C++ y su "seguridad".
#35 Dudo que pueda dejarlo en 1kb como estático. Eso solo lo creo posible en asm y utilizando solo llamadas al kernel.
Deben ser proyectos con muchas librerías incluidas o una cantidad importante de símbolos.
Es el precio a pagar por disminuir las dependencias. ¿Pero eso influye en el rendimiento?
#36 Hombre, menos de 1kb, no pero en un simple hola mundo se consigue un ahorro apreciable en C (en C++ supongo que ocupará algo más)
xavi@jupiter:~$ cat 100m.c
#include
void main(void) ">
xavi@jupiter:~$ gcc --static 100m.c -o 100m
xavi@jupiter:~$ ./100m
Hola Mundo!
xavi@jupiter:~$ ls -ltra 100m
rwxrxr-x 1 xavi xavi 782736 dic 13 01:33 100mxavi@jupiter:~$
#37 Sería increíble que con el recolector y el "runtime" ocupara menos el binario de Go.
Las realidades que no le voy a discutir son:
Compilación rápida != optimización extrema
Recursos con recolector > recursos sin recolector
Tamaño binario estático > tamaño binario dinámico
Pero lo interesante creo que es:
¿afecta negativamente el tamaño del binario en sus proyectos al rendimiento, a las funcionalidades?
¿son tamaños inasumibles?
Why is C++ so bad? In my opinion, the biggest reason is its age. C++ was designed long ago, in 1979. At that time the designers lacked experience and had no idea what to focus on. Ahi dejé de leer
En fin, menudo despropósito
Creo que estamos ante el típico programador al que solo le importa su tiempo, y no el de sus usuarios. Decir que C++ es lento, o que el “startup time” de Go, con sus binarios de 100MB, su modelo de inicialización y su runtime, es mejor que C++.
Creo que en general solo ha leído un poco sobre los lenguajes que compara y se ha montado su película. Sobra teoría y falta experiencia en este artículo.
#8 Si. Eso me llamó la atención. Que valore el "tiempo en compilar" y la velocidad de ejecución o el uso de RAM le de igual...
Debe ser de esos programadores de "si te va lento, compra una máquiina más potente" de hoy en día. Tenemos ordenadores órdenes de magnitud más potentes para hacer lo mismo a la misma velocidad.... Si se optimizara como antes....
#8 Vamos a por los 100MB.
$ go version
go version go1.15.6 linux/amd64
$ cat 100mb.go
package main
import (
"fmt"
)
func main() ">
$ go build 100mb.go
$ ./100mb
Hello world!
$ ls -ltra 100mb
rwxrwxrx 1 luser luser 2034781 dic 12 19:58 100mbMe he quedado corto.
Go no esta tan lejos de C++ en rendimiento con algunas ventajas importantes como la portabilidad sin lineas adicionales.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html
#22 un hello world por encima de 2MB te parece poca cosa? Eso mismo en C++ lo puedes dejar en menos de 1KB.
Trabajo profesionalmente con Go y tenemos binarios que se van hasta los 80MB.