EDICIóN GENERAL
68 meneos
1298 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear

Intel: "Rust es el futuro de la programación de sistemas, C es el nuevo ensamblador" [ENG]

la Open Source Technology Summit (OSTS) 2019, Josh Triplett, un ingeniero principal de Intel, dio una idea de lo que Intel está contribuyendo a que el lenguaje más querido, Rust, alcance la plena paridad con C. En su charla titulada Intel y Rust: el futuro de la programación de sistemas, también habló sobre la historia de la programación de sistemas, cómo C se convirtió en el lenguaje de programación de sistemas "predeterminado", qué características de Rust le confieren una ventaja sobre C, y mucho más.

| etiquetas: rust , intel , josh triplett , charla
"Rust addresses the memory management problem in C"

C no tiene ningún problema con la gestión de memoria. Lo que pasa es que C es superpoderoso, te da la herramienta para hacerlo todo. Y con gran poder viene gran responsabilidad. Si luego los programadores son incapaces de devolver la memoria que piden o se pierden con los punteros no es problema del C, es de la capacidad del programador. Si, los programadores son humanos, pero para eso estan los warnings.

Los lenguajes no se han…   » ver todo el comentario
#15 Aunque estoy de acuerdo contigo en que el auténtico problema de la gestión de memoria en C está en los despistes del programador, no es menos cierto que al final las rutinas eran muy tediosas de programar: reservar memoria, hacer algo con las variables de tamaño variable, liberar memoria; cuando de eso puede encargarse automáticamente otro algoritmo que hace siempre lo mismo. Pierdes el potencial de gestionar tú mismo la memoria de un modo sencillo (aunque si quieres hacerlo, los lenguajes…   » ver todo el comentario
#22 A mí personalmente me parece como comprarse un superdeportivo y limitar la aceleración..
#27 Más bien como hacerte tus propias tuberías o comprarlas pre montadas del leroi merlín. Con las tuyas tienes las medidas exactas, pero tienes que soldarlo todo, un codo mal soldado y tenemos una inundación. Con las de leroy no hay fugas, pero dependes de medidas standard y te tienes que adaptar a lo que leroy tiene.
#27 Casi todos los deportivos nuevos, tienen control de traccion, ABS y ESP y alguno menos Launch control. Ademas tiene corte de inyeccion cuanto te pasas de rpm y los automaticos cambian de marcha solo si te pasas de revoluciones aunque estes en modo manual.

En seguridad hay muchs resctriciones alguna no perjudican nada porque evitan ir por donde no necesitas ir. Algunas son mas intrusivas, pero o en muchos sistemas se procura que si falla una sistema de seguridad haya otro detras o varios e impedir que factor humano pueda crear un problema,.
#22 Ese "eran" de la primera frase se me ha clavao en el alma. :'(

Tienes razón, todos tenéis razón, ya se trata de gustos y filosofías. Yo prefiero tener callos en los dedos de liberar memoria y tener el control, porque de darte cabezazos acabas teniendo un conocimiento avanzado del sistema. Con el otro sistema creamos juniors y seniors, pero no expertos.
#15 Amén. Palabra del senor.
#15 No, lo que estamos haciendo no es normalizar la pereza y el descuido. Lo que estamos haciendo es ser más productivos.

Hace décadas lo caro eran los ordenadores y lo barato los programadores los cuales tenían que afinar sus programas porque los ordenadores no daban más de sí. Ahí un Ensamblador o un C era la apuesta necesaria.

Hoy en día sucede a la inversa, lo barato son los ordenadores y lo caro son los programadores. Como además los ordenadores son órdenes de magnitud más potentes…   » ver todo el comentario
#26 Evidentemente estamos cambiando habilidad por potencia y libertad por vigilancia, y el coste es desgraciadamente un factor muy importante. Pero me gustaba la humanidad cuando la habilidad, el esfuerzo y la inteligencia contaban más.
#29 Cuando los hombres eran hombres y se programaban sus propios drivers.
#26 no estoy seguro de que sea un tema solo de productividad, sino de que hay muchos programadores que no saben informática. Saben programar solamente; pero no tienen ni idea ni de lo que es la memoria de intercambio, por poner un ejemplo.

