"Si has venido aquí en coche, algunos de sus controles –inyección de combustible, dirección, frenos– podrían estar en C++. Si hoy has mirado la tele, habrá algo allí también: las cámaras, los sistemas de comunicación probablemente lleven C++. Mucho software que tu móvil usa para hablar con la torre es probablemente C++. El GPS tiene algo de C++. Es como las tareas domésticas: solo se ve si no está bien hecho". Y esa invisibilidad no sólo se aplica al lenguaje C++ que usan todas esas tecnologías, sino también al creador de dicho lenguaje.
Comentarios
- ¿Qué fue de él?
- Murió de éxito
- ironías de la vida
- Que hubiera usado un exception
Con ese titulo parece que el hombre acabó en la calle pidiendo delante de un super
#2 Ese es el destino reservado a los creadores de lenguajes como Java.
Una de las principales ventajas de Rust es que a los desarrolladores que lo conocen les gusta programar con él. Si C++ no quiere convertirse en un nuevo Cobol, debería esforzarse justamente en ese punto: en ofrecer una buena experiencia de desarrollo, incluyendo el propio aprendizaje del lenguaje y sus librerías.
#3 Pero si en internet tienes un monton de infomación de C++11, C++14, C++17, C++20 y de toda la STD perfectamente documentado... pero es que incluso a dia de hoy no hace falta ni poreocuparse por memory leaks y de hacer new/delete, con los smartpointers (std::shared_ptr y std::unique_ptr) tienes todo eso resuelto... que digas hace mas 25 años que internet apenas existia y tenias que leer libros tediosos por aqui y por alla para entender una 10 parte del lenguaje... pero hoy en dia hay multitud de ejemplos e informacion en internet para utilizarlo rapidamente...
C++ hoy en dia tiene toda la ventaja de un lenguaje de bajo nivel adaptado a alto nivel, catacteristicas que se han ido añadiendo en los ultimos 10 años...
#5 No digo que no, pero si alguien quiere estudiar Rust hoy día tiene una versión, un compilador multitud de tutoriales actualizados. En C++, una multitud de versiones, compiladores, y tutoriales desactualizados.
Al final, las herramientas que se perciben sencillas desde el principio tienen más éxito que otras, quizás con más posibilidades, pero menos amigables con los nuevos usuarios.
Estoy hablando de percepciones.
#6 Para nada, C++ Standard es eso: standard y crossplatform... y un compilador ya sea gcc, g++, Visual C++, etc que este preparado para C++11, o C++17, va a compilar ese codigo estandar.... mas alla de que luego cada "fabricante" añada a su compilador mas funciones distintas que solo funcionan en su compilador...
#7 De nuevo: no digo que no sea así, digo que para alguien que empieza no es fácil percibirlo así.
#3 A ver, si Rust va a acabar con C++, que se ponga a la cola, que no es el primero que lo dice.
Ni sera el ultimo.
#10 Una cosa que no entenderé es que si Rust quería ser el sustituto de C, ¿por qué no genera código C en lugar de binarios? En teoría sería posible y tendrías un código C seguro que podrías compilar en cualquier sitio de forma eficiente.
C++ es una puta mierda.
Go es el sucesor natural de C.
Y Chicken Scheme con compilado nativo y segun que librerias hace que odies a C++, a Motif con C++ y a QT posteriormente a muerte, por haber creado un monstruo peor que el 286 y MSDOS y luego el 386 frente a CPUs y modelos mucho mas sencillos.
http://harmful.cat-v.org/software/c++/
Despues de probar a programar en Chicken una minicosilla simple con OpenGL los de GNU tenian que haber barrido con Unix y C (aunque GNU no sea Unix) y reescribir las coreutils y demas en Scheme con un JIT, y hacer de un Emacs reescrito con Scheme la shell/REPL principal.
Hubieramos avanzado muchisimo.
#9 Go es basura. Y un lenguaje feo de cojones.
#11 Para feo C++ con un template, donde los mensajes del compilador son más gordos que el manual de Emacs.
#12 Ok bro, pero C++ tiene más de 40 años y Go lo desarrollaron hace nada. Es feo, es ramplón, el sistema de paquetería es un mondongo, los binarios que genera son bolas de sebo, etcétera etcétera etcétera.
Una vez superado el hype inicial, potenciado por Google que ha usado Go para hacer su Kubernetes y demás artilugios de gran uso hoy en día, ¿quién cojones va a querer empezar in proyecto de cero en Go, teniendo Rust que hace todo lo que hace Go pero mil veces mejor? Y para lo demás ya tienes C++ con librerías maduras y estables que no te cuesta más aprender que las de Java, Python o cualquier otro lenguaje.
#13 Menudo cuñadismo. C++ aun teniendo 40 años es un truño mastodóntico del que hasta sus creadores se han arrepentido.
Go es de los creadores de C y Unix y tiene más de 30 años de recorrido simbólico, casi 40, encarnado en Plan9 y su divergente C con su suite de compiladores y también en Alef e Inferno.
Sobre Rust, éste no compila a ciertas arquitecturas. Y compilarlo en según que equipos con requisitos constreñidos es im-po-si-ble.
Sobre bolas de sebo, te has quedado en 2013, ahora son mucho más livianos.
Sobre binarios de C++, ve y compárame un binario en multiemuladores en C cualquiera contra Mednafen en C++ y luego me dices si es normal.
#14 Hablas de cuñadismo y sueltas toda la colección de cuñadeces de internet sobre C++, Go y Rust.
Para empezar, ningún "creador" de C++ se ha "arrepentido" de nada. No sé de dónde te sacas eso, pero me imagino que es de aquella supuesta entrevista a Stroustrup donde echaba pestes del lenguaje. Te cuento un secreto: era un April Fools. Una coña, una broma.
Para continuar: Go es una puta mierda de lenguaje feo y mal diseñado que Rust se come con patatas en todos los benchmarks serios. Pero más allá de eso, Go no es un lenguaje pensado para sistemas como lo es C o como de hecho lo es Rust. Sus carencias en ese sentido son bastante evidentes. Es un lenguaje pensado para hacer microservicios y sistemas distribuidos que corran sobre otras plataformas.
No tiene sentido comparar Go con Rust para sistemas y ponerte a decir cosas como que "no compila en determinadas plataformas y equipos con requisitos constreñidos" como una desventaja de Rust frente a Go. Es absurdo.
Sobre binarios en C++, cógeme el programa que tú quieras, me lo picas en tu querido Go, Game of Life mismamente, y luego en C++ y lo ves por ti mismo. Ah, y luego en Rust también.
Esta discusión es absurda y Go es un lenguaje inventado por Google para resolver problemas que sólo tenía Google. Lo de que tiene "casi 40 años de recorrido simbólico" ni lo comento, porque eso es de cosecha propia, está sólo en tu imaginación.
#c-15" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3790873/order/15">#15 Eso de Go inventado por Google solo demuestra tu tremendo analfabetismo sobre el futuro de C y Unix. Pista, te suena Rob Pike? Plan9? La compilacion cruzada de Go y los compiladores de Plan9? Alef e Inferno de Lucent?
Imaginación no sé, pero me estoy descojonando. Go sale de esa gente, de los de Unix y C, misma gente, los de C, Unix, AWK. ESA gente. De hecho sin Plan9, Blit o Acme basado en Oberon no hubieras tenido Golang ni borracho.
Ah, Rust no es rival para Go, es rival para C++. Go si acaso sería un C simplificado para hacer programas para el espacio de usuario y como alternativa sensata a Perl o Python, no entra en el juego de C, cosa que se sigue usando pues es la API básica de Unix.
De C++ mejor no hablo, donde proyectos de 2007 (casi ayer) hoy ni compilan siquiera.
Sobre los creadores de Go, pues como se follan al creador de C++ y se le mean por encima por la experiencia que tienen desde el puto PDP10 con Unix, C y las colaboraciones cruzadas en cosas cmo los BSD.
Golang es la alternativa que debió surgir tras C para el espacio de usuario de los Unix y no esa mierda de C++ con Motif para crear el Netscape y luego QT con C++.
Total, tenemos equipos potentísimos y hasta Microsoft usa cosas como C# en su capa gráfica en Windows.
El usar Golang post 2004-5 en vez de C para escribir por ejemplo un escritorio multiplataforma en muy poco tiempo hubiera sido un ejemplo de adaptarse bien a los nuevos tiempos.
#16 Go si acaso sería un C simplificado para hacer programas para el espacio de usuario y como alternativa sensata a Perl o Python, no entra en el juego de C, cosa que se sigue usando pues es la API básica de Unix.
Go es basura, te lo he dicho ya. Un movida inventada dentro de Google, me da exactamente igual por quién porque al final esa mierda sale de Google por orden de Google y no por decisiones de "los fundadores de Unix y C para que sea el futuro de C" ni fumadas de sapo bufo, que se crea para resolver problemas que sólo tenía Google en proyectos de la propia Google.
Conozco a, y he trabajado con, gente que ha estado en Google en California durante lustros y ellos mismos (en plural) me han dicho exactamente eso. Gente que ha picado más Go del que has picado tú y en productos de primera línea mundial.
Y acabaron de Go hasta las pelotas. Y no me extraña.
Que a ti te gusta mucho Go porque te has picado tres microservicios y has visto que va "más rápido que Python", okay. Yo te diré que me han vacilado niños de Go en mi curro en 2021 queriendo follarse un servicio legacy hecho en esa basura de librería Python que es Flask y al final me los he follado yo a ellos haciéndolo en FastAPI. Experiencia de primera persona: ni siquiera necesito bajarme a usar un lenguaje feo de cojones como Go para tener un rendimiento óptimo en una ap web: lo puedo hacer en Python y tengo los mismos benchmarks.
Hablas de UIs y a día de hoy Go no tiene absolutamente NADA que se pueda usar decentemente para desarrollar apps de escritorio y te pones a echar mierda sobre uno de los mejores frameworks de desarrollo de GUIs que existen, Qt. En serio, que vengas diciendo gilipolleces de Qt y alabando la mierda de Go sólo me demuestra que no has usado Qt en la vida.
En fin, que menuda discusión absurda, como decía. Ya cuando empiezas a meter que Go tiene casi 40 años teóricos es para descojonarse pero el resto de historietas que te montas no hay por dónde cogerlas.
#17 No es por orden de Google, flipado. No has entendido una puta mierda, como todos los rock star developers como tú.
Go nace de los preceptos de Plan9 al ser un compilador que compila cruzadamente *por defecto* como hacían los C en esa máquina, y también recoge mucho diseño de Alef e Inferno, tecnologías que hacen que C++ parezcan una basura hiperinflada y propensa a fallos en comporación.
No es un lenguaje nacido de Google, es un lenguaje nacido de las cenizas del Unix, del Blit de los 80, de Plan9 y hoy 9front, SO's y diseños (sobre todo factotum vs OpenSSH y auth en Unix, entre otros; fossil en fs, los namespaces y el dialecto de C) que dejan a C++ y tu maravilloso moc de QT bajo X como una basura de los 90 que debió ser enterrada en los 2000 con paladas de hormigón. Lo mismo opino de XFree86/X.org. Incluso siendo usuario de Xenocara bajo OpenBSD e Hyperbola. Ambos, C++ y X11 son cosas que debieron ser tiradas abajo sin pensárselo dos veces.
http://harmful.cat-v.org/software/c++/
Sobre QT, lo conozco hasta cuando era propietario, así que no me des lecciones ahora del recorrido de Linux cuando usaba Slackware en casa de vecinos frikazos con PC en sus casas y entender los manuales se me hacía mucho más simple al haber usado DOS en primaria frente al asqueroso Windows .
#17 Si no tienes ni puta idea de la historia de Go y Unix post cisma de los BSD, pues mejor no hables.
Busca info sobre Unix 8 bajo simh, lanza 9front en una VM y verás que esas tecnologías están ligadas y son la inspiración de Golang.
Limbo nació de Inferno, Bell Labs/Lucent y si juntamos los compiladores de Plan9 de esa compañía nace... oh, milagro, Golang. Joder, que la sintaxis de Limbo y Go están ligadas y son muy anteriores a Google.
https://es.m.wikipedia.org/wiki/Limbo_(lenguaje_de_programaci%C3%B3n)
https://es.m.wikipedia.org/wiki/Inferno_(operating_system)
La concurrencia de Golang (CSP) también nace de Limbo.
Lo dicho, poco conoces ciertos sistemas.
Es lo mismo que sigo que OSX e iOS en el fondo nacen del SO de un NeXT recauchutado con Mach, parte de FreeBSD y la API de Carbon y Cocoa pegada encima. Pues sí, básicamente el pasado de iOS (y sobre todo OSX) es el NeXTStep al igual que Go nace de Plan9/Alef/Inferno y todas esas tecnologías están relacionadas entre sí aunque no sea obvio.