Discusión:Rust (lenguaje de programación)

Cómo abordar los comentarios de relaciones públicas

Aquí están los comentarios de relaciones públicas que no se abordaron. No dudes en recogerlos o marcarlos si ya no son aplicables o si ya se han solucionado. 0x Deadbeef →∞ ( háblame ) 11:59, 7 de julio de 2023 (UTC) [ responder ]

• Historia
  • Hay un lapso de 5 años entre el lanzamiento de Rust 1.0 y los despidos de Mozilla. ¿Hay algo que puedas decir sobre ese momento? Creo que fue un período importante para el crecimiento de Rust y su adopción como lenguaje de programación serio.

     Parcialmente terminado He arreglado un poco la brecha, pero aún necesitamos hacer algo de trabajo aquí. 0x Deadbeef →∞ ( háblame ) 12:52, 16 de agosto de 2023 (UTC) [ responder ]

• Sintaxis y semántica
  • Debe tener al menos una oración que defina cada una de las declaraciones if, whiley for; si bien su significado es evidente para cualquiera que tenga experiencia en programación imperativa, no podemos asumir que el lector la tenga.
  • Coloque un comentario antes de la última cláusula de la matchdeclaración explicando que el guión bajo coincide con cualquier valor.

     Hecho 0x Deadbeef →∞ ( háblame ) 00:34, 18 de agosto de 2023 (UTC) [ responder ]

  • "El diseño de Rust estuvo influenciado de manera más significativa por los lenguajes de programación funcional". La referencia no respalda por completo esta afirmación. Solo dice "una influencia significativa es la programación funcional", pero no dice que la influencia funcional fuera más significativa que la influencia de C y C++ (aunque eso bien podría ser cierto).

    No es relevante, ya que se ha reformulado. 0x Deadbeef →∞ ( háblame ) 11:15, 30 de noviembre de 2023 (UTC) [ responder ]

  • "el valor de la última expresión de la función se utilizará como valor de retorno" – La forma en que el ejemplo factorial demuestra este principio es un poco confusa. La última expresión de la función es técnicamente la ifdeclaración/expresión completa, que a su vez se resuelve en la última expresión en cualquier rama que se active en tiempo de ejecución, pero este proceso de dos pasos puede no ser evidente para el lector ocasional. Sugiero dividirlo en dos ejemplos, uno que muestre un retorno simple como fn double(x: u64) -> u64 { 2 * x }y otro que demuestre que iflas declaraciones se pueden usar como expresiones.
  • La tabla de tipos sería un buen lugar para mencionar que las porciones de cadenas en Rust están codificadas en UTF-8 .

    Hecho (no por mí). 0x Deadbeef →∞ ( háblame ) 11:15, 30 de noviembre de 2023 (UTC) [ responder ]

  • La fila de referencias debe indicar que el compilador exige que la referencia no sea nula y sea válida.
  • " OptionLos valores deben manejarse usando azúcar sintáctica": "Azúcar sintáctica" no es el término correcto ya que construcciones como matchy if letno son azúcar sintáctica sino partes centrales del lenguaje, pero de todos modos esta afirmación no es cierta. Puedo llamar .unwrap()a un Optiony explotará si es None. Debes dejar más claro aquí que, si bien aún puedes bloquear tu programa en Rust al intentar acceder a un valor nulo, a diferencia de C o C++ esto se maneja mediante un pánico seguro en lugar de un comportamiento indefinido, una falla de segmentación o algo peor.
  • "Posiblemente nulo; es seguro desreferenciar" – Similar a mi comentario anterior, esto es debatible en función de su definición de "seguro".
  • "Los tiempos de vida son una parte generalmente implícita de todos los tipos de referencia en Rust". La sintaxis de esta oración es confusa. Sugiero dividirla en dos partes o dos oraciones, una sobre cómo cada referencia tiene un tiempo de vida en Rust y otra sobre cómo los tiempos de vida generalmente no necesitan ser anotados explícitamente por el programador.
  • "asigne automáticamente duraciones de vida a las funciones si son triviales" – No está claro si el antecedente de "ellos" es "duraciones de vida" o "funciones".
• Características
  • El párrafo sobre let"Tipos y polimorfismo" parece fuera de lugar. Lo mismo ocurre con el párrafo sobre typelos alias.
  • Hay cierta redundancia en la discusión de los genéricos entre aquí y la sección "Sintaxis y semántica".
  • "El sistema de tipos dentro de Rust se basa en implementaciones, rasgos y tipos estructurados". – Redacción vaga, no queda claro qué se pretende transmitir con esto.
  • "Los tipos estructurados se utilizan para definir campos". Otra frase incómoda.
  • "lo que significa que el tipo de todos los valores se conoce en el momento de la compilación": no puede ser cierto que el tipo de todos los valores se conozca en el momento de la compilación, si según la siguiente oración, tanto el envío dinámico como el estático son posibles.
  • Incluya un ejemplo de una macro declarativa.
  • "Rust también tiene una biblioteca, CXX, para llamar hacia o desde C++". – Aclare que esta es solo una biblioteca de terceros y no una parte del lenguaje Rust.
• Componentes
  • "Componentes" es un título un poco extraño como sección. No encaja perfectamente con "Sistema de control de versiones", por ejemplo. ¿Quizás "Herramientas" o "Ecosistema"?

     Listo . 0x Deadbeef →∞ ( háblame ) 13:09, 7 de febrero de 2024 (UTC) [ responder ]

  • Seguramente puedes encontrar una referencia en inglés para rustup?

     Listo . 0x Deadbeef →∞ ( háblame ) 13:09, 7 de febrero de 2024 (UTC) [ responder ]

  • "Cuando un proyecto está anotado con el atributo crate-level #![no_std]..." – Explique la diferencia entre las tres cajas de la biblioteca estándar y por qué no_stdsería deseable.

    Parece ser Ya está hecho . 0x Deadbeef →∞ ( háblame ) 13:09, 7 de febrero de 2024 (UTC) [ responder ]