No creo que un buen programador (que sabe de informática) sea mucho más ineficiente en C que en un lenguaje de estos. El problema a veces es que hay programadores que vienen del mundo de los scripts o de las páginas web y cuando ven un puntero les da un síncope.
#36 Ese es otro tema y tienes razón, para que alguien pueda denominarse "desarrollador" o "programador" debería tener conocimiento desde cómo funciona un procesador con sus registros y sus cosas y de ahí hacia arriba en todas las capas, comunicaciones, hilos, sistema operativo. Luego puedes centrarte en una parte pero debes saber que hay un bosque alrededor de tu árbol.
#15 C no es superpoderoso porque C no gestiona la memoria.

Los superpoderosos son los programadores que tienen que lidiar con esas tareas. Y el software desarrollado, que es obviamente rápido.

Los lenguajes son herramientas para desarrollar productos vendibles, usables y seguros. Las mejores herramientas son las que te permiten hacer más trabajo con mayor seguridad en mejor tiempo. Por lo tanto, los lenguajes han ido claramente a mejor.

Lo que tú comentas es más programar por afición. Como quien se construye un coche en un garaje.
#35 C es SUPERpoderoso, porque el programador decide como gestionar la memoria. Otra cosa es que sepa como hacerlo eficientemente...
#46 Hoy en dia se suple tiempo de programacion con hardware mas potente. Se pierde menos tiempo en optimizar y usando L de alto nivel. Es mas barato el hardware que la hora de programador.

Tambien es un problema por supone mas gasto energetico.
cppcms.com/wikipp/en/page/rationale
#80 no en proyectos como el kernel de linux, o embebidos, donde la optimización del código se realiza de forma rutinaria, o en gestión de servidores.

Pero el problema de verdad es que se está perdiendo el contacto con el paradigma. Imagina que seguimos por este camino, y decidimos que no hace falta optimización a bajo nivel. Estaremos siendo ineficientes por diseño, y por tanto dejaremos , eventualmente, proyectos imposibles de Mantener.

Por eso es mejor dejar en cada capa de abstracción, un…   » ver todo el comentario
#15 this.

C es difícilmente substituible, mayormente porque los sistemas operativos se hacen en C y ensamblador.

Requiere mucha madurez y un profundo conocimiento de la arquitectura de un sistema. Te obliga a saber de estructuras de datos, y en definitiva, a entender como piensa una CPU.

Rust tiene mucho camino por delante, y recomiendo aprender a escribir código en el , porque obliga al programador a usar prácticas seguras, pero hoy por hoy, C va a seguir siendo los cimientos de la…   » ver todo el comentario
#15 C no tiene ningún problema claro, por eso llevamos décadas viendo fallos de segmentación, desbordamientos de buffer y de pila, deadlocks y data races, etc. que con suerte te cuelgan el programa, y sin suerte causan corrupción de datos o fallos de seguridad.

C ya era un lenguaje obsoleto cuando nació, la única razón por la que triunfó fue por la disponibilidad de compiladores gratuitos. A estas alturas merece morir y ser reemplazado por un lenguaje mejor.

Aun diré más. La abstracción

…   » ver todo el comentario
#43 "Yo aún diría más, un verdadero programador debería programar sus algoritmos en VHDL y sintetizarlos en una FPGA."

¿No se hace un ejercicio de eso en la carrera?
#45 Sí, claro que se hace. Yo tuve que implementar un micro RISC de 16 bits.

Que sepas hacerlo no significa que tenga sentido hacerlo, excepto en campos muy concretos. Es como pedirle a cualquier ingeniero que se ponga a resolver un modelo de elementos finitos a mano. Pues no, para eso tenemos software que te lo resuelve mejor que cualquier humano.
#15 En realidad lo has entendido mal. En Rust, estrictamente hablando, no hay gestión de memoria automática, lo que hay es, durante la compilación, una comprobación de que no estás haciendo cosas mal. Todo se hace con un analizador estático de memoria.

Un ejemplo: por defecto, cuando creas un bloque de memoria, ese bloque pertenece a la función que lo creó, y eso significa que si sales de la función, tienes que liberarlo. Pues bien: el analizador estático de Rust, durante la compilación, mira…   » ver todo el comentario
#54 Muchas gracias por la explicación y el trabajo que te has tomado. No conozco Rust mas allá de un par de tutoriales por curiosidad (y algunas cosas de la sintaxis ya me han dejado aturdido)

