Incluso quienes llevaban tiempo elogiando y usando Rust dicen que cuando se topan con async les cae de golpe una fuerte dosis de realidad. Incluso están saliendo quejas de si acaso están diciendo que ni siquiera se deben crear librerías con Rust (porque es demasiado complejo, quisquilloso y difícil).
Hay gente que lo menosprecia sin siquiera saber quién es Mark Russinovich... es el autor de la suite de herramientas Sysinternals y del libro Windows Internals... es alguien que se convirtió en Microsoft Fellow después de hacer ingeniería inversa de Windows para crear herramientas...
Este es un argumento común, pero desde la perspectiva de alguien que ha leído muchas especificaciones y también ha hecho implementaciones varias veces, no estoy seguro de qué significa realmente, en sí mismo, que exista o no una especificación.
Hay varias estrategias para una "especificación". Está la forma de describir el comportamiento observable y la forma de describir el funcionamiento interno; también se divide entre usar lenguaje natural o usar un método legible por máquinas (como pseudocódigo o definiciones matemáticas). Cosas como la documentación de referencia del lenguaje Python o Rust son especificaciones que describen el comportamiento observable en lenguaje natural. Un enfoque que se ve a menudo en estándares ISO, etc., es una especificación que describe el funcionamiento interno en lenguaje natural, pero eso no garantiza que ese funcionamiento interno coincida con el enfoque de las implementaciones reales; en cambio, se define algo así como que, si una implementación hipotética construida con ese funcionamiento interno y una implementación real se comportan de manera idéntica en lo observable, observationally equivalent, entonces se considera conforme al estándar. ECMAScript, aunque está descrito en lenguaje natural, en su estructura real está prácticamente al nivel de pseudocódigo escrito en lenguaje natural, y también hay casos como WebAssembly, que ofrece tanto una especificación en lenguaje natural como una definición matemática del funcionamiento interno.
Desde el punto de vista de la implementación, las especificaciones en lenguaje natural son más o menos lo mismo. Como una especificación en lenguaje natural tiene que producirse por separado de la implementación real, naturalmente puede ocurrir que ambas se distancien entre sí, y también es común que haya errores. Si es más fácil implementar a partir del comportamiento observable o a partir del funcionamiento interno depende de la situación, pero desde la perspectiva de un lenguaje de programación no hay realmente una razón obligatoria para elegir uno u otro. En ese sentido, Rust ya tiene una especificación, y es correcto decir que esa especificación proporciona información suficiente como para que puedan surgir otras implementaciones alternativas.
Si simplemente quiere juzgar la madurez de un estándar por si llegó o no a convertirse en un estándar ISO, le comparto la noticia de que yo encontré alrededor de 100 errores en el estándar ISO/IEC 18181-1 JPEG XL (y por eso se está retrasando la 2nd amendment)...
Muchas gracias por su esfuerzo.
Por otro lado... vi un texto que decía que hay que tener cuidado de atribuirlo a la personalidad de alguien cuando se intenta interpretar su reacción cuando atacan algo que le gusta, y me pareció una buena observación, porque probablemente se debe a que en una situación real es difícil mantener ese tipo de disposición mental.
Una cosa más. La gente que usaba C++ y se la pasaba sacando errores y metiendo bugs, luego dice: “oye, esto no sirve, mejor vámonos a Rust, que dicen que está de moda... que ni siquiera hay que preocuparse por los errores de memoria...”. Esa gente es igual. También van a terminar creando bugs parecidos con Rust... y después muchos van a decir otra vez: “¿qué otro lenguaje aprendemos ahora para probar?”. Son personas que en C++ ni siquiera han manejado bien la desreferenciación de punteros y aun así se la pasan idolatrando Rust.
Ese tipo de gente va a ignorar por completo cosas como ownership, references y borrowing, que Rust presenta como fortalezas, porque desde la compilación les tiran errores y les complican la vida, y al final van a mezclar unsafe y usarlo a lo bruto como si fuera C++.
Se siente como ver el argumento de que, total, la gente que causa accidentes tampoco se pone el cinturón de seguridad ni respeta los semáforos, así que el cinturón y los semáforos no tienen mucho sentido.
Se puede decir que la gente capaz hará bien las cosas haga lo que haga, y la que no es capaz lo hará mal haga lo que haga, pero si seguimos esa lógica ya no se puede sostener una discusión sobre la utilidad de las herramientas.
Parece que C/C++ de verdad ya va camino a convertirse en latín. Si es por motivos académicos, cualquiera debería estudiarlo, pero dominarlo es casi imposible y, al ser un sistema antiguo, también tiene muchas partes que hoy en día resultan poco razonables...
Es curioso que usen sin problema lenguajes en los que todo es unsafe, pero digan que un lenguaje donde unsafe solo se puede usar de forma limitada es absolutamente inaceptable.
1. Confía en el programador.
2. No impidas que el programador haga lo que necesita hacer.
3. Mantén el lenguaje pequeño y simple.
4. Proporciona una sola forma de hacer una operación.
5. Hazlo rápido, incluso si no se garantiza que sea portable.
Con C++ también basta con usar activamente smart pointers y memory pools, así que...
Creo que, más de lo que uno piensa, no hay tantas ocasiones en las que haya que manipular punteros directamente.
Yo creo que el código thread-safe al final depende de la capacidad del propio programador.
Sin importar qué lenguaje uses,
si no tienes buen nivel, terminas mostrando patrones de código seguro pero de rendimiento pobre, o código riesgoso.
El código thread-safe al final depende de la capacidad del propio programador <- yo considero peligrosa esa idea, porque la seguridad de memoria y de hilos no está simplemente en el nivel de que el programa se caiga o se vuelva lento, sino que puede convertirse en una vulnerabilidad de seguridad, así que no creo que esto deba dejarse en manos de la capacidad de una sola persona.
Se han investigado diversos métodos para prevenir esto de antemano, y al madurar dieron origen a lenguajes como Rust y otras herramientas; creo que el impacto del software en la vida cotidiana se ha vuelto demasiado grande como para no usar eso y echarle la culpa al individuo.
La gente, por ser humana, inevitablemente puede cometer errores, y por más inteligente que sea un programador, también terminará equivocándose. Los bugs de memoria al final también surgen de esos errores...
Últimamente, en vez de confiar en que las cosas se hagan bien por sí solas, quizás sea un mejor enfoque ofrecer desde el principio un entorno en el que sea difícil cometer errores.
Si quisiéramos usar Rust en nuestra empresa, estaría prohibido usar unsafe. Tiene que haber al menos una regla así para poder confiar, aunque sea una vez, en la seguridad que el lenguaje ofrece a nivel de diseño. Pero, ¿de verdad esto tiene sentido?
Por supuesto, en las empresas que usan Rust seguramente habrá un consenso de que no se debe usar unsafe salvo cuando sea realmente necesario. Más que eso, les recomiendo que prueben a programar directamente en Rust... ¿No creen que solo usándolo ustedes mismos podrán saber con qué frecuencia realmente necesitarán usar unsafe?
Parece que hay bastantes comentarios que ven esto como algo de todo o nada, como si si no es All entonces no tuviera ningún valor.
Tiene la ventaja de que se puede distinguir y aislar explícitamente entre unsafe y safe, y de que una persona que cometería 100 bugs de memoria puede pasar a cometer 10; pero aun así, como existe unsafe / de todos modos ocurren bugs de memoria => por lo tanto no es mejor que C++, no sé muy bien si esa forma de verlo sea un juicio realista 😅
Por la cantidad de comentarios, sí parece ser así.....
Da la impresión de que la situación correcta sería: hay muchos comentarios escritos por una persona con una opinión de todo o nada...
Yo también estoy de acuerdo con este comentario. Cuanto más se ve algo de forma dicotómica, al final el único que sale perdiendo es uno mismo.
En el trabajo real, lo normal es evaluar pros y contras y elegir lo que al final da el mayor beneficio. Por las características de la industria, si no es que ahora mismo no queda otra que usar C/C++, creo que las ventajas de usar Rust son grandes, y por eso poco a poco se están ampliando las áreas donde se usa Rust.
La gente que se está pasando a Rust tampoco es tonta; si lo siguen usando, será porque al probar Rust vieron que, en términos de resultados, tiene cosas mejores que C++ jaja
Ya casi queda poca gente que no esté de acuerdo con que Rust es el próximo C++. Incluso fue adoptado como lenguaje oficial en el kernel de Linux.
Aun así, me queda la duda de si Rust realmente es un lenguaje cómodo de usar... Gracias al análisis estático que realiza para prevenir de antemano la seguridad de memoria, los tiempos de compilación duelen bastante, y como semánticas como ownership son difíciles, exige mucho más estudio que lenguajes de propósito general como Python o Java.
El tiempo de compilación probablemente sea en gran parte un problema de LLVM en sí. Facebook está esforzándose por mejorar el instruction selection de LLVM, así que la situación debería mejorar.
Busqué un poco y de verdad parece que sí. Yo pensaba que se invertía mucho tiempo en la verificación de tipos relacionada con ownership, pero el backend de LLVM es grande..
Cuando salió Rust por primera vez, me interesó muchísimo y me puse a estudiarlo un poco... pero en cuanto vi la parte de unsafe, lo dejé de inmediato. Sinceramente no me parecía que hubiera una justificación racional para aprenderlo y usarlo. Al final, cualquier programa que sea un poco complejo termina necesitando unsafe. Y entonces, la seguridad de la que Rust presume tanto se va por la borda. ¿Para qué usarlo?
En Rust, unsafe solo suele ser necesario al hacer programación de bajo nivel; para escribir aplicaciones comunes, prácticamente puede asumirse que casi no habrá que usarlo.
Y aunque ocurra un problema de memoria dentro de un bloque unsafe, el lenguaje garantiza que la parte problemática está dentro de ese bloque unsafe, así que también tiene la ventaja de facilitar la depuración.
C++ también sigue evolucionando y, si igual voy a usar algo unsafe, entonces mejor uso C++; sinceramente no siento la necesidad de aprender y usar Rust a propósito.
No toda la programación en Rust requiere unsafe.
La manipulación de memoria tan delicada como para necesitar unsafe normalmente queda del lado del desarrollo de librerías, así que creo que en el desarrollo de aplicaciones, que probablemente es donde habrá más demanda, casi no habrá ocasiones para usar unsafe.
También es cierto que C++ sigue evolucionando, pero el legado para mantener la compatibilidad hacia atrás pesa muchísimo. Si unsafe por sí solo ya le parece motivo de queja, entonces creo que le van a desagradar todas las funciones de C++ jaja
Ojalá el FFI fuera un poco más amigable... Recuerdo que intenté intercambiar estructuras compuestas con bibliotecas externas a través de FFI y fue una experiencia realmente dolorosa.
Los bugs relacionados con la memoria no van a desaparecer solo por usar Rust. La gente que crea bugs los va a seguir produciendo sin importar qué lenguaje les des. Estamos usando C++ sin ningún problema y de forma eficiente, así que ¿qué van a eliminar y por qué? De verdad soltó una declaración explosiva a la ligera, de esas que desatan una guerra.
Decir que C/C++ se ha usado de forma eficiente y sin ningún problema es difícil, considerando que históricamente han surgido muchísimos bugs relacionados con memoria en C/C++, y probablemente incluso ahora mismo estén ocurriendo en algún lugar. (Aunque gracias a eso muchos investigadores de PL/SE han podido ganarse la vida).
Según el anuncio de Microsoft, el 70% de los bugs de seguridad están relacionados con memoria (https://zdnet.com/article/…)
Lo que investigó el proyecto Chromium es similar (https://www.chromium.org/Home/chromium-security/memory-safety/): de nuevo, casi el 70% eran bugs relacionados con memoria.
La mayoría de los bugs del kernel de Windows son errores relacionados con la memoria, y recuerdo haber visto en algún lado un artículo anterior que decía que en las partes que están desarrollando con Rust esos errores se redujeron drásticamente..
Como el propio lenguaje fue diseñado recomendando activamente readonly, parece difícil negar que tiene un diseño a nivel de lenguaje más seguro que C++. Aunque por eso mismo aparece ese concepto de propiedad que nadie había visto ni oído antes, y programar se vuelve más difícil.
También está la ventaja de rendimiento de que, estadísticamente, un código en Rust hecho más o menos a la ligera puede ejecutarse más rápido que un código en C++ muy bien diseñado.
Parece que dijo algo que podría desatar polémica. jaja
En lo personal, como C++ ya tiene demasiados años, siento que su compatibilidad hacia atrás le pone trabas y hace que evolucione con lentitud de una forma más moderna.
Además, al mantener esa compatibilidad hacia atrás de manera tan estricta mientras se le agregan cosas modernas, terminan existiendo demasiadas formas de hacer lo mismo, y creo que eso se vuelve una barrera de entrada aún mayor para la gente nueva.
Yo también creo que a estas alturas Rust es mejor que C++. Ya es hora de dejar atrás aquellos tiempos de terminar con los ojos rojos buscando bugs relacionados con la gestión de memoria.
Aunque quiera usar Rust, por ahora solo lo uso de forma complementaria; en el trabajo todavía no me toca usarlo realmente.
Por eso no termino de familiarizarme, y si lo dejo un rato también se me olvida...
Está claro que me gusta y sí quiero usarlo... jaja
Los que nunca han escrito ni una sola vez un pool de memoria para mejorar la eficiencia del uso del heap se la pasan hablando de RUST, jajaja.
Azure CTO no es alguien cuya opinión represente tanto como para ser un estándar de la industria; por supuesto, ni siquiera dentro de Microsoft es una opinión que represente la postura de MS, sino que no pasa de ser alguien que de repente se dejó llevar por algo y anda soltando su pensamiento subjetivo... ¿Los que ni siquiera saben usar bien C++ sí van a hacerlo bien con Rust? En fin, está lleno de puro hablador.
55 comentarios
Incluso quienes llevaban tiempo elogiando y usando Rust dicen que cuando se topan con
asyncles cae de golpe una fuerte dosis de realidad. Incluso están saliendo quejas de si acaso están diciendo que ni siquiera se deben crear librerías con Rust (porque es demasiado complejo, quisquilloso y difícil).Hay gente que lo menosprecia sin siquiera saber quién es Mark Russinovich... es el autor de la suite de herramientas Sysinternals y del libro Windows Internals... es alguien que se convirtió en Microsoft Fellow después de hacer ingeniería inversa de Windows para crear herramientas...
Un post que se burla de los problemas de los superfans de Rust con un video corto
https://twitter.com/cmuratori/status/1367627549816152064?lang=en
Rust ni siquiera tiene una especificación formal todavía...
C++ tiene una spec formal que sí "existe", pero todas las implementaciones (
gcc,clang, ...) están incompletas.Este es un argumento común, pero desde la perspectiva de alguien que ha leído muchas especificaciones y también ha hecho implementaciones varias veces, no estoy seguro de qué significa realmente, en sí mismo, que exista o no una especificación.
Hay varias estrategias para una "especificación". Está la forma de describir el comportamiento observable y la forma de describir el funcionamiento interno; también se divide entre usar lenguaje natural o usar un método legible por máquinas (como pseudocódigo o definiciones matemáticas). Cosas como la documentación de referencia del lenguaje Python o Rust son especificaciones que describen el comportamiento observable en lenguaje natural. Un enfoque que se ve a menudo en estándares ISO, etc., es una especificación que describe el funcionamiento interno en lenguaje natural, pero eso no garantiza que ese funcionamiento interno coincida con el enfoque de las implementaciones reales; en cambio, se define algo así como que, si una implementación hipotética construida con ese funcionamiento interno y una implementación real se comportan de manera idéntica en lo observable,
observationally equivalent, entonces se considera conforme al estándar. ECMAScript, aunque está descrito en lenguaje natural, en su estructura real está prácticamente al nivel de pseudocódigo escrito en lenguaje natural, y también hay casos como WebAssembly, que ofrece tanto una especificación en lenguaje natural como una definición matemática del funcionamiento interno.Desde el punto de vista de la implementación, las especificaciones en lenguaje natural son más o menos lo mismo. Como una especificación en lenguaje natural tiene que producirse por separado de la implementación real, naturalmente puede ocurrir que ambas se distancien entre sí, y también es común que haya errores. Si es más fácil implementar a partir del comportamiento observable o a partir del funcionamiento interno depende de la situación, pero desde la perspectiva de un lenguaje de programación no hay realmente una razón obligatoria para elegir uno u otro. En ese sentido, Rust ya tiene una especificación, y es correcto decir que esa especificación proporciona información suficiente como para que puedan surgir otras implementaciones alternativas.
Si simplemente quiere juzgar la madurez de un estándar por si llegó o no a convertirse en un estándar ISO, le comparto la noticia de que yo encontré alrededor de 100 errores en el estándar ISO/IEC 18181-1 JPEG XL (y por eso se está retrasando la 2nd amendment)...
En Hacker News también hubo más de 800 comentarios... aquí también está candente...
https://news.ycombinator.com/item?id=32905885
Muchas gracias por su esfuerzo.
Por otro lado... vi un texto que decía que hay que tener cuidado de atribuirlo a la personalidad de alguien cuando se intenta interpretar su reacción cuando atacan algo que le gusta, y me pareció una buena observación, porque probablemente se debe a que en una situación real es difícil mantener ese tipo de disposición mental.
Hay un comentario en el tuit que me pareció impresionante.
People end up writing Rust code the "unsafe way". - omitido - Rust was never meant to replace those.
A estas alturas, dejo un enlace para quienes quieran saber quién es Mark Russinovich.
https://en.m.wikipedia.org/wiki/Mark_Russinovich
Una cosa más. La gente que usaba C++ y se la pasaba sacando errores y metiendo bugs, luego dice: “oye, esto no sirve, mejor vámonos a Rust, que dicen que está de moda... que ni siquiera hay que preocuparse por los errores de memoria...”. Esa gente es igual. También van a terminar creando bugs parecidos con Rust... y después muchos van a decir otra vez: “¿qué otro lenguaje aprendemos ahora para probar?”. Son personas que en C++ ni siquiera han manejado bien la desreferenciación de punteros y aun así se la pasan idolatrando Rust.
Ese tipo de gente va a ignorar por completo cosas como ownership, references y borrowing, que Rust presenta como fortalezas, porque desde la compilación les tiran errores y les complican la vida, y al final van a mezclar
unsafey usarlo a lo bruto como si fuera C++.Total, de todos modos te vas a morir, ¿para qué vivir?
Es una lógica casi del mismo nivel que esa.
Se siente como ver el argumento de que, total, la gente que causa accidentes tampoco se pone el cinturón de seguridad ni respeta los semáforos, así que el cinturón y los semáforos no tienen mucho sentido.
Se puede decir que la gente capaz hará bien las cosas haga lo que haga, y la que no es capaz lo hará mal haga lo que haga, pero si seguimos esa lógica ya no se puede sostener una discusión sobre la utilidad de las herramientas.
El problema es que el lenguaje es demasiado difícil de usar, pero sí, es cierto.
Lo creeré cuando salga Visual Rust ¬.¬ jaja
Parece que C/C++ de verdad ya va camino a convertirse en latín. Si es por motivos académicos, cualquiera debería estudiarlo, pero dominarlo es casi imposible y, al ser un sistema antiguo, también tiene muchas partes que hoy en día resultan poco razonables...
Es curioso que usen sin problema lenguajes en los que todo es
unsafe, pero digan que un lenguaje dondeunsafesolo se puede usar de forma limitada es absolutamente inaceptable.Creo que es una especie de síndrome de Estocolmo.
El espíritu de C
En mi opinión personal, creo que el punto 1 ya está equivocado jaja, porque las personas son propensas a cometer errores por naturaleza..
Con C++ también basta con usar activamente smart pointers y memory pools, así que...
Creo que, más de lo que uno piensa, no hay tantas ocasiones en las que haya que manipular punteros directamente.
Yo creo que el código thread-safe al final depende de la capacidad del propio programador.
Sin importar qué lenguaje uses,
si no tienes buen nivel, terminas mostrando patrones de código seguro pero de rendimiento pobre, o código riesgoso.
Da demasiado miedo dejar la conducción de un auto o de un avión en manos de la habilidad de un programador....
El código thread-safe al final depende de la capacidad del propio programador <- yo considero peligrosa esa idea, porque la seguridad de memoria y de hilos no está simplemente en el nivel de que el programa se caiga o se vuelva lento, sino que puede convertirse en una vulnerabilidad de seguridad, así que no creo que esto deba dejarse en manos de la capacidad de una sola persona.
Se han investigado diversos métodos para prevenir esto de antemano, y al madurar dieron origen a lenguajes como Rust y otras herramientas; creo que el impacto del software en la vida cotidiana se ha vuelto demasiado grande como para no usar eso y echarle la culpa al individuo.
La gente, por ser humana, inevitablemente puede cometer errores, y por más inteligente que sea un programador, también terminará equivocándose. Los bugs de memoria al final también surgen de esos errores...
Últimamente, en vez de confiar en que las cosas se hagan bien por sí solas, quizás sea un mejor enfoque ofrecer desde el principio un entorno en el que sea difícil cometer errores.
Si quisiéramos usar Rust en nuestra empresa, estaría prohibido usar
unsafe. Tiene que haber al menos una regla así para poder confiar, aunque sea una vez, en la seguridad que el lenguaje ofrece a nivel de diseño. Pero, ¿de verdad esto tiene sentido?Por supuesto, en las empresas que usan Rust seguramente habrá un consenso de que no se debe usar
unsafesalvo cuando sea realmente necesario. Más que eso, les recomiendo que prueben a programar directamente en Rust... ¿No creen que solo usándolo ustedes mismos podrán saber con qué frecuencia realmente necesitarán usarunsafe?En bibliotecas conocidas como tokio, lo llenaron de
unsafe.Parece que hay bastantes comentarios que ven esto como algo de todo o nada, como si si no es All entonces no tuviera ningún valor.
Tiene la ventaja de que se puede distinguir y aislar explícitamente entre
unsafeysafe, y de que una persona que cometería 100 bugs de memoria puede pasar a cometer 10; pero aun así, como existeunsafe/ de todos modos ocurren bugs de memoria => por lo tanto no es mejor que C++, no sé muy bien si esa forma de verlo sea un juicio realista 😅Por la cantidad de comentarios, sí parece ser así.....
Da la impresión de que la situación correcta sería: hay muchos comentarios escritos por una persona con una opinión de todo o nada...
Yo también estoy de acuerdo con este comentario. Cuanto más se ve algo de forma dicotómica, al final el único que sale perdiendo es uno mismo.
En el trabajo real, lo normal es evaluar pros y contras y elegir lo que al final da el mayor beneficio. Por las características de la industria, si no es que ahora mismo no queda otra que usar C/C++, creo que las ventajas de usar Rust son grandes, y por eso poco a poco se están ampliando las áreas donde se usa Rust.
La gente que se está pasando a Rust tampoco es tonta; si lo siguen usando, será porque al probar Rust vieron que, en términos de resultados, tiene cosas mejores que C++ jaja
Nada... Todo
Ya casi queda poca gente que no esté de acuerdo con que Rust es el próximo C++. Incluso fue adoptado como lenguaje oficial en el kernel de Linux.
Aun así, me queda la duda de si Rust realmente es un lenguaje cómodo de usar... Gracias al análisis estático que realiza para prevenir de antemano la seguridad de memoria, los tiempos de compilación duelen bastante, y como semánticas como
ownershipson difíciles, exige mucho más estudio que lenguajes de propósito general como Python o Java.El tiempo de compilación probablemente sea en gran parte un problema de LLVM en sí. Facebook está esforzándose por mejorar el instruction selection de LLVM, así que la situación debería mejorar.
Busqué un poco y de verdad parece que sí. Yo pensaba que se invertía mucho tiempo en la verificación de tipos relacionada con ownership, pero el backend de LLVM es grande..
Cuando salió Rust por primera vez, me interesó muchísimo y me puse a estudiarlo un poco... pero en cuanto vi la parte de
unsafe, lo dejé de inmediato. Sinceramente no me parecía que hubiera una justificación racional para aprenderlo y usarlo. Al final, cualquier programa que sea un poco complejo termina necesitandounsafe. Y entonces, la seguridad de la que Rust presume tanto se va por la borda. ¿Para qué usarlo?En Rust,
unsafesolo suele ser necesario al hacer programación de bajo nivel; para escribir aplicaciones comunes, prácticamente puede asumirse que casi no habrá que usarlo.Y aunque ocurra un problema de memoria dentro de un bloque
unsafe, el lenguaje garantiza que la parte problemática está dentro de ese bloqueunsafe, así que también tiene la ventaja de facilitar la depuración.Si van a preguntar, por existir
unsafe, "¿para qué usar esto?", entonces de entrada no deberían usar C/C++, ¿no?C++ también sigue evolucionando y, si igual voy a usar algo
unsafe, entonces mejor uso C++; sinceramente no siento la necesidad de aprender y usar Rust a propósito.No toda la programación en Rust requiere
unsafe.La manipulación de memoria tan delicada como para necesitar
unsafenormalmente queda del lado del desarrollo de librerías, así que creo que en el desarrollo de aplicaciones, que probablemente es donde habrá más demanda, casi no habrá ocasiones para usarunsafe.También es cierto que C++ sigue evolucionando, pero el legado para mantener la compatibilidad hacia atrás pesa muchísimo. Si
unsafepor sí solo ya le parece motivo de queja, entonces creo que le van a desagradar todas las funciones de C++ jajaPor eso no se recomienda
unsafe.Si usas
safe, todo es más seguro que C/C++, donde todo es prácticamente lo mismo queunsafe.https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
Si no existiera ese mecanismo ambiguo llamado
unsafe, Rust podría llegar a ser una verdadera alternativa a C++.Ojalá el FFI fuera un poco más amigable... Recuerdo que intenté intercambiar estructuras compuestas con bibliotecas externas a través de FFI y fue una experiencia realmente dolorosa.
Incluso de Rust a Rust tampoco es tan fácil..
https://github.com/rodrimati1992/abi_stable_crates
Parece una declaración muy natural si se la ve como una extensión de la situación actual, en la que Microsoft está apoyando activamente a Rust.
Hasta ese terco de Torvalds adoptó Rust, así que no le veo sentido a seguir usando a propósito un lenguaje que cada vez menos gente aprende.
Los bugs relacionados con la memoria no van a desaparecer solo por usar Rust. La gente que crea bugs los va a seguir produciendo sin importar qué lenguaje les des. Estamos usando C++ sin ningún problema y de forma eficiente, así que ¿qué van a eliminar y por qué? De verdad soltó una declaración explosiva a la ligera, de esas que desatan una guerra.
Decir que C/C++ se ha usado de forma eficiente y sin ningún problema es difícil, considerando que históricamente han surgido muchísimos bugs relacionados con memoria en C/C++, y probablemente incluso ahora mismo estén ocurriendo en algún lugar. (Aunque gracias a eso muchos investigadores de PL/SE han podido ganarse la vida).
Según el anuncio de Microsoft, el 70% de los bugs de seguridad están relacionados con memoria (https://zdnet.com/article/…)
Lo que investigó el proyecto Chromium es similar (https://www.chromium.org/Home/chromium-security/memory-safety/): de nuevo, casi el 70% eran bugs relacionados con memoria.
La mayoría de los bugs del kernel de Windows son errores relacionados con la memoria, y recuerdo haber visto en algún lado un artículo anterior que decía que en las partes que están desarrollando con Rust esos errores se redujeron drásticamente..
Como el propio lenguaje fue diseñado recomendando activamente
readonly, parece difícil negar que tiene un diseño a nivel de lenguaje más seguro que C++. Aunque por eso mismo aparece ese concepto de propiedad que nadie había visto ni oído antes, y programar se vuelve más difícil.También está la ventaja de rendimiento de que, estadísticamente, un código en Rust hecho más o menos a la ligera puede ejecutarse más rápido que un código en C++ muy bien diseñado.
Parece que dijo algo que podría desatar polémica. jaja
En lo personal, como C++ ya tiene demasiados años, siento que su compatibilidad hacia atrás le pone trabas y hace que evolucione con lentitud de una forma más moderna.
Además, al mantener esa compatibilidad hacia atrás de manera tan estricta mientras se le agregan cosas modernas, terminan existiendo demasiadas formas de hacer lo mismo, y creo que eso se vuelve una barrera de entrada aún mayor para la gente nueva.
Yo también creo que a estas alturas Rust es mejor que C++. Ya es hora de dejar atrás aquellos tiempos de terminar con los ojos rojos buscando bugs relacionados con la gestión de memoria.
Sí, exacto... si es un proyecto de desarrollo que empieza desde cero, no hay realmente una razón para elegir C++ a la fuerza..
Totalmente de acuerdo
Aunque quiera usar Rust, por ahora solo lo uso de forma complementaria; en el trabajo todavía no me toca usarlo realmente.
Por eso no termino de familiarizarme, y si lo dejo un rato también se me olvida...
Está claro que me gusta y sí quiero usarlo... jaja
Los que nunca han escrito ni una sola vez un pool de memoria para mejorar la eficiencia del uso del heap se la pasan hablando de RUST, jajaja. Azure CTO no es alguien cuya opinión represente tanto como para ser un estándar de la industria; por supuesto, ni siquiera dentro de Microsoft es una opinión que represente la postura de MS, sino que no pasa de ser alguien que de repente se dejó llevar por algo y anda soltando su pensamiento subjetivo... ¿Los que ni siquiera saben usar bien C++ sí van a hacerlo bien con Rust? En fin, está lleno de puro hablador.
Desde la manera en que habla deja ver su vulgaridad sin ningún disimulo. Ánimo.