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
#1 #12 Os cuento un chiste muy malloc()?
...
#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.
#17 ¿Cuántos años llevas esperando la oportunidad de soltar eso?
#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.
#17 me tenéis los frikis de chistes malos hasta el conio.h
#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.
#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.
#63 Pues a saber lo que queda de tu himem.sys
#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
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.
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.
#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.
#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
#18 ¿Qué te hace pensar que es la primera vez que lo suelta?
#1 rust no necesita más RAM
#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.
#13 Te has olvidado de mencionar las mejoras de C++ desde C++11, C++14, C++17, C++20, etc...
#2 Es que el USB una vez bendecido, bendecido queda.
Ya no se puede secularizar.
Luego algunos pierden maletas con datos en USB sin secularizar.
#19 reportado
¿No se vende suficiente RAM y tienen que animar las ventas?
#3 Es que la iglesia todavía tiene mucho poder.
#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.
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.gov#17 unhandled bad joke exception
#2 un palabro muy raro ese de secularizar.
#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.
Si recomiendan Javascript han demostrado que a lo que digan no hay que hacerle mucho caso
#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.
#17 Tu gracia se ha fugado.
#5 #10 #13 #15 JS for the win!
#10 ¿tu clase de estadística? eres un imberbe que está todavía en las aulas ¿y vienes a dar lecciones de programar?
#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.
#17 Segmentation fault
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.
#2 ¿Eran datos religiosos?
#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.
#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.
"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.
#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.
#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.
#87 Podría ser su tercera carrera y tal...
Está relacionado con los fallos de memoria del inquilino de la Casa Blanca.
#17 What the fork()!
#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.
igual alguien se toma en serio la sugerencia.
#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.
#81 bien traído, vive (ms)DOS
#2 Siendo Estados Unidos me creo que alli no permitan USB secularizados, ser pagano no esta muy bien visto por alli
¿Y para qué programar en C/C++ habiendo PHP?
#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.
#18 Un buen ingeniero es experto en el uso del , lo habrá usado mil veces ya
#163 Yo hoy en dia no haria un programa puro en C... no tiene OO, no tiene smart pointers, tienes que reinventar la rueda cada dos por tres cuando no es siempre necesario (por ejemplo listas, mapas, colas, etc) y encima tienes que tener todo el rato el control de no pasarte en escribir en un array, pero que si te pasas por cualquier cosa (en un while pones un "
¿Le pedirías a un samurái que deje de usar su katana? ¿O a un jedi su sable de luz?
#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.
#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
#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/
#13 Luego, te pones a implementar una lista doblemente enlazada en Rust y el compilador te dice
"Para qué quieres hace eso jaja saludos"
#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.
#24 Una vez hice un programa en Java y compilé. Aun estoy esperando a que la VM se encienda.
#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...
#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
#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.
#54 Tu comentario me ha recordado a este video
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.
#19 JS... Te refieres a Jung/Spinoza? No me suena a ninguna otra cosa
#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.
#52 Han visto que por ahí es más fácil meter back doors
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...
#_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.
#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.
#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.
#86 Es lo que se conoce por codigo reutilizable? o programacion por objetos?
#2 segurizar, mejor que securizar
#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.
#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.
#54 Que no se olvide:
#141 En ningún momento he dicho que Rust (u otro lenguaje memory-safe) sea la solución a los accidentes de programación, si no que mitiga y previene muchos de ellos. Igual que los elementos de seguridad activa y pasiva de un coche no son la solución a los accidentes de tráfico.
Sólo apuntaba que ese razonamiento lleva a la conclusión de que no merece la pena invertir en herramientas más seguras, porque el problema son los malos conductores/programadores (que casualmente siempre son otros y no uno mismo).
#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
#92: ¿La has preguntado si la gusta la música .pop() ?
#171 un curso de guitarra. De nada
#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.
Menuda basura de artículo.
Del nivel de los que piden esa estupidez.
#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.
#121 ¿Que mejor linter que un lenguaje que previene errores por diseño?
#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
#227 efectivamente, no sabes ni lo que dices
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.
#1 De hecho muvhat veces consume menos RAM, al hacerlo mejor.
#99 Si es un Talibán es mi talibán de cabecera
#128 Sabía qué vídeo iba a ser.
#c-137" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3913684/order/137">#137 Pues si no eres capaz de hacerlo, no lo hagas.
Yo si he programado extensamente en C y no es tan difícil. Solo hay que saber lo que se hace y ser un poco cuidadoso.
Y si no eres cuidadoso o no sabes exactamente lo que haces la cagarás también en C#, Java, PHP, Python o JavaScript.
Las páginas web no están hechas en C y sus historiales de vulnerabilidades es insuperable.
Piensan prohibir la programación web ?
#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.
#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.
#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.
#54 Espero que al menos lo cobres bien...
#187 Pero el chip ya tiene que estar diseñado para ello, si no me equivoco.