Evidentemente, estos lenguajes se desarrollan con el fin de mejorar la calidad del código y aumentar la estabilidad, y sobre todo, la ciberseguridad. La mayoría de las comprobaciones que indicas ya las hace el compilador de C. Las más profundas, como dices, se pueden hacer con un poco de orden y…   » ver todo el comentario
#64 Perdona, pero nada de lo que he dicho lo hace el compilador de C en ningún momento: si yo hago un malloc en una función asignando el valor a un puntero, y no hago un free en ninguna parte, el compilador no dice ni mu. Como mucho, te suelta un warning si no asignas un valor devuelto a una variable (y, si no recuerdo mal, sólo con -Wall), pero en ningún momento analiza nada de lo que sí analiza Rust.
#15 Un warning no siempre te va a cantar un memory leak, para ello va siempre bien tener herramientas de análisis de código estático. Por lo demás de acuerdo.
#63 Valgrind rules
#67 Cierto, y Klocwork.
Dentro de 50 años todavía existirá C y la base de casi todo seguirá estando escrita en C. Ya veremos entonces qué ha pasado con Rust...
#1 Tú espera 50 años a aprender Rust a ver que tal le va a tu carrera :-)
#3 en el mejor de los casos,se ha sacado un grado superior(FP II para los abuelos) y de aquí a 50 años estará jubilado. :troll:
#5 Jubilación? Iluso, eso ni exisitirá :troll:
#5 ¿FP II no era el grado medio?
#7 Eso era FP I
#10 #12 pues estaba yo confundido, gracias.
#19 Pues no conocía los cambios pero en esencia sigue siendo cierto lo que hemos dicho.
Con la novedad de que ahora FP es lo nuevo y Ciclo Formativo de Grado (Medio/Superior) es lo viejo, y han añadido FP básica para dar salida rápida a chavales de corta edad y alguna especialización.
#7 FP es grado medio, y FPII grado superior
#7 la FP de hoy en día no tiene nada que ver absolutamente con la de hace años. Ahora es cómo hacer un curso de CCC, dura menos, tiene muchas menos asignaturas y más enfocado a la práctica, puedes acumular varios si te sobra tiempo aunque aprendes más con cualquier tutorial de internet ;) pero claro eso de grado superior suena como si fueras ingeniero y claro vende más, también es cierto que la FP antiguamente era una masacre, demasiadas asignaturas, demasiada teoría, demasiado larga, y caía demasiada gente por el camino..
#5 Si tienes un móvil con Android llevas código mío en tu bolsillo.
PD: Estudié filosofía, soy programador autodidacta.
#17 Por curiosidad, ¿qué es lo que has desarrollado?
#59 Llevo desde 2001 colaborando en el desarrollo del kernel de Linux.
#9 pom *
#3 a nivel profesional en España, de momento no ha tenido mucha acogida.

Es verdad que hay factores como que es un lenguaje relativamente moderno, y que salvo en startups el resto del mercado suele ser bastante conservador.
#9 ¿vas a esperar a que se haga popular para aprender?
#13 ¿tu te aprendes todos los lenguajes nuevos que salen? Supongo que dormirás solo 1 hora al día.
#21 No sólo los que están en stackoverflow como los más valorados durante años consecutivos.
#72 Ahá. Yo valoro Scratch (es un decir), pero la realidad es que no está demandado ¿y dónde está Rust?

Top 5 most wanted languages:
Python: 25.7%
JavaScript: 17.8%
Go: 15.0%
TypeScript: 14.6%
Kotlin: 11.1%
The top most wanted languages are nearly identical to last year’s report.

