El estudio de videojuegos LogLog Games se da por vencido con Rust, al que siguen viendo muchas ventajas... para todo lo que no sean videojuegos. Uno de los principales retos fue la curva de aprendizaje del lenguaje: Rust es notoriamente complicado para principiantes y, aunque los desarrolladores de LogLog Games no eran precisamente inexpertos (escribieron más de 100.000 líneas de código en esos tres años), muchos de los problemas iniciales no desaparecieron con el tiempo.
|
etiquetas: rust , no sirve , videojuegos 
C no es un ensamblador con colorines. Y te lo dice alguien que tiene los huevos pelados de programar en C y en su día en ensamblador.
C proporciona un fácil acceso a ASM embebido, pero no es un "ensamblador con colorines". Basta que hayas tenido que escribir algún código en ensamblador para que te des cuenta.
Lo que ejecute la CPU cuando programamos en C preocupa más bien poco. Se encarga el compilador de ello. Igual que en Rust.
C no es un ensamblador con colorines. Y te lo dice alguien que tiene los huevos pelados de programar en C y en su día en ensamblador.
C proporciona un fácil acceso a ASM embebido, pero no es un "ensamblador con colorines". Basta que hayas tenido que escribir algún código en ensamblador para que te des cuenta.
Lo que ejecute la CPU cuando programamos en C preocupa más bien poco. Se encarga el compilador de ello. Igual que en Rust.
¿ Sabes como funciona una CPU microprogramada ?
Esa historia de la unidad de control, juego de instrucciones....
¿ Te recomiendo un libro ?
El Microcódigo de las CPU no tiene absolutamente nada que ver en el tema que estamos tratando. Y sé perfectamente qué es, para qué sirve y en qué consiste.
Por lo que se ve, tú no.
Un abrazo a ambos
C era ensamblador con colorines en su nacimiento, cuando las máquinas eran simples y era "predecible" el output del binario, en el sentido de que la gente se podía imaginar que set de órdenes de ensamblador equivalían a cada orden de C. Pero no permitía ir al detalle al que iba ensamblador, podríamos decir entre muchas comillas que era casi "un macro" de assembler.
Eso dejó de ser así hace muchísimo, para… » ver todo el comentario
Yo no diría esto a alguien y después soltaría esto:
C es un lenguaje de alto nivel, tan alto nivel como Java o Python.
C no tiene nada que ver con Python. Es más, diria que se parece más al ensamblador que al Python.
O cosas como:
Dicho esto, tu afirmación de que “cuanto más alto nivel más ineficiente” es evidente absurda y por ello falsa. La eficiencia del código depende mucho más de los conocimientos
… » ver todo el comentario
TAMBIENun ( o mejor dicho EL ) ensamblador portable en el sentido de que permite, precisamente, trabajar casi casi con el mismo nivel que la… » ver todo el comentarioEn lineas generales, pero cuando hablamos de programación de videojuegos lo que haga el compilador por su cuenta preocupa y ocupa. Esta misma noticia #0 de algún modo lo confirma.
Y yo creo que deberias estudiarte el 'código fuente' de un compilador básico de C, ya te adelanto que te sorprenderás de lo acertado de mi comentario #8.
#38 #20. Con colorines, una gráfica forma de plantearlo.
#149. Efectivamente. Aparte de un compilador directo de lenguage ensamblador ningún otro lenguage está más cerca del propio ensamblador que el lenguage C, de ahí viene su eficiencia (bien empleado) y de ahí vienen los kernels de los sitemas operativos.
Primero, como te ha dicho #20, C es un lenguaje de alto nivel, tan alto nivel como Java o Python.
Es una confusión muy común pensar que hay distintos niveles de “altura” en la clasificación de los lenguajes de programación, cuando en realidad solo hay dos; bajo nivel (Lenguaje máquina y ensamblador) y alto nivel (Cualquier otro).
Todo lo demás son charlatanería repetida mil veces por medios generalistas supuestamente… » ver todo el comentario
Eso en 1999. Hoy los procesadores desde amd64 no operan en registros directamente como pensarias. Hay microcodigo, y a efectos practicos segun el compilador (y no hablemos ya de cosas como el IR de LLVM) hacen que muchas veces el procesador opere de forma totalmente distinta a la que operaria un Z80 con instrucciones que se ejecutan de formal literal.
Eso en 1999, en 2025 y en 2125.
A no ser que le llames "alto nivel" a lo que a tí te salga de los cojones. ¿ Alguna vez en tu vida has visto algo codificado en ensamblador ?
Hoy los procesadores desde amd64 no operan en registros directamente como pensarias. Hay microcodigo,
Hay microcódigo desde hace eones. Los procesadores cableados son de usos muy específicos. Usamos CPU microprogramadas desde casi siempre.
y a efectos practicos segun el
… » ver todo el comentario
Solo gameboy con su Z80 modificado, i486, amd64, risc-v... nada, poco.
>Por otro lado si con LLVM te refieres a un entorno de ejecución de lenguaje intermedio al estilo Java, las CPU no ejecutan eso. El microcódigo no es para eso.
No.
>Las instrucciones ensamblador siempre se ejecutan "de forma literal".
Ya no.
¿ Y qué parecido le encuentras con un código escrito en C ?
No.
No qué ?
A qué te refieres exactamente con "IR" y con "LLVM" hablando de ejecución de código ensamblador ??
Ya no.
Si, A no ser que estemos entendiendo por "forma literal" cosas distintas. Una instrucción ensamblador hace lo que hace, no unas veces una cosa y otras veces otra. Si yo hago un MOV, un CMP un CALL, un JMP.... hace un MOV, un CMP un CALL o un JMP.
Por cierto, leete el enlace a la Wikipedia que me has puesto. Te hace falta.
(pd. No tengo ni idea de si la instruccion BEXTR se ejecuta usando microcodigo o no, solo la he usado como ejemplo).
No tienen absolutamente nada que ver, independientemente del juego de instrucciones que elijas para el ensamblador.
En ensamblador no hay ningún tipo de estructura de control, ni siquiera un simple condicional. Hay que hacerlo a manita con una comparación y un salto, CMP y JMP. Lo mismo para los bucles y cualquier otra estructura de control.
Decir que son muy parecidos es demostrar desconocimiento total de lo que es la programación.
Y de la existencia y calidad del compilador
A mayor nivel, menor distancia
Pero sí, todos son de alto nivel en el sentido de que la sintaxis y ordenes son las mismas, no varían con el hardware, abstrayendonos de pensar tan a bajo nivel (no controlas si se usa el set de instrucciones xx de los últimos procesadores, que caché está usando, ni nada de eso por ejemplo).
No seamos tan categoricos , por favor. Vengo a Meneame a informarme y aprender, no a medir el tamaño de mi miembro viril con el de otros: eso no es una competición de quién sabe más.
Así que yo voto a favor de #8
Al que se le ocurrió el tema de los tabuladores había que fusilarlo.
#42 Sabes que no tiene que ser tabs, no? Que problema encuentras al refactorizar código?
¿Y?
Y ni siquiera el IDE te va a notificar nada.
El código puede ser igual de válido sintácticamente con tab o sin tab.
Y puedes haber hecho muchos cambios después de borrar el tab accidentalmente.
Y en cualquier lenguaje, una línea desaparecida puede dejar una sintaxis perfectamente válida.
Y uno puede seguir trabajando tranquilamente hasta que un día le explota el error en la cara.
Pues okey. Con esos argumentos me queda definitivamente claro todo
#3. El C es practicamente ensamblador, alguien con mucha experiencia en C y ensamblador casi puede deducir que código fuente en ensamblador se va generando detrás del C, y el C++ una extensión orientada a objetos más lenta en cuanto al hardware y más rápida en cuando al desarrollo de software. Incluso es posible enfocar el lenguage C, sin objetos por defecto, orientándolo "a mano" a objetos.
Y te digo de paso, que ahora programo en C# la mayor parte del tiempo y puedo ver (y a veces lo hago por curiosidad) el código ensamblador que se ejecuta a partir de un código en C#. Si ves muchas veces esto puedes llegar a aprender que código ensamblador se va a generar. Lo cuál no quiere decir que ambos lenguajes estén cerca.
(también veo muchos vídeos de Nick Chapsas y lo hace constantemente)
Toda esa complejidad añadida en los tipos tiene sentido cuando merezca la pena (es decir, cuando se necesite seguridad de memoria sin penalizaciones de GC u otras cosas), para el resto del mundo, un lenguaje con recolección de memoria es lo más sencillo y sensato.
Todo el bombo y platillo que se da a rust está en gran medida injustificado
El único problema aquí es que Rust es un lenguaje muy joven y no hay librerías maduras para un montón de cosas, como las que hay en C++, Java o Python.
El día que alguien desarrolle para Rust un motor de videojuegos, se acabó C++ porque quién va a querer hacer proyectos desde cero con un lenguaje mucho más complicado y que además es más inseguro. A igualdad de opciones Rust gana de calle.
En veinte años ni Cristo usará C ni C++ para proyectos que requieran lenguajes de bajo nivel. Ahora mismo esos lenguajes viven de la inercia de décadas de desarrollo de librerías, pero el futuro es claramente Rust.
Que COBOL era un cadáver esperando entierro y que c y c++ iban detrás
Un visionario.
Treinta años después ahí siguen
"C++ es infumable" solo porque no sabes usarlo bien. Yo no lo he usado profesionalmente porque me tuve que pasar a JAVA. Pero C++ es el culmen.
"Que COBOL era un cadáver esperando entierro y que C y C++ iban detrás" Toda la infrastructura bancaria mundial funciona con COBOL en IBMs JCL. El dia que pasen toda esta mierda a algo mas moderno... como Kafka, .... dejan en la calle a miles de personas.
Es lo que me decían hace 30, cuando entraba en la carrera y ahí sigue, sin que se adivine en el horizonte una fecha en la cual se pueda decir "pues adiós".
COBOL no muere, JCL y las IBM no mueren, pero nadie se quiere meter en eso porque nunca sabes cuando te vas a quedar sin curro. Algo tiene que sustiruirlo, Kafka + Hadoop o algo asi? Lo he visto usado para manejo de registros.
A mi me costó un poco aprenderlo, porque todo el tema de los lifetimes, y como funcionan las referencias a memoria, con su sistema de propiedad se me hacía raro. Pero una vez que lo aprendes, dominarlos es menos complicado porque pegarte un tiro en el pie es mucho más difícil. Con C++ tienes más posibilidades de liarla con accesos a memoria, etc.
C y C++ son otros dos que ya están empezando a ser despreciados también. Todas las herramientas de sistemas o los nuevos paradigmas y aplicaciones se están implementando en Rust o en Go, una de dos. C++ sólo sobrevive en lugares donde no hay librerías disponibles para esos menesteres, como por ejemplo los videojuegos, pero ya está. En cuanto a la inteligencia artificial, prácticamente dominada hoy en día por Python, es cuestión de tiempo que Rust empiece a desplegarse en todo el bajo nivel, reemplazando a C++.
#16 Python sin C, C++ y BLAS/LAPACK (fortran) estaria muerto.
Python tiene cien mil librerías que se gastan masivamente y que no tienen implementaciones internas de bajo nivel y por lo tanto no gastan C's ni FORTRANs. En cuanto a las que lo hacen, Rust está ya, ahora mismo, sustituyendo a C y C++ en esas librerías Python, por motivos más que evidentes.
#32 Módulos que están ahora mismo, hoy, y en 2024 y en 2023 y en 2020 también estaban ya, cada vez más desarrollándose en Rust.
* CPython, el más estándar,
* JPython, sobre Java. En entornos Hadoop se ve bastante por temas de Scala.
* PyPy,
* RustPy,
* etc...
Y una larga lista. Evidentemente, el interprete subyacente afecta a las capacidades y rendimiento de Python, pero aun así hay para elegir según la aplicación.
>C++ sólo sobrevive en lugares donde no hay librerías disponibles para esos menesteres, como por ejemplo los videojuegos, pero ya está
Ya quisieras. En videojuegos de PC y consola, multimedia, navegadores... es el rey.
Windows o Linux usan C.
C++ tiene la posibilidad de usar entremezclado codigo C.
Por qué, exactamente?
En principio dudo que alguien escriba un gran motor de juegos en Rust. El modelo de Rust implica a menudo hacer copias,no es precisamente lo ideal cuando se quiere exprimir al máximo el… » ver todo el comentario
Hay dos tipos de lenguajes de programación: los que la gente odia y los que nadie usa. C, C++, Rust, Python, Java y Go son odiados y el resto no los usa nadie
Un programa bien hecho en C es exactamente igual de seguro que uno bien hecho en Rust.
¿ A qué le llamas tú "guarrear" ?
No, lo siento, y eso que no me gusta Rust, pero Rust es mucho mas seguro que C en ese aspecto. Si hubieras dicho C++...
En qué es "mas inseguro" exactamente?
Recuerda que hablamos de programas bien hechos. No es una cuestión de gustos.
Si hubieras dicho C++...
C++ no es "más seguro" que C. El acceso a memoria es prácticamente igual.
Hombre, hace tiempo que no uso C++ pero supongo que hay cosas que no han cambiado:
Si defino un puntero, puedo usarlo sin inicializarlo. Es C y C++. También puedo cambiar la dirección a la que apuntan sin restricciones...
O puedo no liberar nunca memoria reservada (new o malloc)
¿ Sigue siendo así ?
porque básicamente cuando dicen que es un "sistema inseguro" se refieren a eso.
Desde hace 10 años o así salvo programadores de videojuegos o cosas como FFMPEG nadie gestiona la memoria a mano en C++...
Pero si siguen permitiéndose esas cosas que he indicado (y espero que sí) sigue siendo igual de inseguro. Que hayan incorporado medios para gestionar de otro modo la memoria no cambia nada.
Yo mismo he usado sistemas diseñados para lo mismo (como si fueran "microframework") en C... a costa de cierto rendimiento, claro.
Ya no necesitas hacer new y delete... simplemente haces std::make_unique o std::make_shared y tienes el objeto creado en memoria dinámica igual que si hicieras new o malloc y encima no tienes que hacer delete, el smart pointer se encarga de liberar la memoria por ti si se te pasa borrarla...
Eso sí, eso permite aumentar la presión de entrega,reducir los test y producir código funcional más rápido. Código de mierda, pero funcional.
Rust es una buena idea para grandes empresas de sistemas. Si se dispone de tiempo y no hay presión, C sirve.
Pero citar ahí a C# es como poner Java. Es un lenguaje "para otra cosa".
Ejemplo:
www.youtube.com/watch?v=kKZfGYvQ9kg
En este caso este software se ejecuta en paralelo y engarzado primero con la UEFI del sistema y luego con Windows 11 ( y su kernel NT ), ya no hablamos de un programa con su comienzo y final, monolitico,...
No quiero darmelas de nada pero... para sistemas, lo serio, C y ensamblador.
Puedes hacerlo con C++? Por supuesto, puedes usar uno de los últimos estandar, creo que desde C++11 ya tienes smart pointers, por ejemplo. Pero dependes de que el programador con el que trabajas tenga una buena forma de trabajar. No todo depende de que tú seas bueno, depende de que el equipo sea consistente con la seguridad.… » ver todo el comentario
Tiene un fuerte enfoque en no tener cosas ocultas, para que sea fácil saber qué significa lo que lees. Eso le quita alguna funcionalidad.
La comparación es con C
Sabes lo que aporta la orientación a objetos a la hora de desarrollar ???
Rust podría sustituir en todo caso a C. Jamás a C++.
Y realmente los leak de memoria se deben a las prisas o incompetencia de los programadores. Querer arreglar eso vía lenguaje de programación no me parece buena idea.
los leak de memoria se deben a las prisas o incompetencia de los programadores. Querer arreglar eso vía lenguaje de programación no me parece buena idea.
Se nota que eres un gran programador..... que jamás ha escrito una línea en condiciones.
Explicame que es eso de "un lenguaje inseguro".... si eres capaz....
Si no estás de acuerdo con lo que he afirmado será por algo más que por
Tu si que no debes tener ni 10 años...
Buenos argumentos.
Buenos son los que tú das: "Rust no puede sustituir a C++, sólo a C", "Python es una filfa de lenguaje", "los leaks de memoria en C y C++ es porque los programadores son incompetentes".
Todo porque lo dices tú. Qué sabrán los demás.
Se nota que eres un gran programador..... que jamás ha escrito una línea en condiciones.
Ya veo el tipo de programador que eres tú. Sin comentarios.
Rust podría sustituir en todo caso a C. Jamás a C++
Realmente aunque Rust no sea OOP es tan capaz o más para desarrollar lo mismo que un programa hecho en C++, y de estructurarlo de manera muy similar. Evidentemente cada lenguaje tiene que tener la implementación hecha a su manera, no puedes copiar la estructura de un programa hecho en Javascript y… » ver todo el comentario
Claro. Uno que ofrece grandes ventajas en muchos ámbitos. Por eso es la más usada.
. Los lenguajes funcionales, por ejemplo, no suelen usar la programación orientada a objetos
Casi todos los lenguajes oop tienen características que permiten cierto grado de programación funcional como las lambda
De hecho, hoy dia la programación orientada a objetos se considera algo desfasada
????
Quién la… » ver todo el comentario
Los lambda de Python comprados con CL o Scheme son un chiste.
Por eso son usados en muchos ámbitos y Scheme no.
Me gustaría verte desarrollar un programa de gestión con eso...
Los paradigmas tienen ámbitos de aplicación. Hay paradigmas más generales y paradigmas más específicos
Y tengo mas articulos por ahi. Son entornos poco de juguete, donde se exige una correctitud bestial y cosas que tardas un mes en CL tardas en C++ meses o si no anyos. De Python olvidate.
Ahora programa la gestión de un hotel con eso....
Los paradigmas tienen ámbitos de aplicación. Y los hay que se adaptan más a distintos ámbitos y los que se adaptan menos.
Cada vez más lenguajes implementan paradigmas funcionales (es lo que he dicho antes), pero en detrimento de nada.
Ningún lenguaje ha perdido ninguna característica OOP por ello.
A qué te refieres con "tipos inmutables"??
La programacion orientada a objetos hoy dia se considera casi obsoleta
Quién lo considera obsoleto y por qué ??
Diseña un programa de gestión sin OOP y me cuentas.
C se considera obsoleto
Quién lo considera obsoleto y basándose en qué??
Sólo puedes estar trolleando con semejante afirmación. No hay ninguna otra opción.
Porque en Rust puedes montar structs (como en C, si), e implementarlos con partes publicas y privadas, creando Traits para permitir a otros implementar ciertas funcionalidades, que bien podrían valer para hacer gran parte de lo que se hace en C++.
Sobre que los leak son por prisas o incompetencia. Si, claro, y eso es parte del mundo en el que vivimos, la gente la caga. Programando, conduciendo, pilotando, diagnosticando. Y si hay tecnología que puede reducir errores programando para tener menos bugs, conduciendo para tener menos muertos, o diagnosticando para pillar enfermedades antes, lo lógico es que se usen dichas herramientas.
No. C++ no es infumable. Otra cosa es la curva de aprendizaje si no vienes de C.
C++ es "el lenguaje".
El único problema aquí es que Rust es un lenguaje muy joven
El no ser orientado a objetos es un handicap enorme para convertirse en un lenguaje de desarrollo general. Compararlo con C++, Java o Python es un error. La comparación debe hacerse exclusivamente con C.
se acabó C++ porque quién va a querer hacer proyectos desde cero con un
… » ver todo el comentario
Disiento.
Y la experiencia demuestra que entre "más seguro" es el lenguaje, más mierda es el código.
Y peor aún, se pierden los buenos hábitos y se cogen vicios muy difícilmente corregibles.
El desplazar la seguridad al código puede hacer ahorrar dinero a la empresa, pero no lleva a código de más calidad. Todo lo contrario
Se perfectamente en qué consisten los fallos de gestión de memoria en C. Estoy cansado de pelearme con ellos.
Por eso es muy muy muy raro que los cometa. Pongo exquisito cuidado
El lenguaje no evitará que hagas chorradas en esas condiciones.
Eso sí, los errores con los punteros son infernales. Pocas bromas
¿?
Si se requieren permisos para algo es por una razón. No "por accidente". La necesidad de permisos para cualquier acción sobre el sistema no tiene nada que ver con el lenguaje con que esté implementado ese sistema ni con la arquitectura de su kernel.
Usa espacios de nombre, cosa que tambien puedes ver en plan9. Nada que ver con un Unix clasico.
En este aspecto no. No es diferente. Ni debe serlo.
No necesita permisos de root para montar discos,
Ni yo con GNU/Linux. En todo caso es una decisión de diseño del SO (una mala. debe poder restringirse el montaje)
ni para usar cosas analogas a FUSE
¿ Como cual ?
FUSE simplemente es un sistema de montaje a nivel de usuario.
para montar directorios remotos
Eso no tiene nada que ver con HURD. Tiene que ver con samba, nfs, ssh, iscsi.....
Usa espacios de nombre
Vaya, como GNU/Linux. O como crees que funciona LXC o Docker ?
Creo que no entiendes mucho de lo que hablas....
Si es diferente, y no has tocado una distro hurd un tu vida. Prueba a montar un FTP sin fuse y sin root en GNU o BSD y me comentas. Con hurd se puede con ftpfs ya que el propio diseño basado en servicios hace que los usuarios puedan tener sus propios directorios de montaje sin joder al resto.
Por cierto eso de ftpfs suena a sshfs
Yo lo uso y ya.
www.gnu.org/software/hurd/hurd/translator.html
Igualito que Linux o cualquier BSD con perms basados ya sea en grupos o en abortos como polkit, si, no veas.
En Linux yo.puedo montar lo que me de la gana siendo un simple usuario, o no. Según decida.
Espero que con Hurd sea igual... (Y lo será)
El tema de gestión de permisos es una simple cuestión de diseño del sistema. Nada más.
No tiene que ver con qué sea microkernel o no
Ahora comparalo con 9p en 9front y demas y tu cifrado al gusto encima.
> No tiene que ver con qué sea microkernel o no
En Hurd los demonios importan.
Además no entiendo el cambio de juego....
No estamos debatiendo sobre microkernel y kernels monolíticos.
Cuando Hurd sea verdaderamente funcional podremos hacer comparaciones fundamentadas
Ya hay motores de videojuegos desarrollados en Rust, pero creo que se está perdiendo el foco en la discusión en general respecto al lenguaje a utilizar para hacer videojuegos y el lenguaje del motor.
Godot está hecho en C/C++ pero puedes programar para él en muchos lenguajes, entre ellos Rust. El problema que no veo que nadie menciona es que para qué usar un lenguaje u otro.
A nivel de aficionado he… » ver todo el comentario