¿Rust sustituirá algún día a C?

[zShackra]

No termino de entender qué tiene que ver con lo que he comentado yo entre C y C++.

Tampoco recuerdo haber comentado nada acerca de la muerte de ningún lenguaje :S:S:S

Creo que lo tomaste en contra, y de hecho, el comentario mio fue apoyando el tuyo...

No veo porque un compilador de Rust no pueda crear codigo mas optimizado que un compilador de C/C++...
a si, será tal vez porque C se está utilizando hace años y hay millones de dolares invertidos en por ejemplo VC++ para que esté MUY BIEN optimizado?

Hay que invertir mucho tiempo para optimizar un compilador, y luego tambien está el problema que no todas las optimizaciones son "mejorias" para diferentes plataformas.

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

Yo no he dicho que en un futuro muy lejano pueda pasar... pero por ahora, Syntax Error.

Además, creo que estás confundiendo algunas cosas... VC++ no es el único compilador que hay... GCC es uno muy bueno.

No entiendo tu ira hacia C/C++ o los inversionistas de VC++... es un estupendo lenguaje, ¿por qué intentar compararlo con otros? Cada uno tiene lo suyo y aporta algo a la informática... aunque odie a VB, me temo que cada cual tiene sus pro y sus contra y en diferentes ambientes será mejor uno u otro... ¿por qué esa necesidad de decirle al mundo que debe existir un lenguaje maestro?... la informática aún está libre de dogmas y deidades...

[engel lex]

No veo porque un compilador de Rust no pueda crear codigo mas optimizado que un compilador de C/C++...

Mas optimizado.... no mas rapido...


El decir "que rust llegue a ser mas rapido que c" es un poco como tratar de decir "que sea mas rapido que asm" el trato de tan bajo nivel de C lleva a un manejo muy directo del procesador... y bueno seguir hablando sobre esto, seria repetir lo que ya dijeron...

Si, podría llegar cerca de la velocidad de c++ y tal vez para ciertas estructuras superarlo, pero si no tiene un nivel tan bajo nada se hace, y si se hace otro a nivel de c++ no es mas que un c++ con palabras y sintaxis diferentes, pero estructuras similares

[x64core]

Creo que lo tomaste en contra, y de hecho, el comentario mio fue apoyando el tuyo...

Yo no he dicho que en un futuro muy lejano pueda pasar... pero por ahora, Syntax Error.

Además, creo que estás confundiendo algunas cosas... VC++ no es el único compilador que hay... GCC es uno muy bueno.

Sí y es que nisiquiera leiste bien para darte cuenta de que digo:

por ejemplo VC++

No entiendo tu ira hacia C/C++ o los inversionistas de VC++... es un estupendo lenguaje, ¿por qué intentar compararlo con otros? Cada uno tiene lo suyo y aporta algo a la informática... aunque odie a VB, me temo que cada cual tiene sus pro y sus contra y en diferentes ambientes será mejor uno u otro... ¿por qué esa necesidad de decirle al mundo que debe existir un lenguaje maestro?... la informática aún está libre de dogmas y deidades...

¿Qué odio? Yo no veo odio en lo que dijo. Lo que veo yo es un punto de visto valido, lo siento si alguien no puede nisiquiera notarlo.

-

Mas optimizado.... no mas rapido...


El decir "que rust llegue a ser mas rapido que c" es un poco como tratar de decir "que sea mas rapido que asm" el trato de tan bajo nivel de C lleva a un manejo muy directo del procesador... y bueno seguir hablando sobre esto, seria repetir lo que ya dijeron...

Si, podría llegar cerca de la velocidad de c++ y tal vez para ciertas estructuras superarlo, pero si no tiene un nivel tan bajo nada se hace, y si se hace otro a nivel de c++ no es mas que un c++ con palabras y sintaxis diferentes, pero estructuras similares

engel lex, ¿Cómo es que podes llegar a comparar en la rapidez de código C con código ensamblador?

[engel lex]

Hey! :p no lo comparo directamente... por eso digo "es un poco como" haciendo referencia a lo bajo del nivel

[_Enko]

Mas optimizado.... no mas rapido...

Mh... si, es cierto, se puede tener un codigo objeto (ejecutable) más optimizada pero no necesariamente más  rápido para ejecutarse. (optimizacion en uso de memoria por ejemplo)

Pero la optimización que me refería es de velocidad de ejecucion, es decir que el compilador genere la minima cantidad de instrucciones en lenguaje máquina  necesarias para hacer lo que el programa indica y que lo haga utilizando aquellas instrucciones máquina que consuman la minima cantidad de ciclos reloj.
Eso es años de desarollo de un compilador, y en algunos compiladores de C han invertido años de trabajo, con lo que lleva unos costes impresionantes.

[eferion]

Creo que lo tomaste en contra, y de hecho, el comentario mio fue apoyando el tuyo...

Vale... es lo que tienen los foros... no suelen transmitir lenguaje no verbal .