(#21)
#13 Hay gente que no aprende nada de lo que paso con Ruby.
#28 Pues ahora me ha picado la curiosidad... ¿Qué pasó con Ruby? (no es una pregunta retórica)
#51 Hace ya unos cuantos años,llego ruby on rails,la hostia decían,había trabajo super bien pagado,mucha oferta y tal.
A día de hoy el trabajo que existe es muy poco,sigue con un salario decente,pero se paga mejor lo de siempre.
#53 es que ruby es un lenguaje de script más con un framework resultón (lo siento por los de ruby, que solo un poco menos susceptibles que los de python) que sirve para hacer páginas web de tamaño regularcillo, porque si quieres hacer algo grande usas un lenguaje grande para el backend y el frontend en lo que puedas, que sera lo mismo que el backend por simplicidad y para aprovechar gente.

Yo creo que Rust tiene mejor pinta porque es un C que no se enfada si olvidas el free, o sea, un C para torpes, y eso siempre gusta al que paga porque puede contratar a gente más torpe (ergo barata).
#56 ¿Te refieres a usar JavaScript en front-end y back-end o hay alguna otra opción y que realmente funcione bien?

Ruby es muy útil para hacer prototipos muy rápidamente, ése es uno de sus puntos fuertes. Por ese motivo aún se sigue usando en muchos contextos: puede ser más rentable para una empresa ir desplegando características nuevas cada semana que ir creando la aplicación perfecta durante meses para luego descubrir que lo que han hecho no interesa.

Tu argumento no me parece válido. ¿Has…   » ver todo el comentario
#76 Aún me sorprende que haya tanta gente que opine que proveer de mejores herramientas a los programadores implica que éstos sean peores. Especialmente cuando lo que se quiere es evitar errores que todos los programadores han cometido alguna vez en su vida.

A mi me gustan esas caracteristicas para los que aprendemos, porque quita muchos vicios y te hace mas organizado. Tambien te hace ver pronto posibles problemas, justo cuando loas escrito y no cuando no te acuerdas ni lo que escribiste.
#75 Ups, era para #53
#51 ¿Qué es lo de siempre? En desarrollo web hay gente que te dirá que PHP. Si te refieres a consultoras supongo que seguirán con Java y demás.

Desde mi punto de vista, Node.js ha llegado a un punto en que está viéndose como la opción más rentable frente a las plataformas tradicionales (Ruby on Rails, Django, PHP, etc.) por la facilidad de trabajar sólo con 1 lenguaje y por las mejoras que se han ido añadiendo en las últimas versiones de JavaScript.
Eso sí, la productividad que permite Ruby como lenguaje creo que todavía está a otro nivel, al igual que la elegancia que se puede conseguir con poco esfuerzo.
#13 nope, de hecho en su día ya estuve mirandolo y haciendo pruebas.

Pero no cambia el hecho de que o te haces proyectos completos por tu cuenta, o trabajas con ello para adquirir la experiencia adecuada. El mirar un lenguaje un par de dias y no usarlo solo te vale para hablar en el desayuno.

Lo de preguntar a la gente que si van a esperar para aprender tecnologías con bastante hype, se asemeja a preguntar si vas a esperar a aprender suomi.
#9 Así nos va....

Comparando con otros países en este mismo sector. Nuestro sector profesional es mayoritariamente bodyshoping y consultoras que contratan otras consultoras. Entiendo que ahí no haga falta modernizarse y usar herramientas cada vez más expresivas.
#9 Como en todo el mundo.

Las empresas que ya funcionan con una tecnología les cuesta muchísimo esfuerzo cambiar a otra, los beneficios deben estar realmente claros.

En general, no está costando mucho pasar de Java a Kotlin porque es interoperable. No es el caso.

Pasar de C a Rust, se me ocurre que
1) Te obliga a reciclar a tus programadores C altamente cualificados. Algunos no habrán programado en nada más en muchos años. Todos cobrarán muy bien porque un novato no te sirve para sacar…   » ver todo el comentario
#32 En realidad, parece ser (ojo, hablo de oídas) que C y Rust es bastante interoperable. La gente de Gtk está escribiendo cosas con Rust, especialmente Federico Mena, y explican cosas como que es posible portar una biblioteca de C a Rust haciéndolo "función a función", y compilando entre medias para probar que todo vaya bien. Vamos, que parece que puedes reemplazar cachos de código en C por cachos en Rust sin demasiada complicación...

Lo que no quita, por supuesto, que el cambio de sintaxis y de concepto es lo suficientemente grande como para que no se pueda aprender en una tarde...
#1

Salvo lo que sigue escrito en COBOL :-D :-D :-D
#8 Eso estaba pensando... ¿todavía siguen anunciando la muerte de cobol o ya se cansaron?
#20

No hace mucho en mi empresa anunciaron como tema innovador (no nos dedicamos al SW propiamente dicho) el paso de un sistema COBOL de una operadora a algo más modelno. :-D :-D :-D