• Actuación
  • "Rust tiene como objetivo 'ser tan eficiente y portátil como el lenguaje C++, sin sacrificar la seguridad'". Esto se cita en una publicación de blog individual, que comienza con la advertencia "Tenga en cuenta que esta es solo mi opinión y no un decreto oficial sobre el diseño del lenguaje de ninguna manera". ¿Puede encontrar una mejor fuente para esto?

     No se hizo porque fue eliminado. 0x Deadbeef →∞ ( háblame ) 13:18, 7 de febrero de 2024 (UTC) [ responder ]

  • La discusión sobre los modos es un poco ortogonal al rendimiento. Creo que debería presentarse en una sección diferente ("¿Características?") y mencionarse aquí solo porque se relaciona directamente con el uso unsafepara escribir código más rápido.
  • Sé que este es un tema polémico, pero resulta extraño que esta sección no compare directamente el rendimiento de Rust con C o C++ (o cualquier otro lenguaje) en las pruebas de referencia.

     No está hecho . No estoy de acuerdo con el uso de puntos de referencia. La cobertura de fuentes confiables sobre esto es mínima y no parece apropiado que hagamos pruebas comparativas para comparar lenguajes. (Hablo por experiencia, los puntos de referencia realmente no miden cosas fuera de un caso de uso específico). La comparación con lenguajes seguros para la memoria ya parece buena. (escrito después de esta PR) 0x Deadbeef →∞ ( háblame ) 13:18, 7 de febrero de 2024 (UTC) [ responder ]

• Adopción
  • Mi opinión personal es que listas como esta no deberían incluir entradas que no sean enlaces azules, por lo que eliminaría Theseus. También lo eliminaría exaporque parece que ese artículo no cumple con las pautas de notabilidad de Wikipedia.

     En parte, se hizo como parte de la prosificación de esa sección. Se eliminó a Exa y se mantuvo a Teseo con fuentes confiables.

  • Recientemente, el soporte de Rust llegó al kernel de Linux, por lo que esto debería actualizarse.

     Ya está hecho

  • No sé si puedes encontrar una fuente confiable para esto, pero Rust es ahora el lenguaje más común usado en Fuchsia (gráfico). Deberías encontrar una mejor referencia para esta entrada de todos modos, ya que el código fuente es una fuente primaria.

     No se hizo mención del fucsia, fue eliminado del artículo.

Comentarios más sustanciales:

• Algunas omisiones del artículo que parecen notables (aunque no estoy seguro de si se pueden encontrar fuentes confiables para ellas)
  • El ecosistema de crates de terceros. Esto se menciona brevemente en la sección "Cargo", pero es una parte mucho más importante del desarrollo de Rust que, por ejemplo, el desarrollo de C/C++, y creo que debería ampliarse.
  • Hay mucha discusión en línea sobre la "curva de aprendizaje de Rust"; ¿quizás una oración o dos al respecto en "Adopción"?

     ¡ Hecho ! 0x Deadbeef →∞ ( háblame ) 18:16, 17 de julio de 2024 (UTC) [ responder ]

  • No hay mucha información en el artículo sobre la implementación del compilador Rust.
• Sugiero volver a trabajar en la sección "Adopción", ya que, según mi experiencia, las secciones basadas en listas como esta tienden a acumular basura. ¿Se puede convertir en prosa que destaque algunas de las aplicaciones y bibliotecas más importantes escritas en Rust? Lo mismo ocurre con la subsección "Conferencias".

   Lo hicimos yo y Sohom Datta. Se prosificó la sección de adopción y se eliminó la sección de conferencias. 0x Deadbeef →∞ ( háblame ) 01:30, 23 de noviembre de 2023 (UTC) [ responder ]

• La división de contenido entre las secciones "Sintaxis y semántica" y "Características" no está del todo clara. Por ejemplo, ¿por qué en "Sintaxis y semántica" se tratan los genéricos, pero la definición de tipos con structy enumse deja para "Características"?
• La presentación del material en la sección "Características" necesita algo de trabajo. Dejé algunos comentarios específicos arriba, pero en general hay muchos lugares donde la organización/flujo no está claro.
• Algunas cosas para tener en cuenta a la hora de conseguir que este artículo alcance el estado destacado: (Descargo de responsabilidad: no he escrito ni revisado ningún artículo destacado. Sin embargo, he leído muchas reseñas recientes de artículos destacados, por lo que tengo una idea general de cuáles son las expectativas).
  • El nivel de calidad de la prosa es más alto para los artículos destacados que para los buenos artículos. Dejé algunas sugerencias de edición de textos, pero si estás dispuesto a esperar un poco, el Gremio de Correctores de Textos podría realizar una edición de textos más exhaustiva.
  • No realicé una verificación completa de las fuentes, pero encontré algunos lugares en los que la cita no respaldaba por completo la afirmación del artículo. El proceso de revisión de artículos destacados es muy estricto en cuanto a la integridad del texto fuente y unas pocas discrepancias pueden ser fatales para una nominación, así que asegúrese de haber verificado minuciosamente sus referencias.

Comentarios de los lectores

Soy un ex programador (C, Smalltalk, Objective-C, Perl, etc.) y ahora trabajo en otro campo. Realmente aprecié este artículo y aprendí mucho sobre Rust al leerlo con atención. Es posible que elija aprender el lenguaje más adelante. Quería señalar que hubo tres puntos en los que tuve que hacer una pausa y que algunas modificaciones podrían ser útiles para futuros lectores:

