Adrianistán

El blog de Adrián Arroyo


Re: Rust no es un buen reemplazo de C

- Adrián Arroyo Calle

Como muchos ya sabéis, podéis contactar conmigo de muchas formas. De entre ellas, Lector anónimo eligió el correo para enviarme esta pregunta:

Hola.

Sigo tu blog desde hace algún tiempo y tienes un contenido interesante.
Soy aficionado a la programación y sé algo de Python. Estaba pensando en
aprender Rust. El caso es que leí un artículo y me gustaría saber tu
opinión, o sugerencia para que escribas algo en tu blog.

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html

Saludos.Lector anónimo.

Le respondí por correo pero os copio mi mensaje por si a alguno más le interesa:

Hola Lector anónimo,
 
Muchas gracias por seguir el blog, aunque no lo creas, me anima mucho conocer gente nueva que lo haga.
 
Respecto al artículo, me sonaba de haberlo leído antes (es de marzo así que es posible). No estoy de acuerdo en la mayoría de puntos aunque quizá el que más me moleste es el que no hay una especificación porque es una verdad a medias: no existe un estándar externo tipo ISO, ANSI o ECMA pero todos los cambios se someten a un proceso de RFC (https://github.com/rust-lang/rfcs/tree/master/text) que es el mismo que se usa en Internet y muy similar a las PEP de Python. Igualmente con lo de Cargo, por una vez que alguien hace algo decente en este campo con el tema de dependencias (que en C es un caos y realmente no se debería aspirar a eso).
 
Por otro lado, el tono general del artículo es que Rust es muy complejo y que C es más simple. Pero la cuestión de fondo, y que justifica en mi opinión la complejidad de Rust (la cuál no voy a negar) es que el problema que quiere resolver ES complejo y simplificarlo solo te puede llevar a dos opciones: no servir en todos los casos de uso o trasladar la complejidad a otro campo, que en el mundo de C, es la mente del programador que debe ser consciente de lo que hace.
 
Lo mismo con el tema de la concurrencia, si es complejo de hacer en C como el admite es porque es difícil y porque cuando se diseñó el lenguaje no era algo que se tuviese en cuenta (¿cuántos multicores había en los 70?), pero a diferencia de lo que él dice, sí merece la pena muchas veces usar diferentes hilos, sobre todo ahora en que los procesadores no aumentan su velocidad (incluso disminuye, por eficiencia energética) pero sí su número de cores.
 
Y luego finaliza con el tema de la seguridad que para él no es importante, pero ES importante, sobre todo ahora que el software puede provocar:
  • pérdidas de vidas humanas (piensa en los aviones, los coches autónomos o las herramientas médicas avanzadas)
  • hackeos, robos de datos y otro tipo de ataques en pleno auge de los ciberataques
En fin, yo he programado mucho en C y realmente me parece un buen lenguaje para su época, lo respeto mucho, pero creo que a día de hoy hemos avanzado algo y hemos encontrado cosas, que sí, pueden ser más complejas, pero resuelven de forma más correcta los problemas. Por eso si bien no soy partidario de iniciar proyectos nuevos en C, tampoco soy de esos que va pregonando que todo se reescriba en Rust jajaja.
 
Respecto a si debes aprenderlo... Bueno, eso es algo personal, yo lo probaría un poco y vería que tal. Laboralmente todavía no tiene mucho tirón (en mi trabajo por ejemplo no lo uso, aunque cada vez somos más los de la secta jejejeje) pero es muy interesante. Quizá todavía le falta algo de madurez pero con el tiempo llegará (así a lo tonto Python ya tiene 30 años por ejemplo y Rust no llega a 10 todavía).
 
Si tienes alguna duda más, no te cortes y pregúntame, veré que puedo hacer jajaja
 
Un saludo, Adrián

Comentarios

nasciiboy
tambien ley aquel post en su tiempo (rss)... lo que rescataria y se expone como punto principal es la forma en como se mejoran los lenguajes: o escribiendo mas codigo, o agregando mas caracteristicas si por algo (ignorando las necesesidades de su creacion) se caracteristizan c++, rust y python, es precisamente por el numero de caracteristicas que poseen y van agregando/cambiando. Agregar (muchas) caracteristicas no planeadas a un lenguaje/especificacion lo hace mas complejo? casi seguro que si

Añadir comentario

Todos los comentarios están sujetos a moderación