En serio que es que no entendía la respuesta, pensaba que habías malinterpretado mi comentario o algo así, no se.

Mil disculpas por intentar liarte jejejeje.

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

Pues fíjate que no me lo creo. Los procesadores nuevos tienen características que no existían en los años 80. Por tanto los compiladores de esa época no están preparados para trabajar a nivel óptimo con los compiladores actuales y, en consecuencia, no van a poder aprovechar todo el potencial que ofrecen los equipos modernos.

[_Enko]

Pues fíjate que no me lo creo. Los procesadores nuevos tienen características que no existían en los años 80. Por tanto los compiladores de esa época no están preparados para trabajar a nivel óptimo con los compiladores actuales y, en consecuencia, no van a poder aprovechar todo el potencial que ofrecen los equipos modernos.

Pues me autocito xD

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

Cuando digo invertir tiempo, me refiero a  reiscribir el codigo del  compilador de QBasic... llamalo qBasic64 para plataforma de 64 bit inclusive y que incluya optimizaciones SSE3, SSE4 y demas.
(De lo contrario, de que inversión de tiempo podriamos estar hablando? era un compilador de 16bit, claramente requiere reescritura. Ejemplifiqué a QBasic porque es la cosa mas hororosa de los 80 que recuerdo... muy cerquita en el segundo lugar  el Turbo Cpp de Borland. O tal vez en el tercero? xD)

Si, es totalmente inutil y perdida de tiempo pero si posible.

A lo que voy, es que no se puede comparar la velocidad de lenguajes. Sino de ejecutables que genere un  compiladores. Un lenguaje no puede ser mas veloz que otro. Depende de las optimizaciones que tenga el compilador de dicho lenguaje.

[zShackra]

Vale... es lo que tienen los foros... no suelen transmitir lenguaje no verbal .

En serio que es que no entendía la respuesta, pensaba que habías malinterpretado mi comentario o algo así, no se.

Mil disculpas por intentar liarte jejejeje.

Tranquilo, no pasa nada... sí, esto de los foros suele prestarse a malinterpretaciones, nos leeremos luego.

Sí y es que nisiquiera leiste bien para darte cuenta de que digo:¿Qué odio? Yo no veo odio en lo que dijo. Lo que veo yo es un punto de visto valido, lo siento si alguien no puede nisiquiera notarlo.

¿Y a vos quién te preguntó algo? anda mejor a publicar más inmadureces en mi blog... y de paso te repasas las normas de ortografía, que te metes con mi interpretación de la gramática y no sabes ni siquiera escribir bien...

Y ya deja de citarme crío, que a ti no te pregunté ni te respondí nada.

[eferion]

Cuando digo invertir tiempo, me refiero a  reiscribir el codigo del  compilador de QBasic... llamalo qBasic64 para plataforma de 64 bit inclusive y que incluya optimizaciones SSE3, SSE4 y demas.

Eso es justamente lo que ha pasado con los compiladores que tienes hoy en día... han ido evolucionando a partir de lo que había en ese momento.

No puedo hablar de Basic porque no es mi campo y hace como que 15 años que no lo toco pero en C++ ha pasado justamente eso: El compilador C++ de gcc, por ejemplo, creo que nació en los 90... y desde entonces se le han ido aplicando mejoras y optimizaciones hasta llegar al día de hoy. Si me dices que un compilador de gcc de esa época era mejor que los de hoy en día entonces te digo con toda la tranquilidad del mundo que te equivocas.

Otra cosa que puede pasar es que estés más familiarizado con los compiladores de ese momento y sea más sencillo para ti usarlos, pero de ahí a afirmar que eran mejores que los que encuentras hoy en día...

[_Enko]

Otra cosa que puede pasar es que estés más familiarizado con los compiladores de ese momento y sea más sencillo para ti usarlos, pero de ahí a afirmar que eran mejores que los que encuentras hoy en día...

Ha, pero si yo nunca dije que QBasic es mejor que cualquier compilador de hoy dia de Cpp. Al contrario, recuerdo haber dicho que use qBasic como ejemplo de lo peor que haya existido.

Y creo que los dos estamos de acuerdo, en los compiladores modernos de cpp han invertido años de tiempo y dinero para que sean como son ahora.

Lo que en realidad discuto es que aqui se habló de que Rust es más rápido que Cpp. E insisto, ¿Como un lenguaje puede ser más rápido que otro en sentido que produce mejores ejecutables?
Cuando en realidad es el compilador de dicho lenguaje  que es el encargado de esa tarea.

En el campo practico,  no veo como un compilador de un lenguaje moderno puede crear aplicaciones más optimizadas que un compilador como Gcc, VC++ o Intel C++ (que tienen años de desarollo)
Pero en el campo teorico, hipotetico, no descarto dicha posibilidad.

Si se quiere comparar dos lenguajes, pues el parametro a mi criterio es la versatilidad por ejemplo. Pero de ninguna manera velocidad.

Saludos.