1. El material sobre los tiempos de vida es bastante técnico y el lector debe confiar en gran medida en el ejemplo para comprender lo que está sucediendo. Sin embargo, dado que la sintaxis de rust para esto es un poco opaca, el ejemplo es difícil de seguir para un programador que no sea de rust. Por ejemplo, me costó entender cómo el tiempo de vida 'src' en la estructura era relevante para el ejemplo. No estoy seguro de si me perdí algo, pero creo que la acción ocurre principalmente alrededor de 'cfg'. Puede ser útil agregar un párrafo que explique con más paciencia las implicaciones de las declaraciones en el ejemplo. Como punto adicional relacionado, no me quedó claro si estos tiempos de vida tienen el efecto de "extender" el tiempo de validez de una referencia que de otro modo tendría una vida más corta, o si tienen el efecto de activar un error en tiempo de compilación si no se pueden cumplir las restricciones expresadas en el código.

    Por fin lo terminé . Será necesario mejorar la presentación con un poco más de edición, pero los fragmentos deberían estar ahí. 0x Deadbeef →∞ ( háblame ) 04:59, 17 de julio de 2024 (UTC) [ responder ]

2. El material sobre los objetos de rasgo también es bastante conciso. La definición de estos objetos está bien explicada, pero luego se pasa a los detalles de implementación. Creo que a la sección le falta texto sobre cómo se utiliza el elemento de vector apropiado en tiempo de ejecución cuando se produce una llamada a un método. Supongo que todos los elementos del vector también deben expresar el rasgo Display y que se produce algún tipo de comprobación de tipo dinámica para seleccionar el elemento deseado. También me pregunto si es posible que la selección falle si no hay un tipo apropiado disponible. (Si esta pregunta no tiene sentido, considere que todo lo que sé sobre Rust proviene de este artículo, por lo que puede haber una oportunidad de aclararlo más en el texto).

    Listo. Lo he aclarado en la sección sobre objetos de rasgos. 0x Deadbeef →∞ ( háblame ) 02:20, 15 de agosto de 2023 (UTC) [ responder ]

3. El texto bajo el encabezado Biblioteca estándar es bastante conciso y utiliza el término "caja" sin más elaboración. Aunque el concepto de caja se define más adelante (quizás se deba considerar reordenar las secciones), no hay mucho allí para explicar qué hay en cada caja de la biblioteca estándar, o cuál es el beneficio de dividir la biblioteca estándar en tres cajas. Hay una mención a la exclusión de una de las cajas, pero no estoy seguro de qué hay allí y por qué querría excluirla. Puede ser útil considerar qué le gustaría que un lector no familiarizado con Rust tome de esta sección, o si es necesario si cae más en "cómo hacer" que en contenido "sobre" Rust.

 Hecho Caleb Stanford ( discusión ) 16:30 22 jul 2023 (UTC) [ responder ]

Una vez más, agradezco el artículo. Y como no conozco el óxido, dejaré que otros consideren los cambios. -- cmh ^{T C} 13:17, 22 de julio de 2023 (UTC) [ responder ]

Este comentario es muy útil, ¡gracias por tomarte el tiempo de escribir tu experiencia al leer el artículo! Caleb Stanford ( discusión ) 16:25 22 jul 2023 (UTC) [ responder ]

Posibles fuentes para RustConf

Estoy de acuerdo con eliminar la sección de conferencias de Rust ( WP:NOTDIR )), pero creo que RustConf por sí sola merece una mención en la sección de la comunidad como la reunión de la comunidad más conocida. Es un poco difícil encontrar fuentes secundarias, tengo 1 2 o podríamos usar fuentes de YouTube como 3. También podría valer la pena preguntar si queremos mencionar alguna de las controversias recientes relacionadas con RustFoundation, que tuvieron mucha cobertura. Caleb Stanford ( discusión ) 22:06, 29 de noviembre de 2023 (UTC) [ responder ]

Definitivamente deberíamos tratar de cubrir las controversias de la fundación Rust si hay buenas fuentes disponibles. No estoy tan seguro de la confiabilidad de las fuentes que mencionas. El autor del artículo de la revista Analytics India es un entusiasta de la IA , y la descripción de Crablang (una bifurcación no oficial y sin mantenimiento) me hace pensar que se inclina hacia el lado poco confiable. 0x Deadbeef →∞ ( háblame ) 23:58, 29 de noviembre de 2023 (UTC) [ responder ]

Sección de cierre

Actualmente, la sección de cierre arroja una sintaxis específica del analizador al usuario (y es la única sección que lo hace un tanto chocante), ¿hay alguna manera de eliminarla del artículo? (Parece ser una transclusión de una parte de un artículo diferente que hace un uso liberal de la sintaxis del analizador, lo que parece estar bien). Sohom ( discusión ) 00:42, 11 de diciembre de 2023 (UTC) [ responder ]

Esa sección no está bien ubicada. Deberíamos reestructurarla, dándole más fuentes y un flujo más natural. 0x Deadbeef →∞ ( háblame ) 14:54, 22 de marzo de 2024 (UTC) [ responder ]

Gestión automatizada de memoria

@ Wootery : No estoy seguro de entender tu edición reciente: el titular decía "sin requerir el uso de técnicas de administración de memoria automatizadas", así que ¿cómo estás leyendo esto para dar a entender que Rust es de no intervención? Parece estar indicando que Rust es de no intervención. Tal vez no sé a qué te refieres con "de no intervención". Gracias, Caleb Stanford ( discusión ) 19:31, 25 de enero de 2024 (UTC) [ responder ]

