Reflexiones sobre Rust 2019

Colegas, buenas noches a todos!

Nos complace ofrecerle una traducción de un artículo verdaderamente programático de Raf Levin , cuyo trabajo titánico en el desarrollo del lenguaje Rust evoca respeto y reverencia:



Sin falsa modestia y sin odio, un autor respetado objetiva y entusiasta respondió al llamado de la comunidad Rust, publicado por referencia al comienzo de este artículo. Esperamos que haya resultado interesante y que afirme la vida.


Recientemente, el equipo principal de Rust propuso escribir artículos con opiniones sobre cómo debería crecer Rust en 2019. Aquí está mi opinión.

Ciclo de vida de maduración

En este artículo consideraré el ciclo de vida de la maduración en una forma extremadamente simplificada. Deje que consta de solo tres etapas: investigación, desarrollo, pulido. Los diversos elementos de Rust difieren en sus diversos grados de madurez. Es importante tener esto en cuenta al tratar de caracterizar con precisión la etapa actual del desarrollo del lenguaje e, idealmente, llevarla a la siguiente etapa. Por ejemplo, me parece que el lenguaje se encuentra principalmente en la etapa de "pulido". Si persiste en el hecho de que la etapa de "investigación" aún no se ha completado, entonces el lenguaje puede enriquecerse con tipos dependientes, estructuras virtuales , etc., lo que sería interesante, pero contraproducente. Lo contrario también es cierto: no podemos formular exactamente lo que nos falta en la interfaz gráfica de usuario, por lo que es probable que los intentos prematuros de llevar estas búsquedas a una solución estándar den resultados subóptimos.

En muchos productos maduros, los lanzamientos se alternan, algunos de los cuales se dedican a ejecutar nuevas funciones, mientras que otros se dedican a su estabilización. Tal, por ejemplo, es el sistema tic-tock de Intel. Las versiones de Android de Kat Kit y Marshmallow eran estables, mientras que Lollipop estaba palear activamente). En 2018, Rust se enriqueció con muchas características nuevas, por lo que creo que ha llegado el momento de la fase de estabilización. En esto estoy de acuerdo con Jonathan Turner , así como con muchos otros.

Lenguaje óxido

Creo que, en general, el lenguaje Rust está listo. Parece que la comunidad ha llegado a un acuerdo sobre la necesidad de "aterrizar" aquellas características que todavía están "sobre la marcha" (en desarrollo): estamos hablando de asíncrono / espera, genéricos constantes y un intérprete (que probablemente nos proporcione una revisión) tipos genéricos asociados ). Sin embargo, creo que, además de esto, no deberíamos ser demasiado entusiastas para llenar la tubería con nuevas características.

El cambio cuesta dinero. A partir de 2018, se han escrito dos excelentes libros sobre Rust, pero ambos ya están un poco desactualizados. Las convenciones para las rutas calificadas difieren en ellas, ahora usamos dyn Trait , etc. Cuanto más dinámicos sean los cambios, mayores serán las molestias para los usuarios.

Hay muchos factores que limitan el éxito de Rust; No creo que la mayoría de estas deficiencias sean inherentes al lenguaje en sí.

Aparejo

Una plataforma Rust podría haber sido mucho mejor. Experimenté con RLS, pero siempre volví a un editor de texto normal y un bucle de línea de comando (para ser honesto, no he configurado estos experimentos últimamente). Creo que a largo plazo es necesario modificar significativamente las herramientas de Rust para al menos de alguna manera facilitar la curva de aprendizaje. Tengo algunas ideas (espero que haya tiempo para explicarlas con más detalle) sobre un lenguaje de efecto invernadero, del cual no estoy seguro de dónde es factible, dónde no habría una diferencia clara entre el valor y el enlace, el valor podría usarse después de moverse, etc. . En principio, dicho lenguaje permitiría que una cadena sea tratada como un número. El servidor acepta programas escritos en este idioma, los corrige rápidamente y los convierte en un óxido completo.

Naturalmente, RLS solo corresponde a la mitad, los usuarios interactúan con él a través del editor. Trabajar con xi-editor es conveniente, aunque generalmente requiere algo de orientación y apoyo. Este trabajo fue realizado por una comunidad dirigida por Colin Rofles , y estoy feliz de ver cómo mejora este editor (ya se ha convertido en mi editor principal). Proporciona soporte para el servidor de idiomas, así como nuevas características, por ejemplo, un mecanismo de anotación general, que se finalizará mucho mejor en 2019.

Ecosistema de la biblioteca

El mejor trabajo ahora está en pleno desarrollo en la creación de bibliotecas para Rust. A continuación enumero las cosas que planeo hacer yo mismo.

Uno de los temas que me gustaría plantear es la "coherencia", que, en mi opinión, es una de las características más valiosas de Rust, junto con el componente técnico de su sistema de tipos . Muchos componentes del "motor del juego" dentro de C ++ son una selección cuidadosamente preparada de bibliotecas que interactúan bien entre sí. Pero en Rust, muchas de estas cosas suceden orgánicamente. Los contenedores generalmente se afilan para usar en paquetes, y si usas correctamente cosas como, entonces todo lo demás está mejorando. Un ejemplo particularmente convincente del segundo tipo es mint , que garantiza la interoperabilidad de muchos contenedores matemáticos, a pesar de que las convenciones utilizadas para definir los tipos de vectores no coinciden en ellos.

