Lenguaje Rust

[Gonzalo Nahuel Vaca]

Alguno tiene experiencia en Rust? parece que es un posible reemplazo para c++.

No se si les pasa como a mi pero me está costando entender la evolución de c++ (de hecho solo manejo hasta la versión C++14). No se, parece que el comité de la norma se fue por las ramas, de hecho Bjarne Stroustrup (creador del lenguaje) escribió sobre el tema http://www.stroustrup.com/P0977-remember-the-vasa.pdf

Parece que el lenguaje está fuera de control.

Tengo ganas de abandonar C++ pero son muchos años estudiándolo (detesto el lenguaje C, prefiero detectar errores en tiempo de compilación, usar el debugger me parece algo lamentable, así que no es una opción).

En fin, si alguien se puso con Rust puede contar su experiencia?

Saludos!

Ing. Gonzalo Nahuel Vaca

[Carlos Pantelides]

Hola Gonzalo

Alejandro Russo que no participa de este foro hasta donde sé ha dado una presentación hace unos años en CADIEEL orientada a Rust en sistemas embebidos. Si alguien tiene la presentación puede compartirla, quizás

Titulo: Construyendo sistemas embebidos seguros usando técnicas de lenguajes de programación

Resumen: Los lenguajes de bajo nivel, como C/C++, son altamente usados en la industria para desarrollar sistemas embebidos. La forma de programar estos sistemas involucran detalles internos de la computadora como el uso de punteros a memoria como así también una manejo manual de memoria dinámica. La historia del software nos muestra que entre los errores mas comunes, y difíciles de corregir, es la presencia de punteros inválidos (dangling pointers en ingles), es decir, punteros que referencian a lugares de memoria inválidos o que no están mas en uso. Cuando los sistemas embebidos además son concurrentes, también hay problemas de condición de carreras (data races) en los datos que manejan. Sería muy beneficioso para los programadores que el compilador pueda ayudar a los programadores a evitar introducir punteros de memoria inválidos o condiciones de carrera en su código, construyendo así un sistema mas seguro.

Rust es un lenguaje recientemente desarrollado por Mozilla para desarrollar sistemas que requieren alta performance y un ambiente de ejecución pequeño

(runtime). Parte del navegador Firefox ya esta implementado en este lenguaje. Rust usa principios de lenguajes de programación e implementa un sistema de

tipos capaz de detectar la posibilidad de introducir punteros inválidos y maneja la memoria automáticamente si la necesidad de un recolector de basura

(garbage-collector). En esta charla, se explicaran los principios y filosofía detrás de Rust y cómo estos podrían ser aprovechados para construir sistemas

embebidos mas seguros.

Biografía: Alejandro Russo es un profesor asociado de la universidad tecnologica de Chalmers (Gotemburgo, Suecia). Su trabajo se expande entre la intersección de lenguajes de programación, sistemas, y seguridad. Prof. Russo ha recibido distinciones como el premio a investigación de Google (Google Research Award) y

varios fundos de institutos suecos de investigación (Vetenskapsrådet, STINT, and Barbro Osher foundation). Internacionalmente, A trabajado en Stanford University

por a periodo de un año y medio como profesor visitante y ha dado cursos en la Escuela de Ciencias Informaticas (ECI) en dos oportunidades.

[Gonzalo Nahuel Vaca]

Extraordinario! mil gracias.

Promete mucho Rust. Me da broca el camino que tomó C++, no soy capaz de seguirle el paso a todo lo que están haciendo. Recién ahora están hablando de meter la bilbioteca de Boost al STD (un lenguaje de programación genérica que no tiene una biblioteca estandar para realizar arquitecturas cliente-servidor).

El problema de un lenguaje de tantos años es que tienen que realizar modificaciones retrocompatibles para no romper el código legacy que hay dando vueltas. En fin, me parece que la entropía ya hizo estragos y que es más fácil cambiar de lenguaje.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/342da1ca-fbfc-433a-919c-2a308938ddf9%40googlegroups.com.