Tal vez tengas razón, mi pensamiento era que parece implicar que Rust ofrece seguridad de memoria sin ofrecer/requerir funciones de administración automática de memoria, pero el verificador de prestatarios de Rust presumiblemente cuenta como una función de administración automática de memoria, en el sentido de que no lo hace manualmente el programador. Por si sirve de algo, veo que el libro de Rust usa una redacción más cercana a lo que propongo. De todos modos, la siguiente oración lo aclara al presentar el verificador de prestatarios, por lo que no depende mucho de esto. Wootery ( discusión ) 21:42, 25 de enero de 2024 (UTC) [ responder ]

Creo que puedo entender el punto de vista de Wootery. Descartar elementos al final de un ámbito podría considerarse una "técnica de gestión de memoria automatizada". Y la oración actual podría sugerir que la gestión de memoria automatizada no existe en Rust. 0x Deadbeef →∞ ( háblame ) 00:20, 26 de enero de 2024 (UTC) [ responder ]

Ah, gracias por aclarar, ahora veo el problema. Creo que el objetivo era sugerir que Rust puede (pero no necesita) usar el conteo de referencias, pero creo que esto se expresó de manera muy críptica, por lo que deberíamos trasladarlo a otro lugar. Editado con la esperanza de aclarar, siéntete libre de editar más. Caleb Stanford ( discusión ) 17:36, 26 de enero de 2024 (UTC) [ responder ]

Preparación de FAC

Bien, después de trabajar en el artículo durante algún tiempo, soy optimista de que podremos enviarlo a FA, convirtiéndolo en el primer artículo destacado sobre un lenguaje de programación (lo que haría que eventualmente apareciera en la parte superior izquierda de la página principal de Wikipedia). Antes de enviarlo a WP:FAC , aquí hay algunas cosas que preparar:

1. Necesitamos abordar los comentarios anteriores. Hay varios comentarios en #Cómo abordar los comentarios de relaciones públicas, así como uno en #Comentarios de los lectores que son excelentes y aún se aplican. Si alguien tiene un libro sobre Rust que pueda ayudar a ampliar las explicaciones técnicas del artículo a algo que sea más comprensible para una audiencia general, ¡no dude en contribuir! (Algunos comentarios sobre los libros: he estado tratando de obtener información con la edición 2021 de The Rust Programming Language, pero no pude encontrar un libro electrónico en línea que tenga los números de página correctos. Si alguien puede enviarme uno, hágamelo saber. Tengo copias en formato electrónico de Rust for Rustaceans publicado por No Starch Press, Rust in Action de Tim McNamara y Programming Rust publicado por O'Reilly si alguien quiere, ya que son buenas fuentes)
2. Si es posible, debemos convertir todas las fuentes en línea en fuentes de libros. Vi algunas fuentes que utilizan la documentación de la biblioteca estándar y, preferiblemente, deberíamos utilizar libros en su lugar.
3. Después de esos problemas, estamos en condiciones de continuar luego de una lectura exhaustiva de los criterios de FA , revisando todas las fuentes en el artículo y viendo si realmente respaldan la afirmación, y leyendo el artículo para verificar su prosa.

Para las personas que miran esta página: ¡consideren ayudar! Estoy un poco ocupado, pero si más personas contribuyen, me animarán a contribuir más también. 0x Deadbeef →∞ ( háblame ) 13:40, 7 de febrero de 2024 (UTC) [ responder ]

Para el comentario sobre los tiempos de vida, he añadido algunos ejemplos que deberían ayudar a ilustrarlo mejor. Hay otra brecha entre hablar sobre los tiempos de vida en definiciones genéricas y el ejemplo con configuraciones de lectura, que podrían utilizar ejemplos más pequeños para construir mejor el conocimiento. 0x Deadbeef →∞ ( háblame ) 15:12, 22 de marzo de 2024 (UTC) [ responder ]

Cortar contenido del sistema operativo

Squizzler ( discusión  · contribuciones ) realizó algunas mejoras en la sección de adopción de SO (añadió r9 y Fuschia) y también eliminó el siguiente contenido. No me importa usar el texto más abreviado ya que el artículo es bastante largo, pero lo publico aquí en caso de que haya otras opiniones.

Para Linux:

 El soporte para Rust (junto con el soporte para el lenguaje C y Assembly ) se agregó oficialmente en la versión 6.1. [1]

Y para Windows:

 A partir de 2023 [update], DWriteCore , una biblioteca de sistema para diseño de texto y renderizado de glifos, tiene alrededor de 152.000 líneas de código Rust y alrededor de 96.000 líneas de código C++, y experimentó un aumento de rendimiento del 5 al 15 por ciento en algunos casos. [2]

¡Gracias! Caleb Stanford ( discusión ) 16:01 10 mar 2024 (UTC) [ responder ]

Referencias

1. "Un primer vistazo a Rust en el kernel 6.1 [LWN.net]". lwn.net . Consultado el 11 de noviembre de 2023 .
2. Claburn, Thomas (27 de abril de 2023). "Microsoft está reescribiendo las bibliotecas centrales de Windows en Rust". The Register . Consultado el 13 de mayo de 2023 .

Para Linux, existe un artículo dedicado a Rust para Linux , por lo que aquí solo se necesita un breve resumen. La inclusión de Rust en Android también forma parte del proyecto "Rust para Linux".

En mi opinión, el uso de Rust en Windows es un aspecto que debería incluirse en detalle aquí hasta que haya un artículo independiente al respecto. Microsoft es miembro fundador de la Fundación Rust, pero los detalles del uso de Rust en su sistema operativo no son tan conocidos debido a que la fuente no es pública. Las fechas son especialmente importantes.

Creo que la sección "Adopción" debería ser más como una línea de tiempo de eventos significativos en los que Rust se utilizó en productos importantes/software de usuario final, y menos énfasis en el software que aún no ganó fuerza, por ejemplo, Redox/Fuchsia/COSMIC, etc. (disculpas a cualquiera que los use en casa). John Vandenberg ^{( chat )} 00:59, 3 de septiembre de 2024 (UTC) [ responder ]