SIMD

Creo que las bibliotecas SIMD todavía están bajo investigación. Hay muchas bibliotecas de envoltorios, cada una de las cuales ofrece una perspectiva ligeramente diferente y un conjunto diferente de compensaciones: simdeez , packed_simd , más rápido y, por supuesto, mi propio fearless_simd . Estos compromisos están lejos de ser incondicionales, porque algunos usuarios necesitarán exprimir todo el rendimiento del lenguaje hasta la última gota, y si gravita en tales extremos, tendrá que recurrir a las mejores instrucciones para procesadores específicos. Otros apreciarán la portabilidad y la seguridad.

Uno de los errores SIMD más importantes es que se necesita mucho más trabajo en el compilador, en gran parte para la interacción con las arquitecturas SIMD AVX-512 y no x86. También es posible que las bibliotecas de contenedor requieran algunos cambios a nivel de idioma para que el trabajo sea lo más conveniente posible; Entonces, por el momento, incrustar y cfg(target_feature = ...) interactúan mal. En mi opinión, este es otro tema que requiere investigación. Es interesante entender hasta dónde podemos llegar sin soporte adicional a nivel de idioma, y ​​¿qué características exactamente ayudarán a aumentar fundamentalmente la conveniencia de trabajar con él?

Audio

Hay convenientes contenedores de audio de bajo nivel, entre los que se debe destacar especialmente el cpal . Sin embargo, puede haber dificultades con él a nivel de rendimiento (el contenedor no siempre utiliza la transmisión en tiempo real), algunas posibilidades. Es necesario encontrar la forma óptima: modificar cpal o desarrollar un nuevo contenedor que solucione problemas específicos. Para esto, en particular, debe mirar cuidadosamente las bibliotecas de C ++, por ejemplo, RtAudio , que resuelven bien estos problemas.

Para la síntesis de audio de nivel superior, tengo grandes planes para sintetizar rs . Esta opción no es adecuada para todos, pero creo que es una buena base para una variedad de técnicas de síntesis y efectos de audio. Parece que hoy esta área de trabajo se encuentra entre las etapas de investigación y desarrollo.

Para seguir con esto, echa un vistazo a la secuencia #synthesizer en nuestro chat de Zulip. En noviembre, di una conferencia sobre esto, sobre la base de la cual planeo escribir una publicación pronto.

GUI

Las interfaces gráficas de usuario son actualmente uno de los puntos más débiles de Rust. Creo que en 2019 veremos muchos artículos sobre este tema en la comunidad Rust.
Personalmente, me parece que las GUI de Rostov ahora deben atribuirse a la fase de "investigación". Se están elaborando muchos enfoques alternativos, y hasta ahora no hay consenso sobre cuál de ellos es el mejor. ¿Qué tan activamente deberían usarse los gráficos 2D y otras primitivas de interfaz de usuario en la arquitectura del sistema, o deberíamos implementar toda esta pila por nuestra cuenta? ¿Es necesaria la implementación en la web (usando wasm)? ¿Debería percibirse todo el proceso de programación como "Rust-native", o es mejor adaptarse a las convenciones establecidas en alguna GUI madura? ¿La comunidad Rust tiene suficientes recursos para crear un nuevo kit de herramientas GUI? Y si es así, ¿vale la pena?

Comencé un proyecto Druid para hacer una GUI para mi sintetizador y juego, pero este proyecto es de investigación. Presenta mi punto de vista, mis respuestas a todas las preguntas formuladas anteriormente y, en mi opinión, este proyecto se está desarrollando bien. Pero, repito, este es un proyecto de investigación, y sería muy tonto en esta etapa introducirlo en otros proyectos.

Además, varios otros proyectos de desarrollo de GUI están en marcha. En mi opinión, el más prometedor de ellos es Azul , porque me gusta WebRender como base para construir una GUI. Otro proyecto muy prometedor es OrbTK , realizado sobre la base de Redox, pero multiplataforma y realmente avanzado. Puede aprender mucho de los ejemplos de Conrod , ggez , así como de los envoltorios de herramientas de otros idiomas.

Como era de esperar, la actividad de desarrollo de GUI más intensa en Rust está estrechamente relacionada con los juegos, y me parece que esto es bueno. Las innovaciones se arraigan mejor en el segmento de juegos, y la necesidad de herramientas maduras no es tan aguda aquí. Pero, tan pronto como aparece un excelente enfoque para la implementación de la GUI en Rust, creo que encontrará la aplicación más amplia. También noto que mi Druida se originó en base al nivel de GUI del editor del cliente xi para Windows .

Marcado

La biblioteca pulldown-cmark se usa bastante bien, en particular para rustdoc, pero en algunos aspectos está en desuso. Su evolución no sigue el ritmo del desarrollo de la especificación CommonMark. Una de las razones por las que se atascó un poco es con el algoritmo de análisis; Ya tengo una idea de cómo escribir un nuevo algoritmo para este propósito, mucho mejor que antes; pero aún no he resuelto los detalles. Recientemente, he vuelto a este trabajo y me estoy preparando para lanzar un algoritmo. Cuando se new_algo rama new_algo a master, creo que la comunidad debería continuar con su desarrollo y enriquecerla con nuevas características. Estoy pensando en la compatibilidad total de GFM, las matemáticas y tal vez algo más como eso.

Gracias a todos en la comunidad de Rust por finalizar el idioma con el que disfruto vivir.