Portada
mis comunidades
otras secciones
#54:
#11 me paso el día en reuniones escuchando a Juniors encorbatados de las consultoras usando palabro tras palabro.
No hablan ni catalán ni castellano ni inglés, hablan "consulto". El lenguaje de los lamebotas, copypasteros de PowerPoints y Excels qué viven de call en call, gathereando informacion de tus equipos para luego hacerte el reporting.
Todo muy corporativo y profesional.
No hablan ni catalán ni castellano ni inglés, hablan "consulto". El lenguaje de los lamebotas, copypasteros de PowerPoints y Excels qué viven de call en call, gathereando informacion de tus equipos para luego hacerte el reporting.
Todo muy corporativo y profesional.
#125:
Rust no necesita mas RAM, pero vamos... titular putapenico, si ves el comunicado de la Casa Blanca... Por no decir que eso de que las vulnerabilidades ( incluso bugs, que es un conjunto mayor al de las vulnerabilidades ) son el 70% por problemas de memory safety... los ultimos estudios o reviews dicen que mas bien al reves, un 30% serian memory safety.
Se algo de Rust y estoy haciendo cosillas y ya incluso mirando de usarlo pa un modulo relativamente grande en un futuro cercano, pero mientras le veo muy buenas maneras para como hacer ciertas cosas como programacion de tipos genericos ( para un sistema de GUI donde los componentes tengan propiedades adheribles dinamicamente y demas ) y mientras le veo cosas muy chulas y bien pensadas, ese memory safety con el tema de las move semantics forzadas, el borrowing y demas... me recuerda un poco al dobleprogramar del TDD.
Claro que, a traves de forzar ese "asignar es mover ownership" y algunas cosas mas ( boundary checking ) puedes conseguir evitar overflows, use after frees, etc., pero hombre... a cuesta de que, por mucho que aprendas y te hagas a programar asi, perder bastante tiempo y flexibilidad. No es, para nada, gratis, por muy experto que seas en Rust.
Y se que suena a cliche, pero segun que tipo de programacion hagas, los bugs y el tiempo depurando no suele ser por cagarla con estos problemas ( ya digo, ese 70% que dicen... nanai, en software de sistemas, si llega a un 30%... ) y en C ( C++ no sabria decir porque para proyectos propios uso C y ensamblador ) no haces apenas gambas en eso.
En fin, ya digo, voy a hacer un sistema GUI para un proyecto que tengo que tiene ya una libreria de interfaz en modo texto bastante potente ( tiene ya abstracciones de paneles, editores, y muchos gadgets mas ) con ciertas caracteristicas y puede que lo haga en Rust por lo que ofrecen los Traits y demas. Va a ser Rust sin runtime ( esa es otra, por mucho que use musl o mi propio runtime que tengo hecho para ejecucion en UEFI/NT, a ver como hago para tener el control de todo eso... ) o, digamos, como el proyecto que tendo no depende de nada, de nada nada, es todo a pelo usando memoria y registros, a ver como me toca los cojones Rust en eso... va a ser un problema, por mucho que digan que Rust bien pa embedded... no es C.
En fin, amor odio con Rust... hay cosas de Rust que molan pero no es la panacea y no, no esta al nivel de versatilidad, flexibilidad y agilidad de C, ni de lejos. C es dios. Es mas que un lenguaje, es un jodido standard de la industria y, por cierto, lo es sin comites, core teams o pollas woke en vinagre. Todo el tema CoC, el Core Team y sus politicas y parte de la comunidad de Rust ( repito, parte, y es facil de imaginar a quienes si y a quienes no me refiero ) es BASURA que echa mucho para atras.
Se algo de Rust y estoy haciendo cosillas y ya incluso mirando de usarlo pa un modulo relativamente grande en un futuro cercano, pero mientras le veo muy buenas maneras para como hacer ciertas cosas como programacion de tipos genericos ( para un sistema de GUI donde los componentes tengan propiedades adheribles dinamicamente y demas ) y mientras le veo cosas muy chulas y bien pensadas, ese memory safety con el tema de las move semantics forzadas, el borrowing y demas... me recuerda un poco al dobleprogramar del TDD.
Claro que, a traves de forzar ese "asignar es mover ownership" y algunas cosas mas ( boundary checking ) puedes conseguir evitar overflows, use after frees, etc., pero hombre... a cuesta de que, por mucho que aprendas y te hagas a programar asi, perder bastante tiempo y flexibilidad. No es, para nada, gratis, por muy experto que seas en Rust.
Y se que suena a cliche, pero segun que tipo de programacion hagas, los bugs y el tiempo depurando no suele ser por cagarla con estos problemas ( ya digo, ese 70% que dicen... nanai, en software de sistemas, si llega a un 30%... ) y en C ( C++ no sabria decir porque para proyectos propios uso C y ensamblador ) no haces apenas gambas en eso.
En fin, ya digo, voy a hacer un sistema GUI para un proyecto que tengo que tiene ya una libreria de interfaz en modo texto bastante potente ( tiene ya abstracciones de paneles, editores, y muchos gadgets mas ) con ciertas caracteristicas y puede que lo haga en Rust por lo que ofrecen los Traits y demas. Va a ser Rust sin runtime ( esa es otra, por mucho que use musl o mi propio runtime que tengo hecho para ejecucion en UEFI/NT, a ver como hago para tener el control de todo eso... ) o, digamos, como el proyecto que tendo no depende de nada, de nada nada, es todo a pelo usando memoria y registros, a ver como me toca los cojones Rust en eso... va a ser un problema, por mucho que digan que Rust bien pa embedded... no es C.
En fin, amor odio con Rust... hay cosas de Rust que molan pero no es la panacea y no, no esta al nivel de versatilidad, flexibilidad y agilidad de C, ni de lejos. C es dios. Es mas que un lenguaje, es un jodido standard de la industria y, por cierto, lo es sin comites, core teams o pollas woke en vinagre. Todo el tema CoC, el Core Team y sus politicas y parte de la comunidad de Rust ( repito, parte, y es facil de imaginar a quienes si y a quienes no me refiero ) es BASURA que echa mucho para atras.
#10:
#5 ... perdon? si quieres estructuras de datos complejas que tienes que crear, necesitas C, y si quieres OOP, C++.... . Tengo que echarle una mirada a Rust cuando termine mi clase de estadistica, pero el uso de punteros es necesario.
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
#108:
#98 No, no hace más trabajo y más comprobaciones.
Lo que hace es prohibir/impedir (salvo que te emperres usando métodos unsafe) que se pueda hacer algo mal, para que no haga falta comprobar si se hace algo mal.
Así te ahorras el esfuerzo mental de programarlo sin vulnerabilidades y las comprobaciones en tiempo de ejecución.
Y te lo dice un programador de C a pelo con toda la gestión de memoria manual y que Rust lo ha tocado bien poco pero las ventajas saltan a la vista.
Por cierto, no me parece bien que te pongas a decir que los que hablan de las ventajas de Rust sobre C tengan una "obsesión". En ese caso, ¿tú tienes una obsesión con C/C++? Pero encima si lo estás haciendo sin saber nada de Rust ni documentarte sienta peor.
Pero sé que no hay mala intención en lo de obsesión, te lo digo solo para que lo sepas.
Saludos.
Lo que hace es prohibir/impedir (salvo que te emperres usando métodos unsafe) que se pueda hacer algo mal, para que no haga falta comprobar si se hace algo mal.
Así te ahorras el esfuerzo mental de programarlo sin vulnerabilidades y las comprobaciones en tiempo de ejecución.
Y te lo dice un programador de C a pelo con toda la gestión de memoria manual y que Rust lo ha tocado bien poco pero las ventajas saltan a la vista.
Por cierto, no me parece bien que te pongas a decir que los que hablan de las ventajas de Rust sobre C tengan una "obsesión". En ese caso, ¿tú tienes una obsesión con C/C++? Pero encima si lo estás haciendo sin saber nada de Rust ni documentarte sienta peor.
Pero sé que no hay mala intención en lo de obsesión, te lo digo solo para que lo sepas.
Saludos.
#13:
#10 lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria
Precisamente eso es lo que ha hecho Rust. Incorporando, por una parte, el concepto de "propiedad" a los valores almacenados en memoria (liberando ésta cuando el propietario sale del scope) y el de "borrowing" (que permite acceder a los datos sin cambiar la propiedad) y, por otra parte, incorporando un montón de reglas al compilador (que evitan buffer overflows, race conditions, referencias nulas...), que C/C++ incluye, en el mejor de los casos, en analizadores estáticos.
el uso de punteros es necesario
Tanto Rust como C/C++ incluyen raw pointers, smart pointers, referencias... La diferencia es que Rust desaconseja los raw pointers (obligando a marcar el código como "unsafe").
C++ tiene más de 40 años y, aunque ha ido incorporando muchas mejoras a lo largo de los años, tiene serias carencias en cuanto a seguridad. En los últimos años se desarrollaron varios lenguajes que intentaban resolver estas carencias. A día de hoy, parece bastante claro que Rust ganó esa batalla y que acabe sustituyendo a C++ por completo será sólo cuestión de tiempo. Microsoft era el gran valedor de C++ y Linux el de C, y ambos están empezando a darles la espalda.
Precisamente eso es lo que ha hecho Rust. Incorporando, por una parte, el concepto de "propiedad" a los valores almacenados en memoria (liberando ésta cuando el propietario sale del scope) y el de "borrowing" (que permite acceder a los datos sin cambiar la propiedad) y, por otra parte, incorporando un montón de reglas al compilador (que evitan buffer overflows, race conditions, referencias nulas...), que C/C++ incluye, en el mejor de los casos, en analizadores estáticos.
el uso de punteros es necesario
Tanto Rust como C/C++ incluyen raw pointers, smart pointers, referencias... La diferencia es que Rust desaconseja los raw pointers (obligando a marcar el código como "unsafe").
C++ tiene más de 40 años y, aunque ha ido incorporando muchas mejoras a lo largo de los años, tiene serias carencias en cuanto a seguridad. En los últimos años se desarrollaron varios lenguajes que intentaban resolver estas carencias. A día de hoy, parece bastante claro que Rust ganó esa batalla y que acabe sustituyendo a C++ por completo será sólo cuestión de tiempo. Microsoft era el gran valedor de C++ y Linux el de C, y ambos están empezando a darles la espalda.
#5:
Esto era evidente. C/C++ son lenguajes muy artesanales, donde el programador se encarga de gestionar la memoria a mano. Eso puede sonar super chulo, pero excepto en cosas muy muy concretas, es completamente innecesario, y solo sirve para generar problemas derivados de la incorrecta gestión de la memoria de manera manual.
#21:
Pues a ver si les hacen caso, C y C++ se convierten en más minoritarios y los que sabemos podemos pedir como las estrellas del fútbol.
Comentarios
#6 Y "proteger" mejor que "secularizar", "securizar" o "segurizar". Todo lo demás son patadas a la lengua e intentos de adaptar la palabra "secure" cuando ya existe una palabra para ello.
#11 me paso el día en reuniones escuchando a Juniors encorbatados de las consultoras usando palabro tras palabro.
No hablan ni catalán ni castellano ni inglés, hablan "consulto". El lenguaje de los lamebotas, copypasteros de PowerPoints y Excels qué viven de call en call, gathereando informacion de tus equipos para luego hacerte el reporting.
Todo muy corporativo y profesional.
#54 los pelos como escarpias
#54 Espero que al menos lo cobres bien...
#54 Tu comentario me ha recordado a este video
#54 Gathereando???????
#54 Que no se olvide:
#54 hace poco participé en un proceso de selección que tenía buena pinta hasta que recibí un correo del que me iba a hacer la siguiente entrevista y estaba escrito en un consulto insoportable. Les dije que había cambiado de idea.
#54 mi mas sentido pésame par tus neuronas
#54 En las mismas, al fin y al cabo, seguramente como gran parte de Menéame.
Entiendo que terminemos hablando un lenguaje criollo en horas de trabajo con tanto anglicismo y acrónimos. Y creo que es sano limitarlo un poco; aunque creo que en mayor o menor medida todos nos dejamos llevar por la comodidad hasta cierto punto. Para mí el mayor problema viene de olvidarse o no saber que se pueden usar palabras ya existentes sin añadir longitud o complejidad especial; y que esto se retroalimente y refuerce entre compañeros. Y me parece incluso peor escrito que hablado.
Prefiero que alguien diga la palabra en inglés y separe idiomas, registros y entornos que no que se saque una mezcla como "contenerizar", "deployar" o "securizar". Y lo que es peor, que esto se escriba en documentos "serios".
#11
De acuerdo con lo que dices, solo que secularizar si existe aunque no tiene mucho que vez con la seguridad informatica. Yo odio el "encriptar" cuando no se habla de criptas.
Se me ha ido la.olla y en vez de darte a responder te he dado negativo, te doy otro par de positivos luego
#89 Sí, sí; la palabra existe. Es sólo que en este contexto no tiene sentido.
A mí también me da grima que se use lo de "encriptar", quizá porque me enseñaron que no era el término correcto (para eso está "cifrar", al fin y al cabo). Pero me parece que cada vez lo aceptan más, incluso quienes trabajan directamente en la materia. Como decían en una película, el lenguaje también actúa como un virus y hay que tener cuidado con lo que se transmite.
No te preocupes por lo otro. Gracias por la explicación en todo caso.
#89 Encriptar no proviene de cripta sino de criptografía, Del griego Kriptos = ocultar, Graphos = escritura.
Encriptar es ocultar la información cifrándola mediante el uso de clave/s.
Si lo prefieres puedes usar el sinónimo cifrar, pero encriptar aparte de ampliamente utilizado esta admitido.
https://dle.rae.es/encriptar
Pues a ver si les hacen caso, C y C++ se convierten en más minoritarios y los que sabemos podemos pedir como las estrellas del fútbol.
#21 o como desarrolladores de Cobol
Esto era evidente. C/C++ son lenguajes muy artesanales, donde el programador se encarga de gestionar la memoria a mano. Eso puede sonar super chulo, pero excepto en cosas muy muy concretas, es completamente innecesario, y solo sirve para generar problemas derivados de la incorrecta gestión de la memoria de manera manual.
#5 ... perdon? si quieres estructuras de datos complejas que tienes que crear, necesitas C, y si quieres OOP, C++.... . Tengo que echarle una mirada a Rust cuando termine mi clase de estadistica, pero el uso de punteros es necesario.
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
#10 lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria
Precisamente eso es lo que ha hecho Rust. Incorporando, por una parte, el concepto de "propiedad" a los valores almacenados en memoria (liberando ésta cuando el propietario sale del scope) y el de "borrowing" (que permite acceder a los datos sin cambiar la propiedad) y, por otra parte, incorporando un montón de reglas al compilador (que evitan buffer overflows, race conditions, referencias nulas...), que C/C++ incluye, en el mejor de los casos, en analizadores estáticos.
el uso de punteros es necesario
Tanto Rust como C/C++ incluyen raw pointers, smart pointers, referencias... La diferencia es que Rust desaconseja los raw pointers (obligando a marcar el código como "unsafe").
C++ tiene más de 40 años y, aunque ha ido incorporando muchas mejoras a lo largo de los años, tiene serias carencias en cuanto a seguridad. En los últimos años se desarrollaron varios lenguajes que intentaban resolver estas carencias. A día de hoy, parece bastante claro que Rust ganó esa batalla y que acabe sustituyendo a C++ por completo será sólo cuestión de tiempo. Microsoft era el gran valedor de C++ y Linux el de C, y ambos están empezando a darles la espalda.
#13 Te has olvidado de mencionar las mejoras de C++ desde C++11, C++14, C++17, C++20, etc...
#15 Y el uso del punto y coma Ninguna de esas mejoras incluye la automatización completa de la gestión de memoria (que sí incluye Rust) ni una seguridad en tiempo de compilación equiparable a la de Rust, que es de lo que estamos hablando.
#5 #10 #13 #15 JS for the win!
#19 JS... Te refieres a Jung/Spinoza? No me suena a ninguna otra cosa
#19 reportado
#19 #55 Cualquiera que programe en ...JS (ANATEMA!!!!) merece el castigo mas cruel posible: escribir ensamblador para al IBM 370!!!!!
#19 JS es de esas cosas que aprendi a odiar en los 2000... que he visto ahora y me ha sorprendido gratamente, pero es como la tortilla de espinacas que te hizo comer tu madre con 8 anios, que aunque las espinacas esten cojonudas en un restaurante pijo, sigues acordandote de la puta tortilla de espinacas y como las odias con todo tu ser.
#13 Luego, te pones a implementar una lista doblemente enlazada en Rust y el compilador te dice
"Para qué quieres hace eso jaja saludos"
#60 Pero es que tiene razón. No he tenido que programar una de esas desde que salí de la carrera. Arrays de datos y arrays de índices FTW.
#60 use yo::ke::se;
Rust las incluye en la stdlib: std::collections::LinkedList. Pero teniendo en cuenta que el principal caso de uso de las listas doblemente enlazadas es implementarlas para resolver pruebas de programación, tienes dos opciones:
- Usar smart pointers: Rc permite varios owners y RefCell mutabilidad interna (con la penalización de las comprobaciones en tiempo de ejecución), o...
- Usar "unsafe" y hacer lo mismo que harías en un lenguaje como C++
Rust proporciona un montón de mecanismos de seguridad que en C++ ni están ni se les espera, pero también puedes prescindir de ellos.
#60 A ver, es como eso de que JAVA es interpretado... y luego te sale la ostia esa de ClassDefNotFound, que es que un linker se ha pegado una ostia, pero te enteras en ejecucion. Ya se lo de el linkado dinamico enLinux, pero no deja de ser gracioso.
No hace tanto he visto ese error y me han dicho: "Que es el linker?", la madre que me pario del amor hermoso!!!!!!!!
#13 Díselo a los de OpenBSD usando S en /etc/malloc.conf, donde ahí es probable que detox casque como tien que ser.
Muchos de esos problemas con C se han arreglado con las mitigaciones de OpenBSD, opciones de malloc, y pledge y unveil en Firefox y Chromium.
#10 no necesitas C para crear estructuras de datos complejas. Puedes hacerlo con cualquier lenguaje de programación moderno. Lo mismo sucede con la POO.
#24 depende del tamaño de esa estructura... He visto sufrir mucho al garbaje colector de java en proyectos muy grandes... Y al equipo de desarrollo sufrir aun más intentando mejorar el rendimiento...
Nota: yo está como "sistemas" en las reuniones en las que daban caña al equipo de producto... No soy programador.
#36 #57 Eso es una exageracion,... TID tenia una aplicacion que era en X-Windows que movieron a JAVA ... en un applet!!!!! Y vale... el bicho tardaba en cargar ... unos 5 minutos... pero luego funcionaba como un tiro. Y hablamos de aplicacion con calculos matematicos, comunicaciones, ... incluso tenia una herramienta que abstraia todos los ordenadores de una red y permitia mover ficheros en una especie de sistema de archivos distribuido a traves de maquinas locales, servidores en red, ... con un interfaz grafica que encapsulaba FTP y sistemas de ficheros locales de windows y Unix (Solaris), . Y estamos hablando del anio 2000. Y no tuve que pegarme para que aquello corriera, a veces las JVM se le iba la perola, pero ... corria medio bien.
#24 Una vez hice un programa en Java y compilé. Aun estoy esperando a que la VM se encienda.
#57 ¿Estaba conectada?¿HIciste el sacrificio ritual de niños en el altar? Suena a que es problema tuyo.
#57 a mi de pequeño me gustaba el helado de pistacho.
#24 Si, y quizas el problem ahi es de edad. Yo me trague las clases de Estructuras de Datos en C y C++, y siempre me ha costado hacerme las bibliotecas en JAVA. Python es raro de cojones y lo utilizo para otras cosas. Go y RUST, son para cuando termine mis clases de ML.
#10 Tienes que mirar Rust. Te va s sorprender. Yo go tampoco está nada mal en cuanto a protección de acceso a memoria ilegitima.
#45 No soy programador, pero confío plenamente en el criterio de cierto amigo mío que sueña en código, donde me mencionó, hace ya algunos años, que Go era una PM a la altura de PHP, y que si quería hacer algo serio usara Rust.
Ya se que confiar en este comentario sin más pruebas es una estupidez pero confío plenamente en su criterio.
#80 Go es esa PM de lenguaje en el cual está desarrollado ni más ni menos que Kubernetes. Y PHP el sustento de gran parte de la web vía Wordpress. Cada lenguaje tiene su uso y ventajas. Catalogar a Python de PM es extremadamente sencillo, y no por ello es un lenguaje con una grandísima utilidad y el más adecuado en muchos escenarios. Por lo que simplemente es un talibán más o un iluminado de la pureza de los lenguajes funcionales.
#99 Si es un Talibán es mi talibán de cabecera
#80 es difícil encontrar un lenguaje de programación que da tantas facilidades para manejar cadenas y expresiones regulares como PHP. Por eso es una herramienta muy útil para web.
#80 PHP ha mejorado muchísimo con las últimas versiones, y no, PHP no es una mierda, siempre lo suele decir la gente que nunca lo ha tocado o que se quedó en PHP 4 de hace 20 años.
#80 No te fíes de tu amigo para decisiones importantes.
#_80 #45 Tu amigo tiene opiniones muy raras.
Si necesitas hacer algo crítico en lo que no te fies del GC, por supuesto que Rust es un candidato ideal.
Para montar una API decentilla, o crear un CLI, o cualquier cosa medianamente compleja que tampoco sea súper crítica, Go es una maravilla. Ya vale la pena solo por la cantidad de herramientas que te da la librería estándar sin tener que bajarte paquetes de otros.
#93 Ya, pero tambien pasa que hay cosas que no son API o CLI. Ejemplo: SACTA, o los sistemas de control de redes telefonicas.
#45 Ya, es que me ha dado desde hace algunos anios por Ciencia de Datos y ... a ver, que C/C++ fueron mis amores de juventud, pero me toco escribir JAVA durante muchos anios, y ahora estoy lejos del codigo por mandato profesional.
En cuanto tenga tiempo quiero mirar Rust. Lo he empezado, pero en cuanto tengo tiempo me meto con matematicas para ML y esas cosas.
#10
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
El propio creador de C++ decía algo parecido. Él sugiere el uso de analizadores de código estático. Supongo que habría que meterle a estos analizadores algo más. Por ejemplo, la notación:
https://github.com/selairi/memory_notation.h
Por cierto, si tenéis algún segment fault o memory leak, recomiendo leer:
https://github.com/selairi/memory_notation.h/blob/main/PROBLEMS.md
Para los memory leaks lo mejor es Valgrind:
https://cartaslinux.wordpress.com/2020/04/05/valgrind-buscando-errores-de-memoria-en-c-y-c/
#10 ¿tu clase de estadística? eres un imberbe que está todavía en las aulas ¿y vienes a dar lecciones de programar?
#87 por como habla se nota bastante
#87 #90 #124 #138
Es que a los mayores de 40 no nos han prohibido todavia volver a la universidad.
Y ademas ahora existe Internet y puedes sacarte una carrera en universidades en otro continente.
En mi caso estoy intentando una segunda carrera en Ciencia de Datos y estoy pegandome con las asignaturas de matematicas porque hace mas 25 anios que me hice las de la carrera.
Soy mas bien calvo, que cuando empece usabamos el Turbo Pascal y el Turbo C, y OWL era un adelanto de la polla en vez de programar windows con la API en C a pelo,... y teniendo que cargar las entradas de las dll mirando los segmentos de memoria porque era win32 y en mi memoria de persono mayor me acuerdo de que habia un pollo bien montado con los puntos de entrada de las dll si tenias win32 en vez de 16 bits... pero hace mucho de eso.
#90 Lo mismo que para el otro, me toco la codena de escribir ensamblador para la 370. Pero paso hace mucho.
#87 Podría ser su tercera carrera y tal...
#87 Aprender es una maravilla y se puede hacer toda la vida, pero el sistema actual nos hace asociar "aprender" con "debilidad", es todo lo contrario.
#87 El mejor leguaje es Fortran77, y a mi no me gusta el quiche.
#87 Espera, que se me habia olvidado... tambien he escrito codigo en COBOL y profesionalemente en ensamblador de la 370. Pero por lo menos mi codena fue corta, de solo un anio.
#5 Ups, veo que te quedastes en la prehistoria del lenguaje... hoy en dia en C++ con Smart Pointers (std::unique, std::shared) no tienes que gestionar mucho... pero siempre es mejor hablar de oidas
#14 conozco bien los smart pointers, igual que seguro que los conoce la casa blanca
Pero eso solo alivia algunos de los problemas, no resuelve el problema. Por qué el problema es el modelo de gestión de memoria y la forma en la que el programador se relaciona con el.
De hecho, por eso existe rust. Si fuese como tú dices, no haría falta rust para nada.
#25 #14 Sin acritud, desde al menos C++ 11, puedes prescindir de news, deletes, mallocs, allocs, frees y shared pointers si quieres.Yo llevo años haciéndolo, ya solo uso punteros cuando me toca cambiar codigo legacy
#32 Puedes prescindir de news, pero también puedes usarlos. Y ese es el riesgo.
Especialmente en desarrollo de drivers y código que necesita alto rendimiento, el programador está muy tentado a saltarse todas las buenas prácticas. En Rust o Go, el riesgo está mucho más acotado y con un rendimiento similar.
#49 Solo quería puntualizar que no es obligatorio, veo mucho desarrollador asustado por la gestión de memoria dinámica. Simplemente apunto que si no te gusta o no estás seguro de saber lo que haces puedes evitarlo y usar los recursos que tienes desde C++11
Que prefieres Rust? Pues genial
Saltarse "las prácticas" pasa con todas las tecnologías y todas las áreas de la vida misma
#64 Claro. Pero la noticia cita un marco normativo para proyectos USA. Y a los gobiernos les gustan las normas y no tener que confiar en las buenas prácticas de los miles de programadores que contribuyen.
Habiendo lenguajes equivalentes, empezar un proyecto nuevo en C/C++ tiene poco sentido en la inmensa mayoría de casos. Y te lo dice un ex programador de C.
#71 Desde el respeto, eso es tu opinión
Respetable, por supuesto, pero no es necesariamente verdad
#64 El tema aquí no es que haya programadores asustados de la complejidad de C/C++. Los asustados son los pagadores de proyectos que se hartan de exploits en sus sistemas críticos.
#73 Entiendo que sin C/C++ se acaban los exploits.
No lo sé, pero me suena raro
#77 Con Rust es mucho más fácil no cometer errores de acceso a memoria, y se hace muchísimo más difícil cometerlos, por lo que es mucho más difícil (de hecho imposible si lo que programas no está marcado como unsafe) producir aplicaciones con exploits.
A ver si me explico: con Rust no tiene sentido usar Valgrind, porque nunca vas a leer o escribir fuera de rango (que es lo que hacen la mayoría de exploits para ganar acceso a un sistema, aprovechar un fallo de esos para escribir donde les interesa fuera del espacio de usuario).
Y encima, Rust consigue eso sin utlilizar un recolector de basura, por lo que es igual de eficiente que C (o más, porque permite mejores optimizaciones en tiempo de compilación, aunque eso aún no se nota, el compilador está verde aún).
#95 No conozco Rust para debatir/rebatir lo demás.
"Rust consigue eso sin utlilizar un recolector de basura, por lo que es igual de eficiente que C"
Hace más trabajo y más comprobaciones consumiendo menos cpu/recursos? qué es lo siguiente? La máquina de movimiento perpetuo?
En serio, creo que toda tecnología tiene su aplicación pero está obsesión de algunos, no lo tomes personal por favor, de demonizar C++ por los "riesgos" que podría tener la flexibilidad que te daba el C ...me suena a trauma infantil
#98 No, no hace más trabajo y más comprobaciones.
Lo que hace es prohibir/impedir (salvo que te emperres usando métodos unsafe) que se pueda hacer algo mal, para que no haga falta comprobar si se hace algo mal.
Así te ahorras el esfuerzo mental de programarlo sin vulnerabilidades y las comprobaciones en tiempo de ejecución.
Y te lo dice un programador de C a pelo con toda la gestión de memoria manual y que Rust lo ha tocado bien poco pero las ventajas saltan a la vista.
Por cierto, no me parece bien que te pongas a decir que los que hablan de las ventajas de Rust sobre C tengan una "obsesión". En ese caso, ¿tú tienes una obsesión con C/C++? Pero encima si lo estás haciendo sin saber nada de Rust ni documentarte sienta peor.
Pero sé que no hay mala intención en lo de obsesión, te lo digo solo para que lo sepas.
Saludos.
#98 Rust añade el código para gestionar la memoria en tiempo de compilación.
#98 El sistema de asignación de memoria es muy simple (muy parecido a RAII), y soluciona el problema de la gestión de memoria de un modo elegante.
Aparte el compilador es muy moderno y está muy muy optimizado y da errores con sentido (no como los que hemos sufrido durante décadas en C++).
En el tema de performance, hay algunos benchmarks en los que Rust funciona mejor que C (por ejemplo en pidigits aquí https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html ), pero es porque el compilador es mucho mejor y optimiza mejor que g++, nada de movimiento perpetuo, el tooling de Rust es mucho mejor que el de C++ de lejos, sin hablar de la gestión de librerías moderna que viene integrados.
De todas maneras, permíteme que exprese mi opinión sobre el tema del performance: una diferencia de performance del 1 al 5% en prácticamente todos los sistemas modernos es irrelevante, igual tiene un pase en los sitemas embebidos, pero para el resto es ridículo que se use el argumento del performance, cuando la ganancia en seguridad es muchísimo mayor:
* Preferirías que tu aplicación fuera un poquito más lenta (un 5% por ejemplo) o que por diseño no pudiera tener memory leaks ni punteros inválidos?
#49 "el programador está muy tentado a saltarse todas las buenas prácticas"
...linters, y static code analysis en la pipeline son tus amigos
#49 Al final se trata de eso, si en un edificio tienes un cuarto con cables de alta tensión, puedes poner un cartel de "peligro" y quedarte a gusto, o puedes poner un candado. De hecho muchos aspectos de diseño orientados a seguridad (reales o de software) básicamente tratan de que las situaciones de riesgo sean imposibles, o desincentivarlas lo máximo posible.
#32 La idea de todo esto, es que las personas cometen errores. La gestion de punteros, mas o menos de forma automatica es el problema, porque el programador la puede cagar sin darse cuenta. Eliminando eso, aka Rust, eliminas el problema.
#58 Es que no necesitas gestionar punteros desde C++11 !!!
He visto memory leaks y cuelgues usando lenguajes "sin punteros"
Los errores se cometen sin punteros también
#14 #32 Siempre se ha podido usar RAII, desde antes incluso de C++11. El memory safety no es algo que C++11 ni ninguno de las actualizaciones posteriores haya solucionado.
C / C++ son leguajes potentísimos que mal usados te vuela el pie, una buena analogía puede ser un bazooka.
Es un lenguaje que de potente que es, te puedes llevar un buen disgusto. Sobre todo perfiles que no tengan un buen y largo bagaje de programación.
Y claro, el legacy de C++ es como el legacy estándar solo que con nuevos superpoderes: memory leaks, punteros inválidos ... para mí tiene que estar muy muy justificado programar algo en C/C++ hoy en día.
#14 Con los ultimos cambios en c++ con los smart pointers hay poco que gestionar de memoria
#5 es que esas cosas muy muy concretas son la base de todo el castillo que se monta por encima.
Aparte que desde c11 y posteriores la cosa ha ido mejorando.
#5 C/C++ son lenguajes muy artesanales
¿Lenguajes "artesanales" ?
donde el programador se encarga de gestionar la memoria a mano.
He programado en C durante años y jamás he "gestionado la memoria a mano". He cogido memoria cuando la he necesitado y la he liberado cuando ya no me hacía falta.
No es tan difícil.
Los problemas de seguridad se derivan de una mala programación. Y mientras haya esas malas praxis habrá problemas. Uses Javascript, PHP, Rust o lo que quieras.
Hoy en día los problemas de buffer-overflows que es lo más típico debido a la falta de control en el almacenamiento en memoria en C no son los peores problemas de seguridad ni de lejos.
#41 Los accidentes de tráfico se derivan de una mala conducción. Y mientras haya esas malas praxis habrá problemas. Uses cinturón, airbags o lo que quieras.
#59 Me parece una muy dudosa analogía. Según dices, Rust es la solución a los "accidentes" de programación, ¿Cual es la solución a los accidentes de tráfico?
#59 Exacto. Por lo cual debemos pedirle a la gente que deje de conducir.
#41 Si la cojes como quien tiene un saco de algarrobas pues no hay problema, claro.
Yo no he programado extensamente en C pero, precisamente, C te PERMITE hacer optimizaciones del uso de la memoria que no estan al alcance de lenguajes de más alto nivel. Como por ejemplo alinearte con los tamaños de pagina para reducir las llamadas del S.O.
Si, C *puede* usarse de forma artesanal y conseguir cotas de rendimiento y reduccion de huella de memoria muy interesantes.
Pero hacer eso y NO CAGARLA no esta al alcance de cuaquiera ... y por ahi ha de venir el problema.
Es un tema que era importante especialmente en dispositivos embebidos, no se como andará la cosa ahora.
#5 Tu no has tocado c++ desde hace 23 años, así como poco.
Trabajé 5 los en proyectos en C++ y teníamos prohibido gestionar la memoria, y no tuvimos ni una fuga de memoria en esos años.
#61 claro, pero para no tener que "tenerlo prohibido", es mejor no tenerlo
Yo toco c++ cada día, como parte de mi trabajo, ya está bien de ataques personales que no aportan nada
#5 Hace muuuuchos años habia que gestionar la memoria RAM porque habia muy poca, que hoy todos los sistemas tengan memoria de sobra hace que dicha gestion sea "menos" importante, pero en su momento cada kilobyte, incluso cada byte, contaba.
#33 Y además, el arma definitiva contra un jedi es una pistola con tres cañones que disparen simultaneamente; no hay linea recta que pueda repeler los tres tiros a la vez.
#46 Qué va, entonces dan un salto mágico de dos metros.
#46 matemáticas al rescate jejeje
#46 el de casco oscuro sí puede
Una cosa que no queda clara es si la estela que deja el sable de luz también repele. ¿Hay algún tipo de atracción entre el sable y los láseres?
Luego si hay alguien que usa pólvora pues se le tira el sable de luz haciendo el molinillo a la cara y ya está
#33 A mí me confundía la forma en que usaban los sables de luz en las nuevas películas. Sale el llorón cortando árboles de un tajo, pero luego a los buenos les roza un poquito haciéndoles una quemadura de primer grado, que parece sanarse en cuestión de segundos y se mueven con total normalidad. Cuando mata a Han Solo, lo empala atravesándole el vientre en una escena que ya de por sí no tiene ningún sentido. En el grupo de frikiamigos todos pensamos que lo coherente con lo mostrado hasta el momento es que el cuerpo se hubiera partido en dos, cayendo por su propio peso. Nadie se queda completamente quieto cuando siente algún dolor en la zona abdominal y a poco que se mueva con un sable láser dentro...
En las tres primeras el movimiento del sable al estilo kendo tiene más sentido porque la prioridad en cualquier estilo de combate es no hacerte daño a ti mismo. Precisamente el entrenamiento de Luke es en su mayor parte defensivo. En las demás películas, cuando están todo el rato haciendo el molinillo como una majorette resulta ridículo.
#84 ya el Maestro Yoda en plan frijol saltarín puesto hasta arriba de redbull con el sable en moto ventilador ni te cuento...
Es que Disney "olvidó" el funcionamiento de los sables láser de forma muy conveniente para intentar suavizar el impacto "gore". En algunos juegos nuevos de la franquicia parece que estés pegando guantazos con una porra fluorescente. En cambio en el antiguo Jedi Knight (qué tiempos...) caían trozos si golpeabas una extremidad.
#46 Un Jedi simplemente parará las balas.
Luego algunos pierden maletas con datos en USB sin secularizar.
#2 un palabro muy raro ese de secularizar.
#3 Es que la iglesia todavía tiene mucho poder.
#2 segurizar, mejor que securizar
#2 Siendo Estados Unidos me creo que alli no permitan USB secularizados, ser pagano no esta muy bien visto por alli
#2 ¿Eran datos religiosos?
#2 Es que el USB una vez bendecido, bendecido queda.
Ya no se puede secularizar.
#2 secuque?
#2 y que los tenían, en seculmander todavía?
¿No se vende suficiente RAM y tienen que animar las ventas?
#1 rust no necesita más RAM
#1 #12 Os cuento un chiste muy malloc()?
...
#17 ¿Cuántos años llevas esperando la oportunidad de soltar eso?
#18 ¿Qué te hace pensar que es la primera vez que lo suelta?
#18 Un buen ingeniero es experto en el uso del , lo habrá usado mil veces ya
#86 Es lo que se conoce por codigo reutilizable? o programacion por objetos?
#17 Tu gracia se ha fugado.
#17 Segmentation fault
#17 unhandled bad joke exception
#17 Lo veo y subo:
Programar punteros en C es como hacer malabares con el jabón en la ducha de la carcerl: todo es diversión hasta que cometes un fallo.
#44 Recuerda, siempre acabas cometiendo un fallo, por lo menos }
#17 me tenéis los frikis de chistes malos hasta el conio.h
#63 Pues a saber lo que queda de tu himem.sys
#81 bien traído, vive (ms)DOS
#63: ¿Qué es conio.h?
Me lo acaba de preguntar GCC.exe, que no sabe lo que es.
#63 Normal, estás anticuada.
#17 cuando compramos el piso, mi mujer mira la ventada y dice "aqui tendríamos que poner unos estores" , y yo dije "y por que no unos loads?" ... aun sigue casada conmigo, pero solo me reí yo, y me sigo riendo de hecho al pensarlo
#92: ¿La has preguntado si la gusta la música .pop() ?
#17 What the fork()!
#17 Adelante, siéntete free().
#1 De hecho muvhat veces consume menos RAM, al hacerlo mejor.
No sé las repercusiones que tendrá esto a largo plazo (sobre todo teniendo en cuenta la inercia brutal que tienen las inmensas cantidades de legacy code en esos lenguajes, de manera crucial en SO-s, y que existen ya desde hace décadas iniciativas y experiencia acumulada para hacer un uso más seguro de ellos como MISRA, herramientas de linting, QA y similar...), pero meneo.
Para quién le intentese, mandé el otro día el comunicado de la Casa Blanca citado en el envio:
- Comunidado de Prensa de la Casa Blanca: El software del futuro debería ser seguro para la memoria [ENG]
Comunidado de Prensa de la Casa Blanca: El softwar...
whitehouse.govSi recomiendan Javascript han demostrado que a lo que digan no hay que hacerle mucho caso
#48 ¿porqué?
"Este llamamiento es una consecuencia de la creciente preocupación con la ciberseguridad provocada por incidentes como la grave vulnerabilidad Log4j"
Por favor, que alguien me explique esto. No entiendo como la vulnerabilidad de una librería de Java puede tener como consecuencia un llamamiento a dejar de utilizar C/C++ y ofrecer Java como una de las alternativas.
#52 Han visto que por ahí es más fácil meter back doors
#62 ¿Te refieres a que es más fácil que ellos pongan backdoors en la máquina virtual de los lenguajes interpretados y por ello quieren que se usen?
Me da la sensación de que nos están tomando por gilipollas, pero de una manera tan burda que me cuesta creerlo y pienso que soy yo que no lo estoy entendiendo.
#65 Si.
#52 Porque la noticia la ha hecho el becario de la Casa Blanca.
El otro día leí que más de la mitad de las vulnerabilidades de los sistemas venían de las librerías gratuitas.
#69 la otra mitad, de las de pago
Está relacionado con los fallos de memoria del inquilino de la Casa Blanca.
igual alguien se toma en serio la sugerencia.
#7 El propio Biden en el despacho oval ahora mismo bajandose el compilador de Rust
¿Y para qué programar en C/C++ habiendo PHP?
#30 FastCGI
¿Le pedirías a un samurái que deje de usar su katana? ¿O a un jedi su sable de luz?
#26 A un jedi su sable de luz, por supuesto. Manejar ese arma es como hacer malabares con sierras mecánicas; sólo es cuestión de tiempo que te cortes tú mismo en dos.
#31 y como decía un amigo: "sigo sin entender para qué sirve blandir de esa forma una hoja que corta cualquier cosa sólida y no tiene peso" y hacía el gesto de llevarla extendida hacia delante moviéndola un poco como el bastón de un ciego en horizontal.
#26 queda muy guay eso de compararse con ninjas y jedis en tu pefil de RRSS, pero el 95% de los programadores de C que conozco son más bien salchichas peleonas que cualquier otra cosa.
Hola, yo no soy informático así que no puedo participar en el debate ni en el festival del humor. Solo quería decir que me parece muy feo que una compañía grande como la editora de genbeta utilice AI para ilustrar sus artículos. Es cutre y está mal. Creo que voy a boicotear cualquier web que use ai para ilustrar o escribir sus artículos.
#40 , La imagen no aporta nada a la noticia y si no estuviera no cambiaria nada. De hecho, me he leido la noticia y he tenido que volver atras para mirar la imagen porque ni me habia fijado en ella. Si la imagen no estuviera el articulo me aportaria exactamente lo mismo. Personalmente no me parece cutre y no acabo de entender por que "esta mal". A no ser que seas vinetista y veas tu modo de vida atacado, no veo ningun problema.
#40 ¿deberían contratar a un ilustrador? Porque luego si piden dinero también estará mal, y no le van a tener encadenado y sin comer más que lo habitual en una prisión rusa.
#70 Si, yo creo que deberían. No creo que esté bien engordar aún más los dividendos de los dueños a costa de ahorrar en empleados básicos.
#76 si no tuvieran AI, no emplearían a un ilustrador. Simplemente pillarían una imagen de archivo, o no pondrían nada.
El ilustrador aquí no es un empleado básico.
#76 ¿dividendos? ¿En esa empresa? ¿Va en serio? 😂 😂
#40 yo boicotearia a todas las que usen los xcel en lugar de ábacos.
Y eso de escribir en un editor de texto? Está mal, hay que llamar a una imprenta.
#40 a mí me parece fatal que publiquen sus artículos en internet en vez de usar escribas que copien a mano el texto y lo envíen a nuestras casas mediante palomas mensajeras.
No, no tensajero.
Hola, pequeño chip de hardware embeddido, que
te voy a instalar la máquina virtual de Java.
Ah, pues no cabe.
#68 No pasa nada, voy a probar con Javascript, que está muy de moda y dicen que es seguro.
Oh, wait...
#68 J2ME sí.
Menuda basura de artículo.
Del nivel de los que piden esa estupidez.
#37 ¿Estupidez? Tener código más seguro no es ninguna estupidez. Tener Linux programado en Rust, por ejemplo, evitaría muchos errores y problemas.
#88 El lenguaje de programación no te va a dar "código más seguro".
Creer eso es lo estúpido
Tener un Linux en Rust no aportaría nada de nada
#88 Estás guapo
#88 Ya ha habido potenciales fugas con Rust.
De los creadores de "poner un aviso de cookies aumenta la seguridad del usuario" llega "hay que prescindir de C y C++ porque son inseguros".
En serio, no hay que hacer caso a burócratas de mierda que no tienen ni puta idea de nada, y menos de informática.
Rust podría sustituír C. C++ no.
Sinceramente yo creo que C tiene más futuro que C++, a pesar de la evolución de este último. No me cabe duda de que en el largo plazo C++ será reemplazado, pero C a día de hoy es lo más cercano que tenemos al "ensamblador para humanos" y eso no va a cambiar, no estoy de acuerdo con que Rust vaya a ser un sustituto de este. Discreto totalmente con #38
Se entiende que C++ evolucione, todos los lenguajes lo hacen, pero pienso que el salto de C++ de alguien que lo haya usado 15 atrás hasta ahora es tan grande como mirar un lenguaje nuevo. Si miramos lenguajes como Python donde se han hecho grandes saltos en el pasado (ej: 2.x a 3.x, a pesar de la mediocre y larga transición) la evolución suele ser más coherente y los desarrolladores se adaptan rápidamente sin dificultad. En C±± alguien que se quedó en el estándar C++11 hoy día lo tiene jodido.
#42 C es una castaña que es la principal responsable de la pesima gestion de memoria ya que no tiene ningun tipo de control o alternativa. C++11 ya ha introducido SmartPointers (std::unique_ptr, std::shared_ptr) que unido a todo el STD con sus nuevas funcionalidades es el mejor lenguaje del mundo: tienes el bajo nivel de C y el alto nivel de cualquier lenguaje actual...
#96 C no es ninguna castaña. Que el que lo use no tenga ni puta idea de lo que hace no lo convierte en una castaña
La "gestión de memoria" de C es excelente. Se sabe exactamente cuando se usa y el instante en que se deja de usar una porción de memoria. Y se sabe Exactamente donde se está escribiendo y donde se puede escribir y donde no.
No hace falta más
Buscar que un lenguaje arregle la incompetencia de un programador es muy mala idea.
C++ aporta mucho sobre C. Es cierto.
Y Rust no es ni parecido ni puede sustituir a C++. No es un lenguaje orientado a Objetos
#96 Si C es una castaña díselo a Theo De Raadt.
It's a trap!
Qué bonita la imagen del artículo ¿quién la habrá hecho? Al pie de la foto no dice nada...
Lo que deben hacer cuando saquen el pliego de condiciones para un contrato es exigir que no quieren C ni C++ y dejar de dar el culo al mundo.
Genmierda, sucedáneo de xatakabasura y sus titulares clickbait
Sin leerme el artículo, os ahorro un clic: los lenguajes compilados de bajo nivel son un problema porque dan capacidad de control de los sistemas a la población.