Sección de controversias

@BOBROBMEBOYO: Revertí tu edición porque no está citada y me pareció demasiado breve. Sin embargo, creo que vale la pena mencionarla en alguna parte. Debería quedar claro que se trata de la política de marcas registradas y no de la licencia del código fuente de Rust. Creo que también debería tocar eventos posteriores, como la solicitud de comentarios por parte de la fundación y la actualización de la política, y debería incluir algunas fechas. También podría tener sentido ponerlo en la sección de la Fundación Rust. Tal vez otros editores puedan participar. JamenMarz ( discusión ) 06:23, 26 de marzo de 2024 (UTC) [ responder ]

Ya está en el artículo, como último párrafo de la sección "Historia". Betseg ( discusión ) 11:47 26 mar 2024 (UTC) [ responder ]

¿Alguien puede escribir un artículo comparativo de Rust y C?

Comparable al artículo Comparación de Pascal y C que podría usarse como ejemplo. Sé que existe este artículo comparativo para casi todos los lenguajes, pero este artículo para todos los lenguajes no es el mismo, ya que solo consta de tablas y no de comparaciones de código reales como el artículo Pascal vs. C. 84.140.194.104 (discusión) 21:47 5 abr 2024 (UTC) [ responder ]

Hmm. Parece que estos artículos de comparación podrían violar WP:NOT / WP:NOTHOWTO y WP:OR . Proponer su eliminación tendría posibilidades de éxito. No estoy seguro de que sean adecuados para la enciclopedia. De todos modos, por esa razón, no estoy seguro de que se escriban nuevos artículos de comparación como Comparación de Rust y C. – Novem Linguae ( discusión ) 22:23, 5 abril 2024 (UTC) [ responder ]

Acabo de leer el artículo y fue una lectura excelente. Definitivamente no es un CÓMO ni un O. No sé si NO se aplica y por qué debería, pero definitivamente sería una gran pérdida si se eliminara el artículo. Se podría fundamentar citando algunos libros de programación, pero aparte de eso no hay nada de qué quejarse. 84.140.194.104 (discusión) 08:01 6 abr 2024 (UTC) [ responder ]

No veo ningún beneficio en comparar C y Rust. Rust vs C++ es una comparación más común, por lo que sería más valiosa y más fácil encontrar fuentes confiables. Además, C++ está evolucionando a un ritmo más similar al de Rust, con objetivos similares en el proceso de evolución. Por el contrario, si bien el estándar C se está mejorando, el alcance de la evolución está más limitado y la adopción de nuevas ediciones de C es mucho más lenta, ya que C se usa con más frecuencia por su compatibilidad y estabilidad. John Vandenberg ^{( chat )} 00:33, 4 de septiembre de 2024 (UTC) [ responder ]

{{Punto de vista}}etiqueta

@ LOLHWAT : No entiendo lo que quieres decir con "la sección de introducción parece escrita por un colaborador de Rust para una persona externa". Según MOS:LEAD , el párrafo introductorio de un artículo proporciona una descripción general del tema y, en este caso, proporciona una descripción general del lenguaje al tiempo que destaca las características más significativas (aplicación de la seguridad de la memoria a lo largo de la vida útil, adopción rápida, etc.).

¿Qué parte de esto no es neutral, en tu opinión? 0x Deadbeef →∞ ( háblame ) 12:17, 23 de abril de 2024 (UTC) [ responder ]

"Rust es un lenguaje de programación multiparadigma y de propósito general que enfatiza el rendimiento, la seguridad de tipos y la concurrencia. Aplica la seguridad de la memoria (es decir, que todas las referencias apuntan a una memoria válida) sin un recolector de basura. Para aplicar simultáneamente la seguridad de la memoria y evitar las carreras de datos, su "verificador de préstamos" rastrea la duración de vida de los objetos de todas las referencias en un programa durante la compilación. Rust fue influenciado por ideas de la programación funcional, incluidas la inmutabilidad, las funciones de orden superior y los tipos de datos algebraicos. Es popular para la programación de sistemas". La sección principal parece describir a Rust como un lenguaje de programación desde la perspectiva de un colaborador y utiliza palabras que enfatizan su supuesta "bondad". Parece haber poca mención de sus deficiencias. LOLHWAT ( discusión ) 13:13, 23 de abril de 2024 (UTC) [ responder ]

@LOLHWAT : Cuando se describe un lenguaje de programación, se describen sus características. Me parece que esta es una interpretación bastante parcial. No se encuentra que Wikipedia cubra las deficiencias de un lenguaje de programación en la sección principal ( C++ tiene una sección de críticas y Python una mención en una oración por su exceso de contenido), porque no es una característica significativa del lenguaje. A menos que haya una cobertura significativa de lo malo que es algo, no decimos que sea malo. Por ejemplo, solo podemos llamar a la frenología una pseudociencia porque casi todas las fuentes la describen de esa manera.

Estoy dispuesto a incluir cualquier crítica a Rust en una sección si puedes ayudarnos a encontrar algunas fuentes confiables que hablen sobre ello. Pero pedir críticas a un lenguaje de programación desde el principio, cuando la mayoría de las fuentes que hablan sobre el lenguaje no presentan críticas significativas al lenguaje, es simplemente crear WP:FALSEBALANCE . Voy a revertir la adición de la etiqueta, porque la justificación dada aquí parece insuficiente. 0x Deadbeef →∞ ( háblame ) 13:40, 23 de abril de 2024 (UTC) [ responder ]

okay LOLHWAT ( discusión ) 15:07 23 abr 2024 (UTC) [ responder ]

