edición general
140 meneos
5051 clics

Aprende a leer Rust en media hora

Para aumentar la fluidez en un lenguaje de programación, es necesario leer mucho. Pero, ¿cómo puedes leer mucho si no sabes lo que significa? En este artículo, en lugar de centrarme en uno o dos conceptos, intentaré analizar todos los fragmentos de Rust que pueda y explicar qué significan las palabras clave y los símbolos que contienen. [ENG]

| etiquetas: rust
81 59 3 K 374 tecnología
105 comentarios
81 59 3 K 374 tecnología
Comentarios destacados:              
«12
  1. ccguy #1 ccguy
    Uno de los mejores blogs de Rust.
    1 K 23
  2. ccguy #2 ccguy
    #0 esas mayúsculas te van a perjudicar
    0 K 20
  3. #3 --625430-- *
    #1 #2 No soy fan de Rust pero hay un proyecto de crear un escritorio basado en Rust llamado Cosmic.

    news.itsfoss.com/pop-os-cosmic-rust/
    2 K 19
  4. #4 x.y.z
    No tengo más que hacer.
    0 K 14
  5. ccguy #5 ccguy
    #3 hay miles de cosas en Rust ya...

    La nueva generación de herramientas de sistema están casi todas en Rust
    2 K 32
  6. #6 --625430-- *
    #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.
    4 K 32
  7. ccguy #7 ccguy
    #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
    2 K 33
  8. #8 --625430-- *
    #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.
    0 K 10
  9. ccguy #9 ccguy
    #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...
    3 K 44
  10. pkreuzt #10 pkreuzt
    Me vendrá bien, que tengo el RUST un poco oxidado :troll:
    12 K 118
  11. #11 --625430--
    #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.
    0 K 10
  12. #12 kaotan
    #2 ¿si? ¿cómo funciona eso?
    0 K 7
  13. ccguy #13 ccguy
    #11 vale, pues nada, para ti la perra gorda
    0 K 20
  14. dark_soul #14 dark_soul
    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
    3 K 28
  15. #15 Malandrico
    Pocas veces me he sentido más frustrado delante del ordenador que programando en rust.
    2 K 17
  16. #16 J.J.
    #3 Espero que no abandonen la versión GNOME, la de Pop!_OS me parece una de las mejores implementaciones
    5 K 68
  17. #17 --625430-- *
    #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.

    www.debugpoint.com/2021/09/solus-exit-gtk/
    0 K 10
  18. mecha #18 mecha
    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.
    2 K 16
  19. #19 kaotan
    #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.
    0 K 7
  20. halcondeoro #20 halcondeoro
    #18 Pues yo que suelo programar en C lo veo demasiado sencillo y no me fío xD. Dependerá de cuál uses.
    3 K 35
  21. ccguy #21 ccguy
    #14 me haces un driver de algo en ruby?
    1 K 26
  22. ccguy #22 ccguy
    #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.
    4 K 50
  23. mecha #23 mecha
    #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....
    5 K 33
  24. ankra #24 ankra
    #22 Me parece que tos los lenguajes deberían migrar a este paradigma haskell, scala, rust...
    1 K 3
  25. #25 --68408-- *
    #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.
    6 K 52
  26. ur_quan_master #26 ur_quan_master
    Tengo rust bastante oxidado.
    2 K 30
  27. #27 Gusynho
    Lo importante es hacer la petro cuanto antes.
    0 K 6
  28. #28 --625617--
    Ricoy es el mejor en Rust
    0 K 6
  29. #29 --625430--
    #22 Gcc tiene -Wall -Wextra y -Pedantic.
    0 K 10
  30. #30 FooDev
    #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.
    2 K 25
  31. Tolodomonte #31 Tolodomonte
    Yo la verdad es que me gusta más el Ark

    xD

    Hasta luego.
    0 K 6
  32. #32 ElQueSeHaceElSueco
    #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.
    3 K 34
  33. #33 --625430--
    #21 Y un driver para PowerPC 32 bit en Rust?
    1 K 13
  34. ccguy #34 ccguy
    #29 Ninguna de esas cosas te va a ayudar con un race entre hilos, por ejemplo.
    0 K 20
  35. #35 juanac
    #32 y carrera condiciones las de
    1 K 18
  36. ccguy #36 ccguy
    #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.
    0 K 20
  37. #37 --625430--
    #34 Cierto, pero es de esperar que añadan opciones para GCC y Clang y/o pthreads.
    0 K 10
  38. alephespoco #38 alephespoco
    #21 qué drivers están hechos en Rust? Porque de momento el soporte de Rust en Linux está en una fase muuuuuuuuy inicial.
    0 K 10
  39. ccguy #39 ccguy
    #33 ¿existe algo para PowerPC 32 bits que no tenga driver ya?

    Pero si quieres saber lo que está soportado:

    doc.rust-lang.org/nightly/rustc/platform-support.html
    1 K 26
  40. #40 --625430-- *
    #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.
    0 K 10
  41. #41 --669669--
    #11 Un turion sólo vuela si lo lanzas por la ventana
    4 K 30
  42. ccguy #42 ccguy
    #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.
    0 K 20
  43. #43 baronluigi
    En un princípio, al leer el título, había entendido "Aprende a leer a Proust".
    2 K 29
  44. #44 --625430--
    #41 Mi bicho con Void y CWM no dice lo mismo.
    0 K 10
  45. ccguy #45 ccguy
    #40 Si rust no los soporta (es un lenguaje moderno con poco interés en las antiguallas), pues usa otra cosa.
    0 K 20
  46. #46 --625430-- *
    #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.
    1 K 18
  47. Perefct #47 Perefct
    ¿Soy el único que le ha cirriado esto?

    A half-hour to learn Rust
    Jan 27, 2020 · 51 minute read · rust

    30min < 51min
    7 K 65
  48. #48 --669669--
    #44 seguro que los "ls" los hace a toda leche pero ponte a ver un video de YouTube en full hd
    0 K 6
  49. #49 --625430-- *
    #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<=?720][fps<=?30]+bestaudio/best

    Lo uso con "mpv $YOUTUBE_URL"

    Para qué más?
    2 K 26
  50. alephespoco #50 alephespoco
    #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++.
    0 K 10
  51. #51 Maldito
    #7 #8 Prueben también el Silver Searcher, mucho más rápido que grep
    github.com/ggreer/the_silver_searcher
    0 K 10
  52. #52 eljuligallego
    #11 desde cuándo no necesitamos más velocidad?
    3 K 32
  53. #53 --625430--
    #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.
    2 K 16
  55. #55 --68408--
    #22 Bueno bueno, tienes unsafe que en ocasiones muy contadas necesitas. Tampoco es el mesías que estamos todos esperando.
    0 K 6
  56. #56 --624466--
    #6 #7 Incluso curl lo están montando encima de Rust/Tokio/Hyper...
    0 K 10
  57. #57 --625430-- *
    #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.
    1 K 13
  58. friguron_ #58 friguron_ *
    #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:

    www.meneame.net/c/32698949

    EDIT: Ah y confirmo que (después de escribir esos comentarios del otro artículo) perdí mucha inercia con RUST. La propia frustración por la dificultad del lenguaje ayudó a ello, obviamente, y puedo garantizar que hoy sólo me acuerdo del 5% de lo que aprendí en aquel mes o dos meses en el que le di con un poco de ilusión (y que creé un programa mono y todo...)

    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.
    1 K 20
  59. ccguy #59 ccguy
    #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 :-)
    0 K 20
  60. ccguy #60 ccguy
    #50 Rust es lo que es: Un lenguaje moderno de sistemas.

    No es Java, no es .NET (que son bytecompilados), no es Python, etc.
    1 K 23
  61. #61 --624466-- *
    #14 Pues pocos lenguajes más hipsters que Ruby y Go, ya me estoy imaginando hasta las pegatinitas xD

    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...
    0 K 10
  62. ccguy #62 ccguy
    #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.
    5 K 66
  63. #63 --625430-- *
    #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.
    0 K 10
  64. #64 --624466--
    #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).
    0 K 10
  65. ccguy #65 ccguy
    #63 Ya no sé si estás troleando, así que llegados a este punto no tengo nada más que decir. Buenas noches :-)
    2 K 41
  66. #66 --625430--
    #65 Buena suerte, ya te desengañarás.
    0 K 10
  67. selina_kyle #67 selina_kyle
    #65 tiene pinta de que está googleando como loco para copiar argumentos con los que contestar jajajaj
    2 K 24
  68. #68 --625430-- *
    #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.
    1 K 17
  69. #69 lectorcritico *
    #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.
    1 K 15
  70. ccguy #70 ccguy
    #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.
    1 K 32
  71. sieteymedio #71 sieteymedio
    Media hora LOS COJONES.
    2 K 30
  72. #72 --673921--
    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"
    0 K 6
  73. dmeijide #73 dmeijide
    #47 Los últimos 21 minutos de lectura son chistes y chascarrillos escritos en Rust, porque ya has aprendido a leer Rust.
    0 K 10
  74. j0seant #74 j0seant
    #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.. xD
    0 K 7
  75. CortoCircuito #75 CortoCircuito
    #37 Mírate el gcc sanitizer. Y sino, directo a valgrind
    0 K 9
  76. #76 --625430--
    #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.
    0 K 10
  77. #77 --68408--
    #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.
    2 K 20
  78. #78 --68408-- *
    #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 :hug:
    0 K 6
  79. ccguy #79 ccguy
    #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...
    1 K 30
  80. #80 --68408-- *
    #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 :-P
    0 K 6
  81. ccguy #81 ccguy
    #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 :-)
    1 K 30
  82. #82 FooDev
    #60 Que también sirve para desarrollar aplicaciones web, no lo olvidemos. Yo creo que va a abarcar abarca muchísimo más que C/C++.

    De hecho, incluso Google ya le ha puesto ojitos y lo integra en Android:
    security.googleblog.com/2021/04/rust-in-android-platform.html?m=1
    0 K 6
  83. #83 runciters_animals
    #57 rust ya se usa en millones de sistemas empotrados sin pegas
    0 K 9
  84. #84 elgranmago
    #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. foundation.rust-lang.org/board/
    0 K 7
  85. ed25519 #85 ed25519
    #71 efectivamente pone 51 minutos en el articulo
    0 K 7
  86. sieteymedio #86 sieteymedio
    #85 Y que leas el artículo en 51 minutos no quiere decir que lo entiendas.
    1 K 20
  87. #87 ninefingers *
    #8 Creo que no grepeas en muchos gigas de datos habitualmente...
    0 K 7
  88. SneakyDisk #88 SneakyDisk
    #49 Me está costando no hacer la broma de "el año de Linux en el escritorio" :troll:
    0 K 6
  89. #89 ninefingers *
    #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.
    1 K 19
  90. ed25519 #90 ed25519
    #86 jajajjaja eso es otra batalla
    0 K 7
  91. #91 osmotic
    #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.
    0 K 6
  92. #92 --68408-- *
    #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?
    0 K 6
  93. ccguy #93 ccguy
    #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.
    0 K 20
  94. ccguy #94 ccguy
    #91 en partes específicas
    0 K 20
  95. #95 --625430--
    Split y xargs es mas eficiente.
    0 K 10
  96. #96 pollo *
    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…   » ver todo el comentario
    1 K 18
  97. #97 JimmyTM *
    #71 Hombre, si no miras el código ni media hora. :troll:

    El título completo debería ser: A half-hour to learn Rust (in just two months!)
    0 K 13
  98. #98 --68408--
    #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 ;)
    0 K 6
  99. SaulBadman #99 SaulBadman
    #3 Si los desarrolladores de Pop!_OS/System76 están detrás de ese proyecto, auguro que va a ir bastante bien.
    0 K 6
  100. #100 --625430-- *
    #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.
    0 K 10
«12
comentarios cerrados

menéame