[Juan C. Suárez B]

Hola Gonzalo.

¿Por qué detestas el lenguaje C?

Saludos.

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/e0cf5140-15a0-4b7f-910c-dbee690f8cd6%40googlegroups.com.

[Gonzalo Nahuel Vaca]

Hola Juan,

Es gusto personal, pero te doy mis razones:

- El tipo de datos no es lo suficientemente fuerte, un ejemplo es el casteo de un tipo de datos a otro con truncamiento.

- operadores new y delete desnudos.

- manejo de memoria insegura y tiempo de vida de lvalue indefinido.

- Los tipos de datos definidos por el usuario son inseguros y tienen por definición un mal comportamiento (ejemplo: operaciones entre tipo de dato enum y tipo de dato int).

- El lenguaje C no es lo suficientemente expresivo.

- El lenguaje no detecta mal manejo de memoria en tiempo de compilación, lo que obliga a usar el debugger.

Nota: usar el debugger es lamentable por varias razones:

1) El código generado es necesariamente más lento (hay que incluir las instrucciones para debbugear).

2) Como el código usado para debbuger no es el mismo que el código para el deploy, nadie te asegura que tu sección de debagueo halla limpiado los bugs.

3) Genera la idea de usar el lenguaje C como un assembler glorificado. Lo que genera la mitología de que los lenguajes a medida que son de más alto nivel generan código más lento. Cosa que no es así.

Usa el lenguaje que más te guste, yo lo veo como algo arcaico. Sino programemos con tarjetas perforadas jaja.

Un saludo.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAP8UyvQQ%2BiQ5gEBJKpfcvy-E46C1nCDycQVMhcz9LhHDMPy0vQ%40mail.gmail.com.

[Ing. Mirko Serra]

A mí me interesa más saber qué cosas te son molestas de C++ moderno.

La mayoría de los problemas que le achacás a C son todos válidos, pero justamente los puntos donde C++ se ha tratado de diferenciar con diferentes grados de éxito, y el C++ moderno se diferencia aún más (por ejemplo, muchos warnings en casos de truncamiento/conversiones; enum class; new/delete no se usan; etc.). El mayor problema que tiene C++ como lenguaje es el bagage que trae de C (ayudó a tener éxito pero ahora es una carga); incluida (sobre todo?) la forma de enseñarlo.

Ambos son herramientas como también lo es Rust (no lo he usado; he escuchado que algunos cambios de C++ moderno son para seguirle pisada porque es un digno rival), y como tales tienen casos de uso donde son la mejor herramienta.

C como lenguaje es un assembler glorificado (y portable). Es lo que aspira a ser y lo consigue con éxito. Si consideraste hacer un proyecto en assembler, planteate escribir en C y seguro queda mejor (el compilador gcc escribe mejor assembler que cualquier humano en general; el de Microchip en 8 bits hace código que no anda). Si te parece que el proyecto es demasiado grande para hacerlo en assembler, probablemente también lo sea para C.

Creería que el problema es que hay mucha gente que en su valijita solo tiene un martillo (C), y entonces quiere arreglar todo a martillazos.

Saludos y felices fiestas.

Ing. Mirko Serra.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAKLz8eLfQvGpYoyRB6CPE1X7oTCkvH8Kv-d%3DJ-BAvA1dqbWc0A%40mail.gmail.com.

[Gonzalo Nahuel Vaca]

Hola Mirko, con C++ tengo el problema que es una amante maltratadora jaja. En estos ùltimos años han acelerado el ritmo con el que modifican el lenguaje lo que hace que me sea imposible seguir el paso. Nada, tengo la sensación de estar llendo para atras con el lenguaje, había alcanzado cierto nivel y ahora siento que no conozco ni la mitad del lenguaje.