Ideas para reestructurar esto para los estándares de FA

Tengo algunas notas sobre la reestructuración de las partes que brindan una descripción general del lenguaje de programación en sí, que planeo implementar después de este comentario. Sin embargo, noté dos problemas en el artículo:

• La sección de historia, especialmente para las versiones anteriores a Rust 1.0, utiliza algunas fuentes bastante pobres, con archivos de la lista de correo para los registros de cambios y una entrevista a Graydon Hoare por InfoQ. Creo que deberían reescribirse para utilizar mejores fuentes. Algunos de los detalles, como cuándo se inició Rust o cuándo se agregaron los destructores, no son realmente necesarios en un artículo de enciclopedia, así que probablemente lo reduzcamos. El artículo de MIT Technology Review ya proporciona una buena descripción general, podríamos confiar en ese solo para la historia anterior a la 1.0.
• La sección de adopción se topa con preocupaciones de WP:DUE : ¿Qué nos hizo cubrir el blog de Cloudflare sobre el uso de Rust y no el blog de software de FooCompany sobre el uso de Rust? Creo que debemos reducirlo significativamente de modo que solo las adopciones cubiertas por fuentes de terceros (por ejemplo, Ars Technica, ZDNet, etc.) estén en el artículo.

0x Deadbeef →∞ ( háblame ) 15:05 7 jul 2024 (UTC) [ responder ]

Me parece bien. Si quieres ayuda para identificar mejores fuentes, házmelo saber o tal vez enumera otras fuentes que debamos reemplazar. Lo único con lo que probablemente no estoy de acuerdo es con la fecha de "cuándo se inició Rust" (suponiendo que podamos encontrar una mejor fuente), es un evento bastante importante desde la perspectiva del diseño del compilador. Caleb Stanford ( discusión ) 19:09 7 jul 2024 (UTC) [ responder ]

¡Cualquier ayuda para identificar mejores fuentes sería genial! No me importa poner la fecha de creación de Rust como un hito si hay una buena fuente que la menciona, simplemente asumiría que no se perdió para un artículo de enciclopedia si no lo hubo y tenemos que eliminarlo (después de todo, estamos escribiendo para una audiencia general aquí) 0x Deadbeef →∞ ( háblame ) 02:59, 9 de julio de 2024 (UTC) [ responder ]

Más elementos de acción

Estas son algunas notas que tomé cuando revisé el artículo la última vez. ¡No dudes en tomarlas y contribuir!

• No resulta de mucha ayuda organizar los tipos en tablas. Reescribirlos en prosa o listas podría ayudar a los lectores a comprender mejor los diferentes tipos con más explicaciones adjuntas a cada tipo, y también podríamos integrar mejor los diferentes tipos que brindan diferentes funcionalidades.
• La sección de punteros debe distinguir los punteros que están integrados en el lenguaje y los punteros que proporciona la biblioteca estándar, si es posible.
• La sección sobre gestión de memoria podría fusionarse con la sección de punteros como una discusión general sobre cómo Rust gestiona la memoria.
• Hay partes de discusión sobre iteradores que podrían estar en una sección general de "características de programación funcional", hablando de los diversos métodos de los iteradores.
• Lo mismo ocurre con los cierres, que también podrían fusionarse en una sección sobre programación funcional.
• Las macros variádicas no deberían ser una sección independiente; deberían fusionarse con otras secciones sobre macros como una nota relativamente breve.

0x Deadbeef →∞ ( háblame ) 05:55 18 jul 2024 (UTC) [ responder ]

Aclaración necesaria

"Las declaraciones en Rust se separan con punto y coma". "Separado" o "termina con" porque hay una diferencia. Si miramos el código, implica lo último. — Comentario anterior sin firmar añadido por 67.241.240.42 ( discusión ) 13:20, 9 de septiembre de 2024 (UTC) [ responder ]

Estoy de acuerdo en que lo último es más correcto y no estoy seguro de cuál es la mejor terminología para usar, pero... "es complicado", por ejemplo, fn main() { std::process::exit(1) }es válido. Esa función no devuelve nada, por lo que no es una "expresión" en una "declaración de retorno" implícita. fn main() { println!("foo") }También es válido, pero fn main() { let foo = 10 }no lo es; requiere la adición de un ";". John Vandenberg ^{( chat )} 03:58, 10 de septiembre de 2024 (UTC) [ responder ]

Bueno, no. Técnicamente, println!("foo")funciona como una expresión final porque es una expresión cuyo tipo de retorno es el tipo de unidad ()y la mainfunción también obtiene implícitamente ese tipo de retorno, por lo que son compatibles. Para let, es una declaración, por lo que debe terminar en punto y coma. 0x Deadbeef →∞ ( háblame ) 09:06, 10 de septiembre de 2024 (UTC) [ responder ]

Correcto. Una descripción precisa de cuándo se requiere `;` en la última declaración va a necesitar explicar el tipo de unidad/tupla cero, y que a menudo es implícito, lo que curiosamente no veo mencionado en el artículo todavía. ¿Me lo perdí? John Vandenberg ^{( chat )} 04:30, 11 de septiembre de 2024 (UTC) [ responder ]

Sí, el tipo de unidad necesita alguna explicación. 0x Deadbeef →∞ ( háblame ) 03:45, 14 de septiembre de 2024 (UTC) [ responder ]

¿Desarrollador de Rust?

Me pregunto quién es el desarrollador técnicamente: ¿ el equipo Rust o la Fundación Rust ?

He actualizado el campo `desarrollador` de "Proyecto Rust" a "El equipo Rust", ya que dice "Mantenido por el equipo Rust" en la parte inferior de la página de inicio oficial. Charles Dong ( discusión ) 12:10 26 sep 2024 (UTC) [ responder ]

