EDICIóN GENERAL
141 meneos
1831 clics
[ENG] Microsoft está valorando usar Rust

[ENG] Microsoft está valorando usar Rust

Según un informe publicado por Microsoft , el 70% de los bugs corregidos en su productos se deben a problemas con el uso de la memoria. Rust está diseñado para tener un acceso seguro a la memoria por lo que su adopción supondría una mejora importante en la calidad del software de Microsoft,. Otras empresas, además de Mozilla, que han adoptado Rust recientemente son Cloudflare, Dropbox, y Brave browser.

| etiquetas: microsoft , mozilla , rust , seguridad , memory leak , memory safe
«12
  1. #2 Una afirmación como esa sólo puede venir de alguien que jamás ha hecho un proyecto mínimamente complejo en C. O en cualquier otro lenguaje.

    Y no, no soy fanboy de microsoft.
  2. #6

    Puedes dar muchísimas clases de C o C++, pero por el hecho de subestimar la complejidad de los proyectos en esos lenguajes, parece que sólo has hecho programas sencillos.
  3. #11 Pues buena suerte con esas contrataciones, habra que tener paciencia, porque, por lo menos en este mundo, todavia no ha nacido la persona que es capaz de crear codigo totalmente libre de errores.
  4. #6 Esto explica por qué dices cosas sin ningún sentido. Eres un teórico en lugar de alguien con experiencia práctica.
    Si trabajases en cualquier proyecto real de una mínima complejidad sabrías que es inevitable que se produzcan errores. La cantidad de cosas que hay que tener en cuenta es tan grande que es normal que alguna se te escape.

    Tú dices que invirtiendo lo suficiente consigues eliminar todos los errores y no es así, nunca se podrán eliminar todos porque siempre habrá casos que ni en los diferentes test que tenga que revisar el equipo de calidad se hayan ni siquiera planteado y solo se descubren casualmente por el usuario número 10 millones que tiene una configuración especial que nadie podía imaginar que alguien pudiera tener.

    O incluso porque unos años más tarde de su desarrollo, sale un nuevo hardware con requisitos especiales (pasar de un núcleo a varios, discos duros ssd, ...), o también los cambios en el software sobre el que se instalará el tuyo puede tener cambios imposibles de predecir (nuevo sistema de archivos, cambios en los Apis, marcos de trabajo, etc)

    Por lo tanto, como en cualquier ingeniería, tienes que buscar el coste óptimo en el equipo de calidad, qué además necesitas tenerlo ocupado el máximo de tiempo posible. Y no, aunque te gastases el 99,9999999% del presupuesto del proyecto en calidad conseguirías un software libre de errores.
  5. Madre mía, aquí es que todo el mundo programa en C/C++ nivel John Carmack y no tiene nunca memory leaks. Si Microsoft esta valorando Rust, es porque ya se ve en el ejemplo de Mozilla. Y si Firefox ha mejorado tanto en performance y errores es en parte gracias a Rust. Ya que los propios desarrolladores han comentado que las partes que han reescrito en Rust eliminaron memory leaks a punta pala.
  6. #1 Los errores de memoria son jodidos de localizar. Por ejemplo, si en una función tienes que liberar la memoria al salir, pero tienes muchos puntos de salida, es fácil que se te olvide liberarla en alguno de ellos. Y encontrar luego donde, es jodido.
  7. #1 En muchos casos tal vez sea mejor que los desarrolladores enfoquen su atención en cosas mucho más importantes que en detalles que no tienen que ver con el problema como por ejemplo revisar con lupa a ver si hay un desbordamiento de memoria. Un lenguaje donde sean imposibles sería más conveniente.
  8. Rust es como C++ pero la sintaxis está diseñada para que sea fácil identificar errores.
    Para mi es el lenguaje del futuro.
  9. #2 Un error de memoria en yacc y estaba ahí desde hace 33 años. Hablamos de Unix y hablamos de yacc un programa hecho por programadores para programadores... y ahí estaba el error hasta que alguien lo vio:

    marc.info/?l=openbsd-cvs&m=121553004431393&w=2
  10. #11 la tipica frase cuñadil sobre desarrollo de software
  11. #13 ¿Te crees que no se escapan errores? Siempre hay cosas que se rompen. Siempre, en Software y en cualquier cosa. O acaso, por ejemplo tu casa no tiene averías? Por poner un ejemplo físico de algo diferente. Pues, en el software ocurre exactamente lo mismo, hay averías, es decir, bugs o incluso errores de fábrica que muchas veces debido a la complejidad son inevitables.
  12. #13 te falta meter tu mensaje entre tags <ironic>
  13. #1 "Cuñao seal of approval" {0x1f3c6}

    Mención especial para #26 y el resto. Gracias por participar.
  14. #6 Eso no significa nada. Aun recuerdo alguna profesora de programación que tuve en la carrera :palm:

    En un proyecto mínimamente grande donde mete mano mucha gente y con cierta antigüedad eso que dices no tiene sentido, simplemente son aplicaciones con una cantidad de código heredado que es imposible controlar las consecuencias de muchos cambios, si usas ahi la política de despidos que dices, no solo no mejorarás la calidad del software, si no que la gente bajo presión será mas propensa a cometer errores o incluso dejará el puesto en cuanto pueda, sumiéndote en una espiral de baja calidad por falta de experiencia (nadie experimentado querrá trabajar ahi asi que se irán y tendrás que contratar novatos)

    Y windows justo es un proyecto enorme, con cientos de personas tocando y una antigüedad de décadas.

    Me temo que no basta con "suspender" a la gente.
  15. #6 En C++ tienes smartpointers si no te quieres preocupar de la gestión de memoria. En C, que es de lo que hablábamos, no tienes nada parecido. Y aún así, si te empeñas, puedes conseguir que haya leaks.
  16. #19 No, solo una persona. El resto le ha dicho que no se flipe.
  17. #11 ¿De verdad crees que en Microsoft no hay buenos programadores y bien pagados?
  18. #28 se de un tío que pidió tests funcionales para cada posible caso de uso y recibió una estimación de un par de cientos de años
  19. #1 Y los automóviles en lugar de equiparlos con airbags y cinturones de seguridad, podriamos conducirlos con mas cuidado
  20. #5 O de alguien que da clases de C++ y está cansado de ver ñapas en las entregas de prácticas.
  21. «memory leak» -> fuga de memoria. Por favor.

    Con C++ puedes utiliar auto y std::shared_ptr, disponible desde C++11. en.cppreference.com/w/cpp/memory/shared_ptr
  22. #2 Venga, y despedimos profesores si tienen una falta de ortografía también
  23. #9 No es la sintaxis lo que está diseñada para que sea fácil detectar errores. Es la semántica y el compilador.
  24. Estamos en 2019, la industria del software no puede seguir en esta situación ni seguir aguantado a zombies que siguen repitiendo que el problema es contratar a buenos programadores. Rust está siendo una revolución y con razón. C y C++ tendrán que evolucionar para eliminar los fallos de gestión de memoria de raíz o desaparecer a largo plazo.
  25. #4 #3 tal vez sea un idea loca, pero windows es un producto de software. A lo mejor hasta podemos "pedirle" un poco de calidad a su software.
  26. #11 No es ese el problema, un lenguaje de programación en muchos aspectos no deja de ser unas directrices de diseño. Si controlar manualmente la memoria es un quebradero de cabeza, y es más que probable que una persona se equivoque, pues mejor usar directrices que no incluyan ese problema.
  27. #21 No he oído fuga de memoria en mi vida.
  28. #7 Es una idea loca, créeme.
    El negocio del software no está en el desarrollo; sino en el mantenimiento. La pasta ha estado ahí de toda la vida.
  29. #11 Microsoft tiene algunos de los mejores ingenieros del mundo, a los que paga bien y tiene entre algodones. Me quieres decir que les faltas tú o qué?
  30. Así que los inventores de C#, F#, Visual Basic, Visual Foxpro, typescript y mil lenguajes más se decantan por usar un lenguaje creado por la Mozilla fundation... Todo muy en la línea de Microsoft xD
  31. #25 Pues es un término bastante habitual.
  32. #21 auto no tiene nada que ver con la gestion de memoría.
    Mejor nombraría los smart pointer en general, el shared es un tipo de ellos si, como su nombre indica, lo quieres compartir.
  33. #48 Decir que la gente en Microsoft no sabe programar es de un cuñadismo máximo.

    Ya les gustaría a muchos listos de aquí pasar una entrevista para entrar en Microsoft ganando 150k de entrada.
  34. Rust no solo previene las fugas de memoria. A los listillos que se creen que todo se soluciona con un poco de cuidado os recomiendo informaros un poco de la clase de errores que evita Rust.

    Os recuerdo que no todos los proyectos software son vuestras prácticas de la universidad de 2000 líneas monohilo. Que tengáis alumnos imbéciles no significa que en Microsoft cometan ese tipo de errores.

    Y no, los smart pointers no suplen al borrow checker.

    Y aún así Rust es mucho más que sus características de seguridad. Es un lenguaje muy cómodo de usar y su semántica es más parecida a Python que a C, pero con las características de rendimiento de un lenguaje de sistemas.
  35. #1 O aprender a programar en C y C++ antes de ponerse a hacer aplicaciones complejas con esos lenguajes.
  36. #4 eso es así con C, con C++ y RAII eso no pasa. A parte hay herramientas como valgrind, que aunque no son la panacea, leaks de memoria como el que mencionas te los pilla.
  37. #4 Por eso una de las recomendacioones es no tener más de un punto de salida de una función, especialmente si vas a trabajar con memoria. Si la función es compleja quizás sea mejor hacer varias en vez de meterlo todo ahí. Sé que no siempre es tan sencillo como lo pintan, pero seguro que ayuda.

    En cualquier caso las últimas versiones de C++ han añadido muchas ayudas al control de memoria para poder evitar y, si es necesario, localizar más fácilmente las fugas de memoria y las violaciones de acceso a memoria.
  38. #21 no compares los smart pointers con el borrow checker porque no lo sustituyen.
  39. # #11 sí, no hay más que ver que en Google no hay tienen bugs.
  40. #1 ya lo revisan, no creas que le vas a enseñar a Microsoft buenas prácticas.
  41. #6 porque una práctica con 3000 líneas de código es lo mismo que un sistema operativo con 50 millones, no te fastidia...
  42. #3 No es tanto revisar despues, pero al programar cosas de sistema operativo, drivers, firmware y tal, se deberia programar con esa actitud de control por los detalles, "programacion lenta, concienzuda". Muchas mentalidades de ese tipo hacen, generalmente, que el codigo empeore. Llevo, entre una cosa y otra unos 15 años programando drivers y cosas del estilo y esa programacion lenta y de pensar y tener muy presente la memoria y el procesador y demas, esa actitud de control casi paranoico, es la que te ayuda a hacer las cosas bien, aunque tardes mas. Y ojo, empece a mirarme Rust hace un año y algun dia quiero cogerlo con ganas y tal, pero por mucho que use Rust no voy a dejar de tener esa actitud.

    Por cierto, el nucleo de NT y en general lo de kernel, esta bastante pero bastante bien hecho, salvedades de pilas de drivers como WFP y demas, que ha ido cambiando y al principio siempre estan algo incompletos, pero en general NT es codigo de bastante calidad. Si que ultimamente, dicen, parece que les cuesta encontrar relevo para desarrollo de kernel, y si ha habido criticas de los dentro al resoecto, pero es mas critica al volumen y complejidad que a la calidad del codigo.
  43. #74 De acuerdo en todo.

    Sin embargo, una actitud de cuidado por los detalles de lo que se está haciendo es diferente a detalles que puede subsanar el lenguaje. Por ejemplo un lenguaje donde no se declaren las variables puede tener errores simples de tipeo que se evitarían en un lenguaje con declaración de variables. Esos son lenguajes peligrosos por mal diseño del propio lenguaje. Es estúpido hacer perder el valioso tiempo de un programador en revisar esos detalles cuando un lenguaje con declaración de variables se encuentran esos errores con cero esfuerzo del programador mientras en uno que no se declaren las variables pudiera encontrarse el problema dentro de 10 años por un hecho fortuito.

    En el caso de problemas con la memoria, hacer un lenguaje más seguro puede implicar un penalti en tiempo de ejecución. Muchas veces valdrá la pena, otras veces no.
  44. Pues van a flipar. Si son capaces de que no les maten en la zona de spawn que se preparen para los raid.
  45. #8. Como con los coches y la revisiones (y reparaciones) en los concesionarios oficiales. Al parecer el coche eléctrico necesita mucho menos mantenimiento lo que explica en parte que se haya tardado tanto en seguir los pasos de la marca Tesla.
    (CC #7)
  46. #37 así a primera vista parece que es mejorable el proceso
  47. #34, #21...es que no tienen nada que ver con Rust. Los smart pointers y eso le dan a C++ algo parecido a un garbage collector Como a golang o java. Pero aún así puedes tener memory leaks, por ejemplo, montando alguna referencia compleja que nunca se libere, o una mala gestión de memoria creando y destruyendo memoria que podrías reaprovechar.

    Sin embargo, Rust tiene, a nivel de lenguaje, directivas para que el programador indique la inmutabilidad de una variable y la capacidad de mutar los parámetros recibidos. Eso le da al compilador una información preciosa para saber cómo debe gestionar esa memoria o detectar accesos prohibidos.
  48. #29 tranquilo, Rust# esta en camino
  49. #31 lo del cuñao queda bien cuando no hay muchos argumentos para contradecir un argumento. ¿donde están los tuyos?

    Lo mismo nunca has estado en un proyecto de construcción de software, pero, como ya ha comentado más gente, las prioridades no suelen ser contratar gente con mucha experiencia codificando, ni aplicar metodología de medición de calidad, ni mucho menos revisar lo construido.

    Ahora, gente que habla de cosas que no entiende, aquí y en los proyectos hay muchos.
  50. #41 programaran usando paneles solares y puertas AND
  51. #57 Hasta el más listo y experimentado se equivoca, por eso siempre es recomendable hacer pruebas exhaustivas y siempre que sea posible hacer una revisión del software.

    Y a poco que hayas trabajado en el mundo de desarrollo te habrás dado cuenta que revisar no es la opción más popular entre no pocos responsables de proyecto (como en todos los sitios, vamos). Lo que monda dinero y solo da calidad muchas veces se minusvalora.

    Si has llegado a una conclusión distinta, creo que no has vivido una situación similar.
  52. #14 Si ha sido unicamente profesor, seguramente lo más complejo que habrá programado serán los mini ejercicios esos de ver si una palabra es un palíndromo. :-D
  53. #4 Con alguna excepción, una función debería tener un único punto de salida.
  54. #29 Microsoft ha cambiado mucho con respecto a aquella Microsoft de cuando IE6 y sucedáneos. Hasta el framework es open source.
  55. #29 Ya desecharon su propio motor de HTML para usar el de Chrome así que esto tampoco sería tan raro.
  56. No soy experto pero llevo toda la vida oyendo sobre las fugas de memoria como un problema que había que minimizar. Lo extraño es que la propuesta de rust no haya aparecido antes
  57. #29 me encantaría ver un windows escrito en typescript o vb...
  58. #30 #27 Err..no.
    Por un lado tenemos la validacion de parametros recibidos, que cada comprobación puede ser un return en caso de error tras el seteo del error.
    Por otro lado una funcion invoca a otras funciones cuyo valor devuelto puede ser un error y se debe terminar a la recepción del mismo la ejecución.
    Una función con un "return" solo se ve en la Universidad. En la vida real no existen.
    Antes de salir hay que liberar la memoria, o asegurarte de pasar aguas arriba el puntero a la misma (para que lo liberen cuando sea necesario).
    El problema de mandarlo aguas arriba es que el programador aguas arriba debe saber que ese puntero recibido debe ser liberado y a veces son dos programadores distintos y se termina leakeando memoria (reservandola pero no liberandola...)
    Pero el problema fundamental está en los buffer overflows y buffer overruns. Antiguamente existían funciones para copiar memoria de un sitio a otro, pero era responsabilidad del programador asegurarse que lo que estabas copiando "entraba" en el sitio de destino. De ahí el mítico Malloc para reservar la memoria justa. Pero claro, muchos programadores las usaban y usan incorrectamente, la cadena de origen no cabe en el hueco destino y comienza a escribir machacando datos contiguos en la memoria.
    Para solventar esto, se crearon otras funciones de copia de cadenas que te obliga a decir cuantos elementos deben ser copiados. Esto obligaba a los desarrolladores a pensar en el tamaño de la copia, y se reducía el problema del overflow. O peor, el desarrollador pasaba de querer contar y usaba las funciones de copia de cadenas antiguas que no le obligaba a pasar este parámetro.
    Los fallos en overflow que he visto...se cuentan por miles...y una razón es que algunas de estas funciones de copia seguras utilizan como parámetro el número de caracteres a copiar, y otras el tamaño en bytes a copiar. Cuando se utilizan cadenas tipo Char, coinciden el numero de bytes con el numero de elementos de la cadena. Pero si utilizas Wchar, el numero de bytes es el doble del numero de elementos dr la cadena.
    Si utilizas una funcion de copia para copiar una cadena Wchar con 6 elementos, y resulta que pasas el numero de bytes (12) en vez del numero de caracteres (6) que utiliza el numero de caracteres como parametro....pues estás haciendo un overflow de 6.
    Lo mismo pasa con las funciones de lectura, pero aqui basicamente lo que haces es un overrun...es decir...leer 12 caracteres en vez de 6. Leyendo 6 elementos de la memoria contigua que no tiene nada que ver la cadena.
    O peor, hacer un underrun, si en una funcion que espera el numero de bytes a leer(12), le pasas el numero de elementos (6). Como se ha pasado 6, entiende que realmente son 6 bytes, 3 elementos. Y te deja 3 sin copiar.
    Los underrun son menos peligrosos....y faciles de detectar. Pero los overflow...trackearlos son jodidos....
    Ahora ya existen herramientas como Coverity que ayudan bastante en este campo.
  59. #66 Lo que me hace gracia es que la mitad de los que comentan aquí queriendo dar lecciones a Microsoft sobre como desarrollar software, probablemente trabajan en Indra o se ganan la vida desarrollando plugins de Wordpress...
  60. #29 Lo mejor es que se han decantado por Chrome para hacer simbiosis con Edge. Dejando a Firefox de lado.
  61. #24 A ver. Es cierto que es difícil enseñar C a alguien acostumbrado a Javascript o a otros lenguajes modernos. Eso no quiere decir que para ciertas cosas Rust pueda ser mejor que C ni que en C sea extremadamente fácil pegarte un tiro en el pie.
  62. #27 Los puntos de salida de una función no tienen nada que ver con la gestión de memoria. Es sólo un tema de legibilidad e incluso hay tendencias que están en contra, favoreciendo el early return.
  63. #9 Pero su gestión de memoria, aunque algo engorrosa, es cojonuda. Tienen razón en m$. Rust tiene mucho futuro y, añado, golang también. Son el C/C++ del siglo XXI.
  64. #78 Para eso, los programadores de golang tenemos una fantástica instrucción llamada defer. Toda liberación de recursos se incluye en el defer. El defer se ejecutará al salir de la función, por tanto podemos abusar del early return que todo queda limpito.

    Ventajas de los lenguajes modernos.
  65. #83 No he programado un driver de verdad en 20 años. No voy a empezar ahora. Para todo lo demás, golang
  66. #1 También pueden actualizar un poco el código. En C++ moderno (C++11 y posteriores) hay muchísimas formas de gestionar la memoria de forma segura y eficiente.

    #37 Pues, a juzgar por la calidad de algunos de sus productos, yo diría que a lo mejor sí.
  67. #28 no se si es un ejemplo plausible( ni si quiera se si puedo usar aquí la palabra plausible pero el corrector de iPhone lo sugiere) pero yo hago juegos y muchas veces testeamos en un equipo de cuatro personas los procedimientos, luego con grupos de más de 20 amigos, pero al final acabas viendo en YouTube videos de gente que hace algo que a ninguno se os había ocurrido y peta x procedimiento y dices joder...
    Que lo parcheas y solucionas esa situación pero es lo que dices, es imposible no cometer fallos
  68. #12 Esa persona no ha nacido. Pero a un equipo de personas que Implementan calidad y revisión de pares no se la cuelas.
  69. Es tal la cantidad de comentarios cuñados de este hilo que se me hace imposible otorgar el premio al cuñado informático.
  70. #6 Pobres alumnos. Un profesor con Dunning-Kruger. La eterna efermedad de nyestra univ.
  71. #52 #65
    Con unique_ptr, const, move:
    nercury.github.io/c++/intro/2017/01/22/cpp-for-rust-devs.html
    Al fin y al cabo Rust lo que implementa son las semánticas de mover y el chequeo estático que lo asegure.

    Con metaprogramación: medium.com/@bhuztez/emulate-borrow-checker-in-c-with-stateful-metaprog
    Permite chequeo estático.

    Es cuestión de tiempo que el estándar integre la funcionalidad. Como siempre, opcional.

    Crítica a Rust: hackernoon.com/why-im-dropping-rust-fd1c32986c88
    * Necesidad de usar C en algunos casos.
    * Detalles de implementación de rasgos (traits) y conteo de referencias.
    * Imposible de modificar el comportamiento del compilador.
  72. #72

    > Al fin y al cabo Rust lo que implementa son las semánticas de mover y el chequeo estático que lo asegure.

    Ah bueno, si "solo" implementa eso...

    > Therefore, a good practice in C++ is to avoid using move in the case like this, even if this means unnecessary deep copy of the value, to avoid the accidental usage of the moved value.

    Nada más que decir.

    > Con metaprogramación

    En Rust es algo nativo.

    > Es cuestión de tiempo que el estándar integre la funcionalidad.

    Hablemos entonces.

    > Como siempre, opcional.

    O mejor no.

    > Crítica a Rust:

    www.reddit.com/r/rust/comments/5295nf/why_im_dropping_rust/
  73. #96

    > Que Rust utiliza semánticas de movimiento siempre, y no es bueno usarlas siempre.

    No. Lo que te está diciendo es que C++ es semejante mierda que la práctica recomendada es tremendamente ineficiente.

    In C++, it is possible to accidentally use moved value. Therefore, the move operations usually set the original container size to zero.

    > Y eso un coñazo porque no lo puedes desactivar.

    O dicho de otro modo "déjame introducir bugs en producción que yo sé lo que hago".

    > Contigo no hay nada que hablar.

    Lo dice el del argumentazo de "no entiendes C++".
  74. #98

    > es que ni tan siquiera entiendes como funciona una arquitectura Von Neumann.

    ¿Puedes explicarte? No veo qué tiene que ver.
  75. #98

    > Eso lo dice alguien que utiliza un lenguaje con anotaciones para una de sus características fundamentales (ciclos de vida).

    Un error con tus lifetimes solo puede generar más restricciones, no menos. Por su naturaleza no puedes introducir bugs. Como mucho harás que tu código no compile por haber hecho una restricción demasiado fuerte.
  76. #101 > unsafe pointers

    :-P

    En serio, deja de buscar excusas para odiar a Rust. Tiene muchas cosas malas, pero necesitas estar un tiempo con él para notarlas.

    Dale una oportunidad anda... aunque sea para ganar una perspectiva (y odiarlo con razón).

    Me sigue interesando lo de Von Neumann por cierto.
  77. #104 tío, para un segundo.

    Es obvio que no conoces Rust íntimamente. No puedes criticarlo. Punto.

    Con C++ NO puedes tener Rust a no ser que consideres el hack ese con metaprogramming como "tener" Rust (que no funciona ni similar a los lifetimes... ¿BEGIN_LIFETIME, END_LIFETIME? ¡Qué cómodo!).

    Sin embargo con Rust sí que puedes tener C++. ¿Conoces unsafe? Como deducirás por su nombre, es inseguro. El bug que has pasado es un bug usando código inseguro, es decir, con las mismas garantías que C(++) (ninguna).

    > Also I should note that all the bugs I want to focus on will be related to writing unsafe code.

    Llevo muuuchas lineas tiradas de Rust. ¿Sabes cuántas veces he necesitado unsafe? Dos. Y ya no las necesito desde hace unas pocas versiones.

    Obviamente es el primer artículo que has encontrado buscando "rust bugs" o similar en Google. Y ni te lo has leído. Las respuesta que estás dando son búsquedas rápidas en Google en plan "rust disadvantages" y, lo que es peor, cosas que no sabes exactamente cómo funcionan (como los supuestos "bugs" al "anotar" lifetimes).

    Insisto: Rust tiene mucho para criticarlo, pero de momento ni te has acercado (porque se nota que no lo conoces).

    Aprende Rust para poder criticarlo o deja de tener este tipo de debates innecesarios.

    Por cierto, me sigue interesando lo de Von Neumann.
  78. #108

    > -> &'a u32
    > ¡Qué cómodo!

    1. Eso no es el equivalente a BEGIN_LIFETIME, END_LIFETIME (en Rust no existen) sino a borrow<$2>
    2. Lifetime elision. La mayoría del tiempo no tienes que especificar lifetimes.

    > No vengas a dar lecciones sobre lo que desconoces.

    Muchas palabras vacías, mucha retórica, pero pocas respuestas.

    Bye.
  79. #4 Y en esos casos es donde esta justificado y recomendado usar un goto a un punto final que libera lo que haga falta.
  80. #13 Si, si se la cuelas.
  81. #27 Es tan sencillo como usar goto a una parte final comun que libere lo que haga falta.
  82. #61 Early returns si, pero cuando no haya hasta ese punto mucho que liberar y que no haya que andar haciendo muchas IFs para saber que habia o que no habia hasta ese punto. Cuando hay diferentes niveles de recursos adquiridos, goto a etiqueta final y todas las salidas por un punto unico de liberacion de recursos.
  83. #32 Ojo, valgrind pilla lo que se de en ejecucion, y muchos leaks, desbordes, etc. ocurren raras veces, vamos, que valgrind te pillara cosas que se reproduzcan facil, pero corner cases...
  84. #57 Pero donde ha dicho eso ? No creo que se refiera a Microsoft en el sentido de que ellos programen mal. Lo dice en general, supongo, si aprendes a programar con cuudado en C no necesitas Rust u otros, eso es asi. Ahora, Rust tiene constructos que ayudan EN AlGUNAS COSAS, ojo, que no es una panacea.
  85. #83 Programa un driver de NT en golang... no se como sera eso, pero go es un lenguaje que usa garbage collector y demas... no se, para muchas cosas si, y ningun problema en reconocerle esos meritos, pero no ya solo el lenguaje, sino el hecho de no tener 100% control de que se hace cuando, donde y como... un lenguaje que no tenga eso de una forma completamente explicita y clara... para programavion a bajo nivel, de SO, etc.... yo al memos no lo quiero.
  86. #85 Si, pero solo pilla cosas cuando se dan ( y si, hara que los que a veces se dan pero no petan, peten ). Pero si hay algo que no se reproduce cuando lo ejecutas con valgrind, pues no lo vas a pillar.
  87. #92 Bueno, esa es otra historia, y si, con maa covertura pruebas mas superficie, pero ya me se como va, coverturas del 80-85% y luego salen cosas en cliente.
  88. #106 No, te equivocas. Hay mucho estigma estupido ( como siempre, muy academico pero poco realista ) con el uso del goto. Si ves eso como ironia, lo siento, pero al menos cierto tipo de desarrollo o ciertos entornos no has tocado.
  89. #119 No, de poco recomendable nada, su uso es necesario, mas que recomendable, para salidas a un unico punto, donde se hace todo el tear down.
  90. #8 en el desarrollo a medida, puede. En la venta de paquetes software, ni de coña
  91. #21 «memory leak» -> fuga de memoria. Por favor.

    Pensaba que estaba solo en esta lucha por evitar la desaparición del castellano.
  92. Por si alguien tiene interés en aprender Rust: exercism.io/tracks/rust
  93. #77 Te faltó el ironic al final de la frase
  94. #61 Efectivamente, a eso me refiero, a ficilitar el mantenimiento y la claridad del código. El early return es muy útil cuando está claro y justificado.
  95. #58 En la vida real existen, igual que también existen los casos en que varios return hacen el código más ágil y más eficiente. De todo hay en esta vida.

    Y sí, los memory leaks no son lo peor que uno puede encontrarse, especialmente si se trabaja con codigo antiguo, pensado para plataformas concretas que en un hardware más moderno puede dar otros problemas de los que uno a veces no se da cuenta hasta bastante después de tener el código muy avanzado.

    Y tal y como comentas, trabajar con cadenas multibyte y unicode en ciertas plataformas puede ser un infierno si no se tiene experiencia, paciencia y tiempo. Y de esto último no suele haber.

    Afortunadamente las cosas van evolucionando a mejor y cada vez se cuenta con más y mejores herramientas de trabajo.
  96. #31 ¿En serio me estás diciendo que es mejor ponerse a programar en C o C++ sin saber a la hora de acometer proyectos complejos?
    Yo diría que el "cuñao" aquí eres tú.
  97. #118 Sé perfectamente dónde puede usarse y es recomendable usar un goto. Pero ese tipo de desarrollos y entornos no es ni lo común ni de lo que en líneas generales hablan la noticia o los comentarios. Su uso es muy poco recomendable por norma general en C y C++, y lo es por muy buenas y probadas razones.
  98. #4 por eso para ese tipo de cosas se contrata a alguien que sepa y se le paga bien.
  99. Según mi punto de vista es que ya no hay desarrolladores de C. Los que hay ahora ni saben lo que es un analizador de código estático (cppcheck sin irte muy lejos) ni dinámico (valgrind, que tampoco hablamos de soluciones avanzadas). Se programa en C como se programa en JavaScript, y cuesta mucho enseñar a las nuevas generaciones el tema de lo que realmente se está haciendo con la memoria y el micro a bajo nivel.
«12
comentarios cerrados

menéame