La realidad es que el lenguaje es muy bueno, pero como remarcas lleva la pesada herencia de C. Quizas Rust no tiene que arrastrar con lo mismo, por eso consultaba si alguien tiene experiencia. Ahora con el tema de webassembly que estoy tratando de aprender tengo la chance de ver si me conviene cambiar de lenguaje (uControladores hace rato que no programo).

Mil gracias y felices fiestas!!!!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAOCjbm8du0Gt8Fb%2BfAoye%3DQ%3DhnvaBc72uOm15ejmM%3D9x67tv7A%40mail.gmail.com.

[Carlos Pantelides]

Obviamente no quiero caer en nuestra periódica War Of Programming Languages, sólo quiero comprender esta parte:

> Nota: usar el debugger es lamentable por varias razones:

>1) El código generado es necesariamente más lento (hay que incluir las instrucciones para debbugear).

Entiendo que hay que poner datos para que el debugger pueda asociar el código actual con el código fuente y esto se prende y apaga con un flag al compilador. ¿Hace diferencia en el código resultante cuando no está con -g?

>2) Como el código usado para debbuger no es el mismo que el código para el deploy, nadie te asegura que tu sección de debagueo halla limpiado los bugs.

¿Te estás refiriendo a que para poner -g es conveniente pedir -0 (no optimización)?

Aparte, ¿no podrías utilizar testeo unitario y minimizar debugging y printf()s? Esto trasciende al lenguaje utilizado. No tengo idea de tus circunstancias pero quizás más que cambiar de lenguaje quizás te convenga explorar otros recursos. Te lo digo como agnóstico a los lenguajes, salvo evitar MS, pero por prejuicio, no hace falta meterse en esa conversación por favor ;-)

Saludos

[Gonzalo Nahuel Vaca]

Hola como estas? 

El tema debugger, si queres seguir secuencialmente las instrucciones en C y ver como afecta los registros y memoria estas haciendo asm glorificado y el código generado por el compilador no esta optimizado.

Lo peor que podes hacer es debuggear con código no optimizado y luego pasar a producción con código optimizado.

Como hacer pruebas automáticas en embebidos no tengo idea, debería hacer la especialización/maestria para hablar de ese tema.

Como regla general, debuggear es la marca de un mal lenguaje que no puede detectar los errores en tiempo de compilación. Después tenes las excepciones que tengo entendido que en embebidos no se usan (C++) así que no se como hacen para recuperar el sistema de una excepción.

Un abrazo!

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CA%2BPxht3PJ%2Bmh4VLkaNPpJHUC1NweCpvLo7vjhz_%3D32iP4Zvwkg%40mail.gmail.com.

[Carlos Pantelides]

Gonzalo,

> El tema debugger, si queres seguir secuencialmente las instrucciones en C y ver como afecta los registros y memoria estas haciendo asm glorificado y el código generado por el compilador no esta optimizado.

>Lo peor que podes hacer es debuggear con código no optimizado y luego pasar a producción con código optimizado.

mmmh, no entiendo cual es la relación de usar un debugger con el lenguaje utilizado, he usado debugr para lenguajes "de alto nivel" como java, javascript y php y si estás usando el debugger es por que no sabés que es lo que estás haciendo o es código ajeno y estás intentando descifrar que hace.

¿Estás hablando de código altamente relacionado con tiempo real donde la optimización te podría cambiar el comportamiento por que en lugar de depender tus tiempos de factores independientes dependen de la implementación? Tipo un delay() con un for()

 

Como hacer pruebas automáticas en embebidos no tengo idea, debería hacer la especialización/maestria para hablar de ese tema.

Hay un libro, Test Driven Development for Embedded C que me consta que es útil y si mal no recuerdo tiene un capítulo entero dedicado al problema del tiempo.

Te estoy haciendo todas estas preguntas y comentario más para aprender que para discutirte o incluso ayudarte, paciencia.

Saludos

[Gonzalo Nahuel Vaca]

Hola Carlos, no hay problema. Que no soy un gurú tampoco jajaja.