Y en banca, debe ser la leche.
#20 Es que los que anunciaban la muerte de COBOL murieron :troll:
#1 Año 1973, un friki cualquiera en la cafetería de Informática (la superior, la de 5 años, no la de peritos) de Berkeley, California:

- "Dentro de 50 años todavía existirá ASM y la base de casi todo seguirá estando escrita en ASM. Ya veremos entonces qué ha pasado con C... "

:troll:
#14 En el 73 cambiar de modelos y lenguajes era sencillo y barato. Había cuatro gatos programando haciendo 4 programas.
Ahora mismo, el cambio se cobra bastantes réditos.
#55 Cambiar sí es caro. Mover todo el código de, por ejemplo, el kernel Darwin de C a Rust costaría un pastizalamen en developers y una pechá de tiempo en años de curro.

Desarrollar cualquier cosa nueva usando Rust, más seguro y más moderno y más sencillo, en lugar de usando C no sólo no tiene repercusión alguna en el coste inicial, sino que a la larga sale más barato.

Y todas las nuevas generaciones de programadores que lleguen usarán Rust en lugar de C, exactamente igual que otras…   » ver todo el comentario
#61 Peino canas. He escuchado este discurso antes. Con C, con Cobol, con PL1...

De aquí a 15 años te lo recuerdo.
#61 ¿Qué te hace estar tan seguro con el cambio hacia Rust? ¿Los gurús hablan bien de él? ¿Aumento de la demanda de programadores en Rust? ¿Tienes una Palantir?
#71 Ojo con las palantir. No sabes quien más puede estar mirando...
Me gustaba más en videojuego.
La idea de que los objetos tengan atributos relacionados con el uso del objeto en memoria reducirá el tipo de descuidos que convierten en vulnerables a muchos programas.
#2 same un ejemplo!
No verán nuestros ojos la caída del lenguaje C.
Este es el año de Rust en el escritorio :troll:
#47 Sí, estoy de acuerdo. Nunca me ha gustado la sintaxis de C y C++. Pero es lo que todos copian.

Yo hablo de la sintaxis porque es un escollo para la conversión del código ya existente. Si vas a hacer un lenguaje similar a C, pues hazlo lo más parecido posible para facilitar la migración. De lo contrario haz algo diferente como python.
A ver... Rust es bastante similar a C. OK. A demás cambia algunas cosas para evitar los problemas de C con el acceso a memoria. Bien. Pero...

Una función en rust es así:

fn main() {
println("¡Hola, mundo!");
}

Mientras que en C es así:

void main() {
printf("%s","¡Hola, mundo!");
}

Un diría ¿y qué? Un cambio que en principio parece que no hace daño...

¿Cuál es el problema? Que yo hubiera hecho hecho Rust lo más parecido posible a C e incluso habría…   » ver todo el comentario
#38 Si quieres atraer a los usuarios de C, lo último que deberías incluir es características de Cpp.
La gente de C, normalmente aborrece al primo pijo.
#41 Supuestamente Rust busca reemplazar a C y a C++. Así que yo habría hecho que se pudiera convertir automáticamente ambos lenguajes.

Esto es parecido a lo que pasa con Android: Si Huawei quiere sacar un sistema que reemplace a Android, tiene que poder ejecutar aplicaciones Android de forma transparente. Ya después, y si tiene éxito de verdad reemplaza a Android, puede que los desarrolladores se vuelquen a hacer aplicaciones nativas para ese sistema.

Con cualquier lenguaje que pretenta reemplazar a C y C++ lo que se necesita es que el reemplazo tenga una dificultad mínima para seguir usando el mismo software de antes. Si tiene éxito los programadores se volarán a utilizarlo directamente y aprenderán sus ventajas.
#41 Una guerra cada vez, por favor :hug:
#38 No por favor, la enésima discusión sobre sintaxis no... Es un bikeshedding de manual: es.wikipedia.org/wiki/Ley_de_Parkinson_de_la_trivialidad

La sintaxis de C y C++ son un coñazo, escribir un parser es bastante difícil (gramática sensible al contexto, macros, includes, etc.) y algunas declaraciones son absurdamente complejas (intenta declarar un array de punteros a funciones y llora). La sintaxis de Rust, sin ser la más legible del mundo, es mucho más clara.
#38 Edit
comentarios cerrados

menéame