Discusión de los parámetros de vida útil

La discusión de los parámetros de duración de vida aquí es un poco opaca. ¿Sería posible que alguien la expandiera? Se nos da un ejemplo, pero la sintaxis no está desempaquetada (¿cuál es exactamente el parámetro de duración de vida, por ejemplo?) y no está del todo claro cómo se usa el parámetro de duración de vida en la función de ejemplo. ¿Permite algún análisis del compilador de la función que de otra manera no es computable? Si es así, ¿cuáles son los resultados de ese análisis y qué sucedería si la función no tuviera un parámetro de duración de vida? También hay alguna discusión sobre la función que devuelve información de duración de vida. Una vez más, la sintaxis no se explica realmente (¿ese valor de retorno es una duración de vida? Obviamente no parece una para un lector nuevo en rust) y sin un ejemplo, no está claro qué uso haría el llamador de un parámetro de duración de vida devuelto. ¿Quizás introducir un fragmento de código que muestre cómo se usa ese valor de retorno?

Espero que estos comentarios sean útiles; si supiera lo suficiente para responder estas preguntas, intentaría hacerlo yo mismo, pero me temo que no puedo. Rpgoldman (discusión) 14:57 29 oct 2024 (UTC) [ responder ]

Gracias por mencionar esto. ¡Intenté editarlo por primera vez! Avísame si está más claro o si podemos hacer más modificaciones. Caleb Stanford ( discusión ) 17:53 29 oct 2024 (UTC) [ responder ]

Historia anterior a la versión 1.0

Fuentes secundarias que sean confiables. No debería ser tan difícil encontrar fuentes que cubran el desarrollo anterior a la versión 1.0, ¿verdad? ¿verdad?

cc @ Caleb Stanford : Muchas gracias por dar un paso adelante y agregar contenido en la sección de historia. La charla en Applicative 2016 es una buena fuente de WP:PRIMARY que podemos usar. Para una mayor verificabilidad, probablemente deberíamos considerar agregar marcas de tiempo para afirmaciones específicas. En cuanto a las fuentes escritas sobre la historia temprana de Rust (y algo de material adicional), busqué algunas de estas con algunas búsquedas:

• Mozilla lanza Rust 0.1, el lenguaje que acabará usurpando el C++ de Firefox, Extremetech, 2012-01-24
• Samsung se suma a la búsqueda de Rust por parte de Mozilla, CNET, 2013-04-03
• Samsung se asocia con Mozilla para crear un motor de navegación para máquinas multinúcleo, Ars Technica, 2013-04-03
• Samsung y Mozilla unen fuerzas para desarrollar el navegador web de próxima generación para Android, Extremetech, 2013-04-03
• Mozilla imagina un nuevo y valiente Firefox multinúcleo con 'Servo', WIRED, 5 de abril de 2013
• El lenguaje Rust, respaldado por Mozilla, se estabiliza en la versión 1.0, Ars Technica, 16 de mayo de 2015
• Se lanza Rust 1.0, el lenguaje de programación detrás del nuevo motor web de Mozilla, Servo, Extremetech, 20 de mayo de 2015
• Facebook está desarrollando un servidor Mercurial en Rust. No se trata de un simulacro, The Register, 18 de octubre de 2016

La cobertura sobre Rust en sí es todavía bastante limitada, pero creo que está bien. Los detalles técnicos del lenguaje antes de la versión 1.0 no eran de interés para los periodistas ni para los académicos, así que tampoco deberíamos cubrirlos. Este es un artículo enciclopédico que se supone que proporciona información general sobre el lenguaje, por lo que usar extensamente una fuente primaria para cubrir algo de historia técnica resulta desagradable. Siento que deberíamos simplemente reducir los detalles técnicos (ver también WP:NOTCHANGELOG ) y hacer declaraciones más generales sobre el desarrollo (que provengan directamente de la fuente de la conversación o de una fuente secundaria). 0x Deadbeef →∞ ( háblame ) 06:29, 1 de noviembre de 2024 (UTC) [ responder ]

Pasaré un poco más de tiempo haciéndolo si tengo algo de tiempo libre este fin de semana... antes de eso, disculpen mis comentarios desde el asiento trasero ^^' 0x Deadbeef →∞ ( háblame ) 06:30, 1 de noviembre de 2024 (UTC) [ responder ]

¡Gracias! 😅 Estoy totalmente de acuerdo con el sentimiento. Algunos puntos específicos a continuación:

En cuanto a fuentes escritas sobre la historia temprana de Rust (y algo de material adicional), busqué algunas de estas con algunas búsquedas:

¡Esto es increíble y muy útil, gracias! Honestamente, mientras escribía esto, necesitaba urgentemente más fuentes.

> Los detalles técnicos del lenguaje anterior a la versión 1.0 no interesaban a los periodistas...

¡Estoy de acuerdo! Creo que debería aclarar lo siguiente:

• Lo que creo que es de interés general: (1) los detalles no técnicos, incluyendo cómo surgió Rust, cómo se financió; (2) quién estuvo involucrado (contribuyentes principales e individuos); (3) por qué y cómo creció en popularidad; (4) cambios conceptuales importantes a lo largo de los años (como la eliminación del recolector de basura y la pureza de funciones) que son relevantes para Rust hoy y para su desarrollo histórico. Muchos de estos detalles faltaban por completo en el borrador anterior (¡y gran parte de él todavía está incompleto! Por ejemplo, el artículo anterior a este ni siquiera nombra al equipo central o los desarrolladores iniciales del lenguaje después de los años de Graydon).
• Lo que creo que se debería omitir: (5) cambios sintácticos o ejemplos de sintaxis antigua; (6) contenido del registro de cambios (como el primer párrafo de Evolution, lo dejé porque ya estaba redactado anteriormente, pero en realidad creo que debería condensarse en una o dos oraciones como máximo).