Me metí en tremendo bardo, lo explico como lo entiendo, si estoy equivocado porfa corregime:

>mmmh, no entiendo cual es la relación de usar un debugger con el lenguaje utilizado, he usado debugr para lenguajes "de alto nivel" como java, javascript y php y si estás usando el debugger es por que no sabés que es lo que estás haciendo o es código ajeno y estás intentando descifrar que hace.

Del libro "Programming, principles and practice using C++ - Bjarne Stroustrup" capítulo 5 "Errors"

5.9 Debugging (pag 159):

* se comienza a debuggear antes de escribir la primera línea de código:

- Se decide como se van a reportar los errores std::cerr por ejemplo, o un return 1; o trow.... ect. (C no tiene estas posibilidades)

- Se debe hacer el programa fácil de leer (el lenguaje tiene que ser expresivo, C no lo es)

- El código debe estar BIEN comentado (no poner comentarios por todos lados), para eso la idea debe estar expresada en el código.

- Lo que no se puede decir en código es y que debe estar comentado es el nombre del programa, el propósito, autor, versión, ect.

- Usar nombres significativos.

- la lista sigue...

Si tenés que usar el debugger para entender lo que hace el código, es que no esta bien escrito o bien comentado/documentado. Lo que muestra que usar el debugger para esos propósitos es la marca de o un mal programador o un mal lenguaje. Lo que confirma que la hipotesis de que usar el debugger es una situación lamentable.

> ¿Estás hablando de código altamente relacionado con tiempo real donde la optimización te podría cambiar el comportamiento por que en lugar de depender tus tiempos de factores independientes dependen de la implementación? Tipo un delay() con un for()

si pero...

La crítica que le hago a C es que los errores tienden a aparecer en tiempo de ejecución (en el runtime), suponete lo siguiente:

tenes un enum  semana {domingo ........ sábado}.

Tenes una variable int x = 2;

suponete una variable enum semana dia = viernes;

ahora por esas cosas de la vida hiciste día += x;

de que nos disfrasamos? te va a generar un comportamiento indefinido y el compilador te dijo que estaba tuto legal!

Esa expresión en C++ es un error de compilación, el lenguaje no te permite hacer un código con ese comportamiento indefinido.

algo que debería saltar en tiempo de compilación ahora te va a llevar una tarde con el debugger. Esto es un problema del lenguaje, no del programador. Usar es debugger en esta situación es lamentable. Lo estás usando por una falla del lenguaje.

> Hay un libro, Test Driven Development for Embedded C que me consta que es útil y si mal no recuerdo tiene un capítulo entero dedicado al problema del tiempo.

Mil gracias por el tip.

Un abrazo!!!!

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/379d0f56-03f7-485c-9632-d34bfb49bc83%40googlegroups.com.

[Carlos Miguens]

Estimados buenas tardes,

   Como bien comento mi tocayo Carlos Pantelides, te recomiendo que utilices TDD, en este año comencé a usar esa practica para desarrollar algoritmos de compresión para un wearable y los resultados fuero muy buenos. Para su desarrollo utilice C, Eclipse, SonarQube y todas las buenas practicas como desacoplar el codigo y orientarlo a los test, integración continua y MISRA C. 

   Si bien se puede checkear problemas como punteros invalidos corriendo los tests o pusheando al repositorio, tambien se puede ver en tiempo de desarrollo configurando correctamente el plugin de sonarQube para eclipse.

    Siendo prolijos y utilizando algun RTOS que brinde la posibilidad de tener un patron de diseño unificado, el codigo C se puede escalar muy facilmente,  y utilizando TDD ahorras los inconvenientes que resaltas

    Actualmente estoy usando Linux Embebido (si se que es otro mundo) pero en vez de pasar de C a C++, estoy pasando de C a Python.

    Con esto no quiero decir que el camino que muestro sea el único, pero es mi recomendable.

    Saludos y felices fiestas!!!  

Carlos

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embeb...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embeb...@googlegroups.com.