Portada
mis comunidades
otras secciones
#62:
#46 Buena paja mental. ¿Qué tiene con ver con esto? ¿tu propuesta es mantener USB 2.0 como estándar de facto y no hacer nada que no funcione en esos cacharros?
A ver: Para lo que necesites C, tienes C. Usalo y ya está.
Rust no ha nacido con interés en compatibilidad con todo lo que existe ya en la actualidad, a pesar de que es muy portable (siempre que alguien se haya molestado en escribir lo que sea necesario, claro).
No te preocupes que si de repente la humanidad no puede vivir sin PowerPC 32 bits se añadirá soporte para esa arquitectura.
A ver: Para lo que necesites C, tienes C. Usalo y ya está.
Rust no ha nacido con interés en compatibilidad con todo lo que existe ya en la actualidad, a pesar de que es muy portable (siempre que alguien se haya molestado en escribir lo que sea necesario, claro).
No te preocupes que si de repente la humanidad no puede vivir sin PowerPC 32 bits se añadirá soporte para esa arquitectura.
#10:
Me vendrá bien, que tengo el RUST un poco oxidado
#47:
¿Soy el único que le ha cirriado esto?
A half-hour to learn Rust
Jan 27, 2020 · 51 minute read · rust
30min < 51min
A half-hour to learn Rust
Jan 27, 2020 · 51 minute read · rust
30min < 51min
#25:
#18 Precisamente lo contrario. Ponte a mirar C++ moderno sin ir más lejos, y dime que es más fácil de leer que Rust.
Y mi trabajo diario es picar en C++, cosa que disfruto como un enano y eso que Rust no me dice nada, la verdad. Pero si de algo puede fardar Rust es de ser un lenguaje que aprende de los fallos, de C y C++ principalmente, para hacerlo más sencillo y ameno al programador medio.
Y mi trabajo diario es picar en C++, cosa que disfruto como un enano y eso que Rust no me dice nada, la verdad. Pero si de algo puede fardar Rust es de ser un lenguaje que aprende de los fallos, de C y C++ principalmente, para hacerlo más sencillo y ameno al programador medio.
#22:
#18 rust tiene el principio de que si compila, funciona.
No vas a poder (ni queriendo), tener overflows, races, errores no controlados, opciones en un enum no chequeadas, etc
Con lo cual si estás acostumbrado a ir a lo loco como puedes hacer en C, te espera una pelea con el compilador. A cambio, cuando tengas un binario, tienes la certeza de que va a hacer lo que esperas.
No vas a poder (ni queriendo), tener overflows, races, errores no controlados, opciones en un enum no chequeadas, etc
Con lo cual si estás acostumbrado a ir a lo loco como puedes hacer en C, te espera una pelea con el compilador. A cambio, cuando tengas un binario, tienes la certeza de que va a hacer lo que esperas.
Comentarios
Me vendrá bien, que tengo el RUST un poco oxidado
#3 Espero que no abandonen la versión GNOME, la de Pop!_OS me parece una de las mejores implementaciones
#16 Pues visto el percal con Libadwaita y la peste de Gnome monopolizando todo, hasta Solus OS ha abandonado el stack Gnome y se va a basar en Enlightenment en las siguientes versiones.
https://www.debugpoint.com/2021/09/solus-exit-gtk/
#46 Buena paja mental. ¿Qué tiene con ver con esto? ¿tu propuesta es mantener USB 2.0 como estándar de facto y no hacer nada que no funcione en esos cacharros?
A ver: Para lo que necesites C, tienes C. Usalo y ya está.
Rust no ha nacido con interés en compatibilidad con todo lo que existe ya en la actualidad, a pesar de que es muy portable (siempre que alguien se haya molestado en escribir lo que sea necesario, claro).
No te preocupes que si de repente la humanidad no puede vivir sin PowerPC 32 bits se añadirá soporte para esa arquitectura.
#62 No, mi propuesta no es nada, solo que Rust parece hecho para la seguridad y a la vez barrer con cientos de máquinas para conseguir un nuevo negocio y más ventas.
Ah, Rust sigue teniendo vulnerabilidades. No es la panacea.
Si los CADT (jwz dixit) se sienten más felices, allá ellos con su homeopatía.
#63 Ya no sé si estás troleando, así que llegados a este punto no tengo nada más que decir. Buenas noches
#65 Buena suerte, ya te desengañarás.
#65 tiene pinta de que está googleando como loco para copiar argumentos con los que contestar jajajaj
#67 Si, hombre sí.
Llevo aquí desde tiempos del TCL y Perl, cuando instalar una distro podía freirte tu monitor de tubo y el configurador de X era más cancerigeno para la usabilidad que un simple menú en ncurses.
Un saludo.
He visto a muchos vendiéndome la moto en seguridad una y otra vez. No cuela.
Incluso OpenBSD ha tenido ataques cuasitriviales por un conocido (en modo anónimo) colaborador de NetBSD haciendo un kernel panic en segundos. Pues eso.
Que no me vendan milagros.
#68 yo también soy de esa época, pero no estoy anclado en el pasado con mi terminal de 80x24 tirando greps monohilo con regex que tardan la puta vida.
¿Soy el único que le ha cirriado esto?
A half-hour to learn Rust
Jan 27, 2020 · 51 minute read · rust
30min < 51min
#47
#47 Los últimos 21 minutos de lectura son chistes y chascarrillos escritos en Rust, porque ya has aprendido a leer Rust.
#8 perdona? Tanto corrección como rendimiento son esenciales en cualquier herramienta de bajo nivel, si tu argumento es que grep funciona aunque sea 10 veces más lento que ripgrep pues nada...
#9 Hijo mío, que con xargs y las SSD ya no necesitamos "tanta" velocidad.
Que mi portatil Turion 2 con 2GB de RAM, Void y sin necesidad de ripgrep vuela con un SSD.
#11 vale, pues nada, para ti la perra gorda
#11 Un turion sólo vuela si lo lanzas por la ventana
#41 Mi bicho con Void y CWM no dice lo mismo.
#44 seguro que los "ls" los hace a toda leche pero ponte a ver un video de YouTube en full hd
#48 La pantalla es de 1680x1050, como mucho a 720p.
Cojo mpv + youtube-dl, con esta config en ~/.config/mpv/config:
script-opts=ytdl_hook-ytdl_path=/home/void/.local/bin/yt-dlp
sub-auto=fuzzy
ytdl-raw-options=ignore-config=,sub-format=en,write-sub=
sws-allow-zimg=no
sws-fast=yes
vd-lavc-skiploopfilter=all
video-unscaled=no
ao=alsa
vo=gpu,drm
ytdl-format=bestvideo[height
#49 Me está costando no hacer la broma de "el año de Linux en el escritorio"
#11 desde cuándo no necesitamos más velocidad?
#52 Desde que GNU Grep y las caches de CPU y de la RAM son tan enormes que algo como ag o ripgrep se hace bastante innecesario.
He visto algunas Ryzen con más memoria L3 que mi equipo de los 2000.
#11 También está el tema de gasto energético. Algo que es más óptimo para el procesador, por definición, hará que consuma menos energía. De hecho por eso las grandes se han metido en la Rust Foundation. Aquí hay un filón para bajar su consumo energético y, por consiguiente, sus costes. https://foundation.rust-lang.org/board/
#6 lo dirás tú, no las habrás probado.
Juega un poco con ripgrep por decir una, o tokei y me dices si las versiones anteriores se acercan en rendimiento
#7 El grep de GNU no está mal en rendimiento, pero en Unix lo que importa es que sea correcto, no que sea rápido.
Ripgrep estaría bien en sistemas con un disco no SSD, pero hoy en día con cosas para xargs y con todo el mundo con SSD's no se necesita tanto rendimiento y velocidad como antaño.
#7 #8 Prueben también el Silver Searcher, mucho más rápido que grep
https://github.com/ggreer/the_silver_searcher
#8 Creo que no grepeas en muchos gigas de datos habitualmente...
#6 #7 Incluso curl lo están montando encima de Rust/Tokio/Hyper...
#56 Y por eso se están cagando en sus muertos ya que Curl se usa en millones de dispositivos empotrados.
Y si no reculan, una alternativa ligera (sobre todo del mundo BSD) se lo va a comer con patatas.
#57 Creo que el backend se puede desacoplar y utilizar otra cosa si no hay alternativa por el momento (hasta que se pueda usar GCC en el backend del compilador).
#57 rust ya se usa en millones de sistemas empotrados sin pegas
#7 Rust no deberia ser mas rapido que C, sino mas seguro y robusto. En cuestion de rendimiento deberia ser casi tan rapido como C o con diferencia inapreciable.
Edito: veo que en alguna se aprovecha a poner multihilos para aprovechar los cores y eso en Rust, se hace mas facil.
#22 Me parece que para lenguajes para aprender al principio, te obliga a hacer las cosas bien y se aprende mejor cuanto antes aparezcan los errores y es lo que hace rust.
#69 el motivo de que las aplicaciones escritas en Rust sean más rápidas que sus equivalentes en C es que en Rust el multihilo es seguro y fácil de implementar, por lo que siempre que se puede se usa. Así que en cualquier arquitectura actual siempre vas a tener mejor rendimiento.
No es lo mismo buscar procesando ficheros uno a uno que muchos en paralelo.
#3 hay miles de cosas en Rust ya...
La nueva generación de herramientas de sistema están casi todas en Rust
#5 La nueva generacion de herramientas son un quiero y no puedo, ya lo siento. Las herramientas Unix en C funcionan perfectamente y son compatibles con cientos de scripts que requieren Posix.
Ahora bien, en un SO como Redox OS serían la hostia en verso.
#78 la diferencia es que yo llevo toda la vida programando en C y un par de años haciendo cosas en Rust, pero me están respondiendo personas que simplemente no quieren cambiar nada.
Allá cada cual pero cuando en tres años los curros que pidan cinco de experiencia en Rust sean los más pagados que no se sorprendan.
me hablan de sistemas embebidos y tal que son precisamente los que más necesitan Rust porque un bug en firmware puede no poderse arreglar nunca en sistemas en producción...
#79 > Allá cada cual pero cuando en tres años los curros que pidan cinco de experiencia en Rust sean los más pagados que no se sorprendan.
Los ingenieros en Rust precisamente son los mejor pagados a día de hoy (al menos en EEUU) al no haber competencia, de momento.
> me están respondiendo personas que simplemente no quieren cambiar nada.
Eso suena un poco presuntuoso y a la vez victimista, ¿no crees? Si yo te digo que quiero usar C++20 en lugar de Rust, ¿en qué posición me encuentro? ¿Inmovilista o idealista?
> me hablan de sistemas embebidos y tal que son precisamente los que más necesitan Rust porque un bug en firmware puede no poderse arreglar nunca en sistemas en producción...
Me parece que estás dando al lenguaje de programación más importancia de la que realmente tiene, y si es cierto que llevas varios años de programador esto me chirría un poco. Un lenguaje de programación no te crea una arquitectura, que es lo que realmente ahorra tiempo y dinero de un mantenimiento de cualquier tipo de proyecto, no solo empotrado.
¿Que el lenguaje te guía/ayuda/orienta con detalles de programación de sistemas? Perfecto; pero eso ya lo tienes en bibliotecas de C y C++. Si realmente lo que quieres es trabajar bajo raíles, Rust probablemente sea tu sitio. Si necesitas más control sobre acceso a memoria, probablemente las ventajas de Rust no lo sean tanto en este caso.
A mí particularmente el coste de aprender Rust teniendo C++23 a la vuelta de la esquina no me merece la pena. Pero no me merece la pena porque llevo 10 años aprendiendo C++, ya que ha ido evolucionando con el tiempo; y tiene pinta de que seguirá evolucionando. Si vienes de C la cosa cambia, ese lenguaje del demonio siempre fue y será horrible.
Hay muchos problemas con la gente de C y C++. El principal es que los de la vieja escuela prefieren escribir todo "a mano", para tener el control de lo que se ejecuta (el típico antipatrón Not Invented Here, vamos). Y cuanto más código escribes, más bugs introduces. Rust te ahorra unos cuantos tipos en tiempo de compilación, lo cual es muy de agradecer pero también dice bastante de la calidad del programador que se aprovecha de dichos fallos, dicho sea de paso. Además, al contrario que C, Rust es muy expresivo (y en ese aspecto, se parece bastante a C++).
A lo que voy es: como exprogramador en C, es fácil caer en la tentación de Rust y creer en la segunda venida. Pero como consejo, deja vivir a los que vemos Rust con escepticismo por culpa de ese tipo de capa de mesiandad que lo rodea
#80 ¿has probado Rust o no? Porque si no, ya me aburro. No te lo tomes a mal, pero en cuanto me dicen que en C se hace lo mismo, que si hay librerías, que sí tal y cual... pues me estás diciendo que no entiendes lo que aporta Rust.
Y un programador en C que cree que él no introduce fallos porque tiene mucha experiencia no tiene suficiente experiencia por definición
#81 ¿Qué más da si lo he probado o no? ¿No irás al ad-hominem + falacia de autoridad? Me he tomado el tiempo de responderte con la mayor educación posible argumentando mi -probablemente equivocado- punto de vista, así que te rogaría que no reduzcas tu respuesta a un mero "tú qué sabrás que ni lo has probado".
> pues me estás diciendo que no entiendes lo que aporta Rust.
Desde el punto de C++ no, desde el punto de vista de C sí. A ver si te enteras tú también con quién estás hablando
> Y un programador en C que cree que él no introduce fallos porque tiene mucha experiencia no tiene suficiente experiencia por definición
Desde que cambiaste a Rust, ¿todo tu código está libre de fallos?
#92 desde que cambié a Rust han desaparecido muchos tipos de bugs, claro. Porque son imposibles en Rust.
Pero es que discutir sobre lenguajes con quien no ha probado el objeto de la discusión no lleva a nada. Si quieres dale una oportunidad muy bien y si no también.
#93 No es eso lo que te pregunté, pero vale. Queda claro que como tanta gente en este portal haces cherry-picking del bueno.
> Pero es que discutir sobre lenguajes con quien no ha probado el objeto de la discusión no lleva a nada
¿Por qué? Nunca he programado en php y sé que es una auténtica mierda, basado en los artículos que he leído aquí y allá.
Pero me parece bien también, vista tu actitud no deseo que bajes desde tu torre de marfil a discutir con meros ignorantes como yo. Buena suerte y enhorabuena por elegir el mejor de los lenguajes disponibles
Media hora LOS COJONES.
#71 efectivamente pone 51 minutos en el articulo
#85 Y que leas el artículo en 51 minutos no quiere decir que lo entiendas.
#86 jajajjaja eso es otra batalla
#71 Hombre, si no miras el código ni media hora.
El título completo debería ser: A half-hour to learn Rust (in just two months!)
Tengo rust bastante oxidado.
#26 Voy a tener que llamar a la policía del humor 😁
En un princípio, al leer el título, había entendido "Aprende a leer a Proust".
yo aprendí a programar en dlang. Lo de RUST se lo dejo para los que dicen que Python está de moda. Mejor usa Go o Ruby. No hay año que no exista un hipsterlangprogramingporquenoquieroparecertonto
#14 me haces un driver de algo en ruby?
#21 Y un driver para PowerPC 32 bit en Rust?
#33 ¿existe algo para PowerPC 32 bits que no tenga driver ya?
Pero si quieres saber lo que está soportado:
https://doc.rust-lang.org/nightly/rustc/platform-support.html
#39 Una pista: cacharricos USB 2.0.
Hay ingentes de ellos, y la gente suele usar PowerMacs porque en un futuro de escasez el tener una maquina viable se hace imprescindible.
#40 Si rust no los soporta (es un lenguaje moderno con poco interés en las antiguallas), pues usa otra cosa.
#45 Antigualla es relativo cuando llegue el semi-colapso de materias primas y algunos equipos Intel empiecen a fallar al meterseles demasiada caña. Toda maquina que sea antigua con Linux y NetBSD será salvable, aunque sea con webs basicas sin JS, Gopher, musica y podcasts en MP2/Opus para no saturar el ancho de banda y/o la CPU y protocolos como Gopher o Gemini en ultima instancia.
Sí, hay raspberry pi's, pero las SD's fiables se cuentan con los dedos de una mano.
#21 qué drivers están hechos en Rust? Porque de momento el soporte de Rust en Linux está en una fase muuuuuuuuy inicial.
#38 ¿y? Rust está llegando al kernel. Ya lo sabemos.
Es posible escribir drivers en Rust, y esos drivers tendrán unas garantías de corrección más allá de que el programador sea un crack.
#42 Es que como ejemplo de algo que no se puede hacer en Ruby y si en Rust, pues es muy flojo.
Cada lenguaje tiene su target, su momento y sus compromisos.
Rust tiene buena pinta, veremos a ver si realmente llega a sustituir lenguajes core como Java .net o Go, o se queda en algunos nichos en los que quedaba C/C++.
#50 Rust es lo que es: Un lenguaje moderno de sistemas.
No es Java, no es .NET (que son bytecompilados), no es Python, etc.
#60 No te ofendas, pero leyendo este hilo me da que eres uno de estos evangelistas de Rust. Hay gente escéptica, asúmelo. No vas a convencerlos igual que no te van a convencer
#60 Que también sirve para desarrollar aplicaciones web, no lo olvidemos. Yo creo que
va a abarcarabarca muchísimo más que C/C++.De hecho, incluso Google ya le ha puesto ojitos y lo integra en Android:
https://security.googleblog.com/2021/04/rust-in-android-platform.html?m=1
#42 no hay que usar de unsafe en muchas partes para hacer drivers en rust?
es mejor que 100% unsafe esta claro, pero a nivel drivers me parece que la ventaja de seguridad de rust se acorta.
#91 en partes específicas
#14 Si es la popularidad lo que te preocupa, python lleva ya muchos años muy por encima de Ruby y que yo sepa siempre ha estado por encima de Go. Rust lo lleva petando en las encuestas de StackOverflow desde hace por lo menos 5 o 6 años. Yo que tú haría un upgrade de prejuicios.
#14 Pues pocos lenguajes más hipsters que Ruby y Go, ya me estoy imaginando hasta las pegatinitas
Con toda mi admiración y respeto por esos lenguajes y las cosas que han conseguido.
Python no tiene rival en ML por el momento y como lenguaje de introducción, muy capaz y potente para web y otras tareas de automatización.
Rust yo lo veo como un sucesor a C++ que introduce varias cosas bastante interesantes, pero con una curva de aprendizaje importante a diferencia de Go (que queda descartado para este puesto por su GC). Si aprendiste y apostaste por D en su momento, entiendo esos sentimientos...
Uno de los mejores blogs de Rust.
#1 #2 No soy fan de Rust pero hay un proyecto de crear un escritorio basado en Rust llamado Cosmic.
https://news.itsfoss.com/pop-os-cosmic-rust/
#3 Si los desarrolladores de Pop!_OS/System76 están detrás de ese proyecto, auguro que va a ir bastante bien.
#55 Para casos muy concretos y precisamente por estar dentro de un unsafe (que debería ser mínimo) sabes donde mirar si algo no hace lo que debe
#74 Efectivamente. A ver, tampoco es plan de culpar a nadie... pero evidentemente la frustración que los de C/C++ hemos pasado, Rust la va a evitar y eso es una gran ventaja.
Pero es cierto lo que dices, el programador inepto es menos inepto gracias a Rust. Y eso que en C/C++ tienes static analysis tools y sanitizers, pero ya tienes que estar toqueteando el build system y eso no mola. Pero bueno, la limpieza de C++ (de C++11 en adelante) es impecable cuando tienes mimbres. Si no vales, lamentablemente tienes que irte a Rust.
#0 esas mayúsculas te van a perjudicar
#2 ¿si? ¿cómo funciona eso?
#29 Ninguna de esas cosas te va a ayudar con un race entre hilos, por ejemplo.
#34 Cierto, pero es de esperar que añadan opciones para GCC y Clang y/o pthreads.
#37 Mírate el gcc sanitizer. Y sino, directo a valgrind
#75 Eso no resuelve los problemas de hilos y condiciones de carrera.
Muchas de esas opciones y más están en OpenBSD. Simplemente compila algo y mira la lista de símbolos y a donde vuelve la función main. Pista, no es donde crees.
#34 Ahí te tienes que dar de tortas con GDB o el depurador que uses, y tener suerte de que sea algo tonto (un mutex que se olvidó usar, por ejemplo)
Esta reacción es típica en los que llevan años con C y especialmente C++. Síndrome de Estocolmo se llama.
Es entendible, tras pasarte decenas de años aprendiendo todos los recovecos y campos de minas que tienen, y que se te valore laboralmente por ello, es jodido que venga algo que te puede quitar del trono.
Pero que nadie se preocupe, el código que ya está escrito es improbable que desaparezca. No se va a quedar nadie sin trabajo de mantenimiento.
Eso sí, para todo lo nuevo, ninguna empresa va a querer escribir nada en C / C++ a la larga. Más que nada porque Rust ahorra muchos quebraderos de cabeza en mantenimiento.
Veo que la gente aquí no tiene ni puta idea de lo que habla sobre Rust, como suele ser. La mayor ventaja de Rust no es la seguridad. Esto es porque no se publicita así. Los usuarios del lenguaje lo que destacan son otras cosas:
- Gestor de librerías incorporado, que funciona rápido y bien y ahorra todos los infiernos absurdos que implica utilizar librerías en C/C++, además de ahorrar la mierda de los sistemas de build.
- Trasladar la inmensa mayoría de errores durante la ejecución a errores durante la compilación. Si alguien no ve en esto algo extremadamente ventajoso, que se dedique al sado.
¿Ese puntero que intentas acceder habiéndolo liberado por descuido? Rust no te habría dejado.
¿Ese null que se te descuidó? Rust no te habría dejado.
¿Ese cuelgue que pasa rara vez cuando ejecutas un programa durante 72h horas y es imposible de localizar después de días de agonía de depuración y que ni los gurús del equipo fueron capaces de encontrar en años? Rust te lo habría pillado al compilar a la primera, te habría dicho dónde y qué tendrías que hacer probablemente para corregirlo.
Rust tiene mucha más información que C o C++ sobre el código que está compilando, con lo que puede hacer demostraciones y razonamientos mucho más complejos y puede evitar muchos más problemas, además de hacer más y mejores optimizaciones. En Cy C++ en muchos casos es básicamente imposible, y cambiarlo requeriría destrozar el lenguaje.
- Estar en el siglo XXI de una puta vez en cuanto a utilización de nucleos y hacer mucho más sencillo y sin errores su uso, cosa que en C / C++ es como poco dudoso. Estamos hablando de que Rust no compila si hay race conditions, cosa que hasta los muy expertos hacen mal porque es extremadamente difícil.
Como muestra de este punto: los autores de Chrome tuvieron que desistir de hacer un motor CSS paralelo (que aprovechase los nucleos) en C++ después de tres intentos infructuosos a lo largo de varios años (el programa se colgaba siempre).
Firefox lo logró a la primera usando Rust.
Y estamos hablando de gente de primer nivel en todos los casos.
- Las restricciones de Rust implican programar de otra manera con la memoria (favorece la programación orientada a datos, simplificando mucho), que implica dos cosas:
La primera, que se aprovecha mucho mejor la localidad de la memoria, y se aprovecha mucho mejor el cache de la CPU, con lo cual los programas tienden a aprovechar mucho mejor la velocidad del hardware.
La segunda, que se puede razonar con el código de forma local. Es mucho más fácil aislar una parte del código para entender lo que hace sin tener a la fuerza en la cabeza la complejidad del sistema completo.
Todo esto es porque el lenguaje te fuerza a ello. En C++ nadie te obliga. Sin embargo serían las mejores prácticas a seguir también en C++ y si no las sigues, vas a tener problemas.
- Mensajes de error que realmente ayudan a entender los problemas. Salvo muy pocos casos, la inmensa mayoría de mensajes de error al compilar, indican la localización exacta (a nivel caracter), el motivo del error y da incluso sugerencias para arreglarlo. Clippy (el linter) además tiene un montón de avisos extra.
- Es mucho menos probable cometer errores de lógica por la sencilla razón de que es mucho más sencillo pensar cuando tienes menos cosas en las que pensar. La inmensa mayoría coincide en que esto es lo menos esperado de rust y lo que más se agradece.
Normalmente si compila, es que va a funcionar bien.
La mayoría de grandes compañías no son tontas y ya están adoptando equipos de Rust mientras aquí estáis discutiendo obviedades. Todo lo que se escriba nuevo y de bajo nivel muy probablmente será con Rust a partir de cierto momento. Las grandes ya están escribiendo lo más crítico en Rust. Microsoft ya lo ha incorporado a muchos de sus desarrollos. Torvalds ya ha dicho que al contrario que con C++ no ve con malos ojos utilizar Rust en el kernel de Linux, de momento de forma limitada y en el futuro ya se verá.
Además, la gente que realmente controla, no se chupa el dedo y ya está desarrollando backends para por ejemplo para gcc, para poder tener la misma compatibilidad.
C y C++ son un engaño. Te hacen creer que controlas (incluso tras muchos años de experiencia) y te pegas la hostia después de compilar.
Rust te obliga de antemano a saber lo que estás haciendo. Por eso parece mucho más difícil al principio. Sin embargo, todo lo que te obliga Rust son cosas que deberías estar controlando desde el principio. C y C++ te dejan hacer burradas sin que seas consciente de ello y lo peor, creyendo que no las haces.
Y por eso empresas gordas como MS, decían (en 2019, mientras se pensaban si adoptar oficialmente Rust) cosas como las siguientes:
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
"As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more. "
"While many experienced programmers can write correct systems-level code, it’s clear that no matter the amount of mitigations put in place, it is near impossible to write memory-safe code using traditional systems-level programming languages at scale."
#96 >- Gestor de librerías incorporado, que funciona rápido y bien y ahorra todos los infiernos absurdos que implica utilizar librerías en C/C++, además de ahorrar la mierda de los sistemas de build.
Eso en Windows.
>¿Ese puntero que intentas acceder habiéndolo liberado por descuido? Rust no te habría dejado.
¿Ese null que se te descuidó? Rust no te habría dejado.
¿Ese cuelgue que pasa rara vez cuando ejecutas un programa durante 72h horas y es imposible de localizar después de días de agonía de depuración y que ni los gurús del equipo fueron capaces de encontrar en años? Rust te lo habría pillado al compilar a la primera, te habría dicho dónde y qué tendrías que hacer probablemente para corregirlo.
Eso lo puede implementar GCC y Clang sin problema.
>- Mensajes de error que realmente ayudan a entender los problemas. Salvo muy pocos casos, la inmensa mayoría de mensajes de error al compilar, indican la localización exacta (a nivel caracter), el motivo del error y da incluso sugerencias para arreglarlo. Clippy (el linter) además tiene un montón de avisos extra.
Clang tambien y eso hizo mejorar bastante a GCC.
Tu mucho rajar contra C y GCC pero te has quedado en 2003.
Pocas veces me he sentido más frustrado delante del ordenador que programando en rust.
#15 SuperAMÉN hermano...
Hace unos meses salió otro artículo por aquí de RUST, y la inquietud que has comentado, también la expliqué yo con alguna palabra más. Concuerdo 100% contigo:
Rust también llega al Kernel de Linux [ENG]/c26#c-26
Ahora si tuviera que actualizar o mejorar mi programa, me parece(ría) chino completo lo que yo mismo escribí. Un lenguaje "bien parido" no debe ser así.
Por otro lado, cojo cosas de Swift (de nuevo, es un ejemplo), que las escribí hace AÑOS, y las entiendo SIN DES PEI NAR ME.
Un buen lenguaje tiene que tener todo: potencia sí, pero también no descuidar la mantenibilidad/traspasabilidad del código (a ti o a otra persona), y no permitir que solo los mega wizards gurús ninjas jedis del mismo puedan ser los únicos que queden para mantener en el futuro.
no conozco nada de rust, pero viendo el artículo parece un lenguaje hecho complicado a proposito para que los programadores puedan decir: ¡eh, mira todo lo que sé!
No sé, me ha dado la impresión que hace difícil lo sencillo.
#18 Complicadillo, pero porque lleva a tiempo de compilación cosas que en otros lenguajes resuelves en la ejecución. En Rust tienes que ser consciente de donde se guarda en memoria cada variable.
#18 Pues yo que suelo programar en C lo veo demasiado sencillo y no me fío
. Dependerá de cuál uses.
#20 No, si el caso es que lo veo como una forma retorcida de escribir C. Como si alguien hubiera decidido escribir programas en C con una sintaxis traida de otro lenguaje (JavaScript, te miro a ti) y se hubiera inventado este lenguaje Rust.
Tal vez sea cosa mía....
#18 rust tiene el principio de que si compila, funciona.
No vas a poder (ni queriendo), tener overflows, races, errores no controlados, opciones en un enum no chequeadas, etc
Con lo cual si estás acostumbrado a ir a lo loco como puedes hacer en C, te espera una pelea con el compilador. A cambio, cuando tengas un binario, tienes la certeza de que va a hacer lo que esperas.
#22 Me parece que tos los lenguajes deberían migrar a este paradigma haskell, scala, rust...
#22 Gcc tiene -Wall -Wextra y -Pedantic.
#29 Yo eliminaría -pedantic de los argumentos de gcc y añadiría el uso de cppcheck y Valgrind
#22 Podría ser así, pero no creo que Rust ayude con los 2 cosas más difíciles en programación:
1. Invalidación de caché.
2. Nombrar cosas.
3. Errores por un paso.
#32 y carrera condiciones las de
#32 Con 2 me temo que no.
Pero con 3 seguro que sí (más que nada porque una de las consecuencias típicas es un acceso ilegal más allá del final del array).
Con 1 no sé, depende de qué caché hables.
#22 Bueno bueno, tienes unsafe que en ocasiones muy contadas necesitas. Tampoco es el mesías que estamos todos esperando.
#18 Precisamente lo contrario. Ponte a mirar C++ moderno sin ir más lejos, y dime que es más fácil de leer que Rust.
Y mi trabajo diario es picar en C++, cosa que disfruto como un enano y eso que Rust no me dice nada, la verdad. Pero si de algo puede fardar Rust es de ser un lenguaje que aprende de los fallos, de C y C++ principalmente, para hacerlo más sencillo y ameno al programador medio.
#25 Rust viene a decir, si eres un inepto en C/C++ ven con nosotros que no dejaremos que se note tanto lo inepto que eres..
#18 Más que un lenguaje para "presumir" me parece un lenguaje orientado a la robustez. En general no hay más de una o dos formas de hacer lo mismo y el compilador es completamente inflexible ante lo que él categoriza como mal código. Es difícil de usar, pero también es difícil de meter la pata.
No tengo más que hacer.
Split y xargs es mas eficiente.
Lo importante es hacer la petro cuanto antes.
Ricoy es el mejor en Rust
Yo la verdad es que me gusta más el Ark
Hasta luego.
estoy hasta los huevos del "en minutos", "en media hora", "en 6 horas", ......
menudos agentes de ventas cabrones y menudos idiotas los que se creen todo eso.
Muy harto del "es muy facil"