> La charla en Applicative 2016 es una buena fuente de WP:PRIMARY que podemos usar

¿Estás absolutamente seguro de que es primario? Klabnik no participó antes de la versión 0.1 (las primeras dos subsecciones). Entendí que su opinión era secundaria sobre esa base. Por supuesto, deberíamos interpretar el video como WP:PRIMARY posterior a su participación, después de que se le agregó al equipo central (no estoy seguro de la fecha exacta, pero podemos buscarla).

¿Eso también convertiría a Klabnik y Nichols en candidatos primarios? Lo cual podría ser... un problema un poco serio, si eso es realmente lo que estás afirmando y no estoy malentendido ni equivocado.

LMK lo que piensas, sospecho que estamos cerca de un consenso aquí si podemos estar de acuerdo sobre el estado de la participación de Klabnik antes del 0.1.

Caleb Stanford ( discusión ) 19:08 1 nov 2024 (UTC) [ responder ]

PD Por cierto, ¿por qué permitimos todos estos enlaces de mail.mozilla.org pero no el historial de fuentes de GitHub? ¿Porque no está archivado? No tengo clara la distinción. ¡Gracias! Caleb Stanford ( discusión ) 23:22 1 nov 2024 (UTC) [ responder ]

Deberíamos eliminarlos. Solo eliminé uno porque me dio un poco de pereza. ¡Lo siento! 0x Deadbeef →∞ ( háblame ) 03:13, 2 de noviembre de 2024 (UTC) [ responder ]

¡Gracias! Eso tiene mucho más sentido :-) Caleb Stanford ( discusión ) 17:50, 3 de noviembre de 2024 (UTC) Estoy de acuerdo con WP:IS y el razonamiento a continuación. Gracias por aclararlo. Caleb Stanford ( discusión ) 17:50, 3 de noviembre de 2024 (UTC) [ responder ]

No estoy completamente seguro. Creo que llamarlos (a la charla y al libro) secundarios está bien, aunque también hay que tener en cuenta a WP:IS . Y tal vez Klabnik no se considere un tercero, ¿podríamos seguir considerando la fuente como independiente? Wikipedia:Parte y persona#¿"Tercero" no significa "independiente"?

En cuanto a qué partes son de interés general, creo que partes de (4) podrían ser debatibles. Por ejemplo, creo que podemos citar el hecho de que Samsung contribuyó a Rust 0.6, que agregó soporte para ARM según algunas de las fuentes que mencioné, pero ¿las cosas sobre los estados de tipo y las funciones puras? Puede que no sean necesarias. 0x Deadbeef →∞ ( háblame ) 03:37, 2 de noviembre de 2024 (UTC) [ responder ]

Argumentaré a favor de la inclusión de los estados de tipo y las funciones puras. En cuanto a los estados de tipo, bueno, personalmente no me interesan demasiado, pero (según las fuentes que he leído) mucha gente habla de ellos como una parte importante de la historia del lenguaje, y parecieron tener un impacto en el diseño conceptual de Rust desde el principio. Así que, aunque personalmente no me importe, no me siento cómodo anulando las fuentes. Eliminar las funciones puras, por otra parte, fue ( advertencia de WP:OR ) posiblemente el mayor error en la historia del lenguaje. (fin de WP:OR ) En cuanto a la relevancia, tiene que ver con las afirmaciones sobre la relación con la programación funcional y la influencia de la programación funcional en el lenguaje (que es de interés general) y que discutimos en varios lugares. Caleb Stanford ( discusión ) 18:01, 3 de noviembre de 2024 (UTC) [ responder ]

¿Existen fuentes confiables que hablen de los estados de tipos como una parte importante de la historia del lenguaje?

Entiendo por qué consideras que la eliminación de las funciones puras es un acontecimiento importante, pero hasta ahora tu razonamiento probablemente no se ajuste a la forma principal en que abordamos las decisiones editoriales. Si hay fuentes confiables que hablan de la eliminación de las funciones puras como un hito clave, entonces genial, escribamos eso en el artículo. Si no las hay, no nos pongamos tristes porque no lo incluyan. 0x Deadbeef →∞ ( háblame ) 09:16, 4 de noviembre de 2024 (UTC) [ responder ]

PD: He restaurado la fuente de RustConf 2022, pero avísame si no estás de acuerdo. Tampoco tengo claro por qué no podemos usar un número limitado de fuentes primarias "para hacer declaraciones sencillas y descriptivas de hechos que puedan ser verificados por cualquier persona educada con acceso a la fuente primaria pero sin conocimientos especializados adicionales" ( WP:PRIMARY ), que es exactamente lo que estoy haciendo; aquí no hay ninguna interpretación. Solo intento aclarar nuestros propios hechos. Si lo consideras de interés general es una pregunta aparte. ¡Gracias! Caleb Stanford ( discusión ) 23:50 1 nov 2024 (UTC) [ responder ]

La fuente de RustConf 2022 parece respaldar solo la declaración dentro de la nota al pie, pero no el contenido principal (cuando el compilador se inició correctamente) 0x Deadbeef →∞ ( háblame ) 03:17, 2 de noviembre de 2024 (UTC) [ responder ]

Ah, tienes razón en eso. Lo pensé un poco y creo que deberíamos eliminar la afirmación. Pero WP:ABOUTSELF no se aplica aquí, ¿verdad? @ Sohom Datta : ? Estoy confundido con el mensaje (no con la reversión en sí). Esa es una fuente secundaria. ¡Gracias! Caleb Stanford ( discusión ) 17:52 3 nov 2024 (UTC) [ responder ]