Rust para desarrolladores web: inicio rápido y vuelo rápido

Hola a todos! Hoy quiero compartir mi experiencia en el aprendizaje del idioma y la rápida implementación de un proyecto de red de alta carga utilizando las conexiones de red asincrónicas sin bloqueo, ahora tan populares y populares, en un lenguaje Rust nuevo, hermoso, elegante y muy efectivo.
Pondré especial énfasis en la publicación en una explicación rápida y clara de las capacidades del lenguaje y la plataforma para especialistas que tienen una amplia experiencia en desarrollo web, porque yo mismo lo soy. Existe la idea errónea de que la curva de entrada en Rust es muy, muy empinada. Pero mostraré que esto está lejos de ser el caso. Vierta café y condujo!

Una breve historia de los valores de programación

Para que el material se encuentre bien en la cabeza y el corazón, es bueno recordar brevemente lo que la gente quería hacer en la programación durante los últimos 50 años y con qué terminaron. Sin ofender, solo opinión personal subjetiva y holivar, respaldada por 20 años de experiencia en desarrollo.

Lenguajes de bajo nivel: C, C ++

Está claro que puede escribir el programa inmediatamente en forma de números en códigos de máquina y muchos lo hicieron en ZX Spectrum, BK0010-01 y en PC; el código resulta ser muy rápido :-) Pero somos personas, mucha información no cabe en nuestras cabezas, estamos distraídos y por lo tanto incluso la invención del ensamblador no ayudó mucho: el código a un nivel tan bajo rara vez se escribe y es muy preciso y, muy probablemente, si no está desarrollando controladores, microcontroladores o sistemas embebidos complicados, esto no será útil en la vida.


A principios de los años 70, Bell Labs inventó el lenguaje C, que se arraigó gracias a la sintaxis lacónica y abstracciones muy "baratas", casi convirtiéndose en un "ensamblador portátil". Está claro que si tomas una tonsura, escribe durante 10 años en las noches C, no comas carne, ores y no te distraigas con las redes sociales y el sexo justo, puedes escribir programas muy útiles y rápidos, como GNU testifica elocuentemente, excelentes juegos productivos, querido, pero no alternativo en calidad de Windows, y se pueden dar muchos más ejemplos.
Pero la otra cara de la moneda se hace sentir constantemente: abre regularmente agujeros en la seguridad (se ha creado una industria completa para "agujeros en el software"), causada por agujeros en el concepto del lenguaje C en sí mismo: el compilador es como un toro irresponsable, con un poder increíble, un orgasmo intenso y poca memoria. Cualquier negligencia, y no solo puede soltar el programa (desreferenciar un puntero nulo, liberar dos veces el puntero, salir de la matriz), sino arruinar irrevocablemente los datos y no notarlos durante mucho tiempo hasta que los clientes comiencen a llamar y cuando sea demasiado tarde ("comportamiento indefinido", diferente de compilador a compilador).

Björn Straustrup solo confundió aún más la situación a principios de los años ochenta, agregando capacidades OOP a C. A pesar de su gran popularidad, C ++, en general, es visto como una serie de experimentos de programación, como tal, con diferentes resultados de éxito, incluyendo letal A veces incluso parece que no tenía sentido en C ++ desde el principio, o se perdió gradualmente, dando lugar a un montón de conceptos objetivamente complicados y conflictivos, que se vuelven cada vez más con cada nuevo estándar. A pesar del excelente objetivo de "abstracciones de costo cero", que le permite obtener un código rápido, para crear una solución confiable, como en C, se requieren las siguientes condiciones:

• experimentado, de la palabra "muy", equipo (años de práctica, "monjes" de programación)
• buen analizador de código estático
• departamento de pruebas (en el código puede haber huecos que deja un compilador irresponsable, lo que puede hacerse sentir durante mucho tiempo)
• requisitos acordados por todos los miembros del equipo que son monitoreados cuidadosamente (no se utilizan punteros en bruto, encapsulación estricta, la disciplina más severa para nombrar variables, inicializar objetos, etc.)

Está claro que el cumplimiento de estos requisitos, especialmente en el contexto de una creciente necesidad empresarial de un "código que funcione sin sorpresas repentinas", es muy costoso. El código en tales proyectos está escrito durante mucho tiempo, debe probarse durante mucho tiempo y con cuidado, pero, a veces, sin C / C ++, antes de la invención de Rust, era realmente difícil de hacer.

Una vez más, un resumen de C / C ++: tenemos un compilador poderoso, pero "irresponsable" con "abstracciones actuales", que ayuda muy poco al desarrollador. Como resultado, todos los problemas pasan a los hombros del programador. Si al menos un programador en el equipo no tiene experiencia, no tiene mucho cuidado y no conoce todas las sutilezas del compilador (de hecho, nadie conoce todas las sutilezas y los usuarios las encuentran más tarde), espere el problema. Pero luego el programa funciona de forma rápida y probablemente correcta :-) Esto, por supuesto, generó todo un mercado de "muletas": analizadores estáticos, que, como resultó, deberían ser pagados por el Cliente. Surge la pregunta: ¿no podría ser posible escribir un compilador más estricto y seguro que ayude al desarrollador y genere programas sin sorpresas y agujeros de seguridad de bajo nivel?

Java, C #, Kotlin

La situación con un control francamente débil del "comportamiento indefinido" y requisitos muy altos para los desarrolladores en C / C ++ dieron lugar al deseo de crear un entorno de desarrollo seguro, que incluye para Internet, accesible para la mayoría de los visitantes. Entonces a finales de los 90 apareció Java.
En principio, ahora cualquier persona con un nivel diferente de capacitación podría escribir cualquier cosa y FUNCIONÓ y no poner en el programa: no hubo "agujeros" de bajo nivel en la seguridad y accidentes espontáneos (casi, pero ya fueron causados ​​por errores en una máquina virtual y fija centralmente). Solo había "agujeros" lógicos o código lento oculto (nacido de la ignorancia de los algoritmos, el concepto de costo algorítmico y la desaceleración cuando aumentaba el volumen de datos), que ya no daba tanto miedo y le permite crear programas rápidamente y, si es necesario, reescribir pequeños fragmentos con un equipo calificado de C / C C ++.
Las cosas interesantes y valiosas que ha traído el mundo de Java son las siguientes:

• El código se escribe una vez para una máquina virtual que funciona en cualquier arquitectura (Windows, Linux, Mac)
• el desarrollador ya no administra la memoria directamente, como en C / C ++: esto se transfiere a los hombros del "recolector de basura"; Esto elimina el riesgo de comportamiento indefinido, corrupción discreta de datos y posibles agujeros de seguridad de bajo nivel.
• el código se compila sobre la marcha, mientras se ejecuta el programa (compilación Just_In_Time), porque se sabe que solo una pequeña parte se ejecuta activa y frecuentemente en el programa, por lo que no tiene sentido compilar todo
• se hizo más fácil escribir código eficiente de subprocesos múltiples, como el modelo de memoria se especificó estrictamente (mucho antes que en C ++), pero, más sobre eso, no se resolvieron todos los problemas con la "confiabilidad lógica de varios subprocesos" (los puntos muertos, por ejemplo, o las carreras de datos, seguían siendo posibles)

Por supuesto, el advenimiento de una plataforma tan amigable hizo posible escribir muchos programas útiles e inútiles, que la empresa aprovechó de inmediato. Y el soporte para la compatibilidad con versiones anteriores en Java durante 15 años o más ha hecho que la tecnología sea tan popular en el mundo empresarial.

Sí, también tengo analogías con la cerveza sin alcohol y las mujeres de goma.

Sin embargo, lejos de inmediato, los siguientes problemas surgieron en Java:

• Debido al "agujero" lógico en el sistema de mecanografía, que se heredó de C / C ++, el tipo "Nulo" se introdujo en Java, que hasta el día de hoy causa muchos problemas y conduce constantemente a fallas de programadores "poco experimentados" que no conoce el tipo opcional y no está interesado en mónadas de programación funcional
• Los proyectos Java, que a veces funcionan un poco más lento, requieren órdenes de magnitud más RAM que C / C ++ que necesita el recolector de basura (tenemos varios proyectos que consumen decenas o cientos de gigabytes de RAM); esto a menudo no es un problema directo, ya que Los precios de la RAM están cayendo, pero el "sedimento se mantuvo"
• A pesar de la compilación de jit y las grandes inversiones para acelerar el recolector de basura (que muchos nuevos aparecen regularmente y dicen constantemente: "pruebe un nuevo GC, es mucho mejor"), durante unos 20 años, algunos proyectos Java altamente cargados han estado trabajando con pausas regulares durante varios segundos, que no se puede quitar de ninguna manera (hay una recolección forzada de basura, y como los tornillos en el GC no se tuercen, el recolector de basura simplemente no tiene tiempo para limpiar todo, incluso trabajando en paralelo e incluso devorando más recursos que el programa en sí)
• Se sabe que las aplicaciones Java GUI a veces se congelan y ralentizan, causando enojo a los usuarios, debido a la misma recolección de basura y no hay esperanza y no se espera
• la sintaxis del lenguaje es muy detallada y redundante (debe escribir y luego leer las palabras "función estática pública" en lugar de, por ejemplo, "pub fn" o "def"), forzando a veces a romper los dedos en las uñas y causar dolor objetivo y sangrado de los ojos
• una fuerte disminución en los requisitos para el nivel de calificaciones de los desarrolladores y una curva de entrada suficientemente baja dieron lugar a una gran cantidad de código de "grado extraño de frescura", que constantemente se hace sentir a lo largo de mi vida con un hedor memorable

Después de leer, debe quedar claro que no todo se puede escribir en Java, se escribirá muy lentamente, luego se ralentizará regularmente y se bloqueará por un segundo bajo carga, a veces "come" mucha RAM (generalmente se come al menos la mitad de la RAM del servidor), juegos productivos Tampoco puede hacerlo, pero algunas piezas de lógica empresarial que no son particularmente exigentes en cuanto a rendimiento y RAM, especialmente las de múltiples subprocesos, son bastante posibles, útiles y, por lo tanto, vemos tanta popularidad de la tecnología en el mundo empresarial. Y nosotros mismos utilizamos Java de manera regular y activa para los servicios de la empresa.

C #, Scala, Kotlin

"¿Y cuándo será sobre Rust?" - espera un minuto, necesitas un poco más de preparación para comer este dulce caqui. Si no habla sobre las características de otras tecnologías, no entenderá por qué apareció Rust y por qué es tan popular y tan demandado .

Entonces, tratando de hacer que Java sea mejor y más progresivo, Microsoft, en la persona del autor TurboPascal / Delphi, al comienzo del cero, ideó C # y el concepto de .NET. Objetivamente, según muchos expertos de renombre, y en las salas de fumadores de los desarrolladores, "C #" es más sexy que Java, aunque, por supuesto, hasta ahora, a pesar de Mono, está fuertemente vinculado a Microsoft con todas las entradas y consecuencias :-)

Scala es sin duda un gran paso adelante, ya que El lenguaje, por supuesto, resultó ser científicamente abstruso y sofisticado, tomando muchas cosas útiles e inútiles del mundo de la programación funcional. Pero algo no está muy claro con la popularidad. Sin embargo, Apache Spark es realmente bueno y popular, nada que decir.

Kotlin es popular porque hace que Java sea más eficiente y fácil para los principiantes, especialmente en plataformas móviles que no tienen tiempo para estudiar seriamente la programación :-)

Pero el problema principal en C # (en la plataforma .NET), así como en Scala, Kotlin y en otros lenguajes JVM, persistió. ¡El recolector de basura, Carl, crea una carga notable en el servidor y detiene la ejecución del código durante segundos bajo carga y requisitos de RAM glotones! Y cuántos idiomas más con un recolector de basura y compilación jit no aparecerán, estos problemas permanecerán y aún no hay esperanza, incluso en teoría.

Scripting

"Pero, ¿qué pasa con PHP?". Sí, ahora hablemos de scripting. Parecería, ¿por qué es él? A finales de los años 80, se hizo evidente que si necesita resolver rápidamente el problema utilizando código, no necesariamente súper rápido, y es seguro, sin un comportamiento indefinido y agujeros de bajo nivel, puede escribir un guión. Los guiones se escribieron antes, en bash, perl, awk, pero resultó que en python puedes escribir guiones grandes, grandes, especialmente científicos, ¡y durante años!

Lua encontró su nicho en gamedev y machine learning ( Torch ), JavaScript, en desarrollo web tanto en el lado del navegador como en el lado del servidor (todos saben que la autorización en la infraestructura "npm" de Node.js se reescribe desde Node.js y Golang en óxido?). Python: en el aprendizaje automático y el análisis de datos, así como en las secuencias de comandos del sistema. Y PHP: se adapta perfectamente a las tareas del servidor para el desarrollo web.


Las ventajas de los scripts son obvias:

• El código seguro y eficiente sin comportamiento indefinido y agujeros de seguridad de bajo nivel, usando algoritmos populares y estructuras de datos (listas, diccionarios, colas), se crea en literalmente minutos
• Un comienzo muy rápido y una curva de entrada suave. Lleva varios días descubrir y escribir un script python útil, cambiar la lógica de nginx a través de scripting en Lua, o hacer la integración de la tienda en línea en PHP
• Si escribe scripts de manera disciplinada, observando CodeStyle y de la forma más estricta posible, puede resolver rápidamente problemas complejos y crear grandes productos de software: una gran cantidad de bibliotecas científicas en Python, sistemas de administración de sitios web y negocios en PHP, plataforma de red neuronal Torch en LuaJit, scripting de juegos en muy juegos famosos y populares, etc.
• Algunos tipos de programación multiproceso, donde I / O es el cuello de botella, se resuelven de manera bastante eficiente en Python. Y utilizando las últimas funciones de Python con futuros como "async / await" es aún más fácil resolver los problemas de procesamiento de una gran cantidad de sockets de red
• De manera muy elegante, la tarea de procesar asincrónicamente una gran cantidad de zócalos, incluso sin subprocesos múltiples, se resolvió en Node.js fuera de la caja
• Crear páginas web, usar numerosas bibliotecas de Unix, ir a la base de datos sigue siendo fácil y conveniente usando PHP y productos basados ​​en él
• En Python, PHP, JavaScript es muy conveniente probar hipótesis y hacer prototipos en horas, no en meses.
• Para el análisis y el procesamiento de datos, tradicionalmente es muy conveniente usar python / R junto con una gran cantidad de bibliotecas de alta calidad (pandas, scikit-learn, seaborn, matplotlib ...)

Sin embargo, no puede conocer las posibles desventajas de los scripts:

• Un nivel de entrada bajo y una velocidad de secuencia de comandos muy rápida a veces, en ausencia de un control adecuado sobre los desarrolladores, crea toneladas de código ineficiente y difícil de mantener en cualquier plataforma
• La ausencia de un compilador, un sistema de tipos y una escritura estática requiere una verificación dinámica de los parámetros pasados ​​a las funciones y métodos para los tipos y una cobertura de código de alta calidad con pruebas automáticas. De lo contrario, cualquier cambio en el código puede romper el programa y el cliente, y no el desarrollador, será el primero en saberlo (sí, sé sobre TypeScript, pero son muletas y cataplasmas muertas)
• Objetiva y obviamente, en lenguajes sin tipeo y compilación estáticos, donde suceden muchas cosas en tiempo de ejecución, no se pueden usar numerosas optimizaciones y, por lo tanto, en algunas tareas, los scripts funcionan con órdenes de magnitud más lentas y consumen muchas veces más recursos. A pesar de los intentos de implementar la compilación jit en python (pypy), PHP (hhvm), JavaScript (traducción al código de máquina, wow, Node.js v8), LuaJIT: no nos engañemos: todo esto parece muletas débilmente eficientes. La razón es, y debe entenderse de una vez por todas, que debido al tipeo deliberadamente débil de los idiomas, es poco probable que los scripts logren escribir un tiempo de ejecución efectivo, acercándose en velocidad a Java / C # mucho más tipado
• Y en Python, parece que nunca habrá multihilo eficiente, como en Java / C #, debido a GIL

Sin embargo, desde en la mayoría de las aplicaciones comerciales, incluidas sistemas de gestión del sitio, CRM, etc. Dado que la mayor parte del tiempo de ejecución del código se dedica a consultas a la base de datos, la ventaja de jit Java / C # está profundamente nivelada por la velocidad de escribir soluciones en PHP / python / JavaScript, y personalmente, para crear aplicaciones web, seleccionaré 10-20 líneas en PHP de 10,000 cuerdas y un montón de menudillos en Java / Spring. Y PHP7 de alguna manera overclockeó para que se ejecute más rápido que python3 ;-)

¿Qué conclusión se puede hacer aquí? No es necesario resolver todos los problemas, como ahora es popular, solo mediante secuencias de comandos; en algunos casos, es razonable tomar otra herramienta más adecuada, si hay buenas razones para esto:

• cargas de red muy altas y subprocesos múltiples "extremos", miles - decenas de miles de sockets de red, etc.
• restricción en el uso de RAM y hardware
• procesamiento intensivo de datos y computación, matrices con millones de entidades, GPU (aunque python / numpy / pandas pueden ayudar aquí)

A menudo en la empresa practicamos este enfoque:

• tomar una decisión rápidamente en PHP / python / JavaScript / Node.js, lanzarse a la batalla y comenzar a resolver los problemas del cliente
• ejecutamos funciones, oportunidades, mejoramos los servicios
• en casos raros, por experiencia, generalmente no antes de algunos años, algunos de los servicios que ya tienen una funcionalidad estable se reescriben en C / C ++ / Java / Golang / Rust

Por lo tanto, es mejor comenzar, por lo general, con secuencias de comandos, comenzar una batalla, y luego, si lo necesita directamente, necesita recoger otras herramientas y esto funciona, generalmente de manera muy suave y sin riesgos.

Programación funcional, Lisp, Haskell, F #

Muchos, durante toda la carrera de desarrollador, nunca vienen aquí, sino en vano. Es extremadamente útil entender por qué apareció la FP (programación funcional) y por qué en algunas áreas es tan popular.

Lo explicaré simplemente. Hay un problema tan insoluble en matemáticas como el "problema de detención" . Si lo pone en palabras muy simples y bastante no estrictas, pero está claro, entonces no puede encontrar un algoritmo que pruebe que el programa funcionará sin errores. Por qué Porque inicialmente, la gente comenzó a programar de manera agresiva e imperativa, usando:

• variables mutables
• ciclos con condiciones
• efectos secundarios

Y comenzaron a cometer errores. Ahora vemos esto, observando una gran cantidad de errores tanto en la web como en aplicaciones de escritorio y móviles. Y no importa cómo cubra el código con pruebas automáticas, los errores continúan goteando, dispersándose por el piso y riéndose.
Para detener esta pesadilla de la aparición de errores y software despiadado, a finales de los años 50, apareció una dirección de programación funcional y el lenguaje Lisp . Ahora esta familia de idiomas representa, más o menos adecuadamente, Haskell .

A pesar de que una gran cantidad de posibles errores en el código se eliminan realmente debido a:

• tipos de datos algebraicos y coincidencia de patrones en ellos
• la ausencia de ciclos (solo a través de la recursividad) y variables mutables dentro del alcance de un brazo extendido (por supuesto, se pueden encontrar muletas para evitar esto)
• escritura estática muy estricta y, al mismo tiempo, salida automática muy conveniente de los tipos Hindley-Milner
• características muy potentes, con la división en "puro" y "con efectos secundarios", con posibilidad de uso parcial
• soporte seguro de programación concurrente
• soporte para combinadores a través de mónadas para todas las ocasiones (más sobre eso en la sección Rust)

Haskell «» — , , , : . Haskell «», , , , . Haskell .

, , — Haskell , , , Java/C#.

, . Haskell , , , , . , «» — Haskell .

«C/C++» — Golang, D

, , C/C++ (, Forth). C++ , , D ( — , ).

, - /C++ c RAII , . 2009 Google Golang .
, Golang , , , . Golang Java/C# ( ) , … , Golang:

• «green threads» ( ), python
• , , (, Docker ) :-)

. Node.js python .

, Golang , Google vs Sun/Oracle, , , , :-) , « Java/C#» , — . Docker Golang . Golang — Java/C#, , .


, , Swift , c « » . macOS.

— Rust!

, , 40-50 , , , «zero-cost» , , - - :-) , , (Java/C#), , (C/C++), -, — . , ?

— . , , , 50 , 2010 Mozilla Research. , :

• «zero-cost» ( C/C++ ), .. , , ------ « » (, , )
• cargo ,
• (* — ): , — « », , , ,
• , , ( , , GC , - runtime, )
• -, Null (!),
• Haskell pattern-matching , Enumeration (Golang, , )
• ( Java, )
• ( Golang — ; Java/C#/Erlang .. , )
• , ( C/C++)

, , -. ? ! , 50 . , , «» , , .

Rust «» , , Haskell .
Rust , , , Java :-) — Nulls, pattern-matching , generics traits . . , , , « Haskell», .

.

?

! , «» («ownership») . « » ( «lifetime», Rust book, ), ( , ).
/, . /, .
C++, - move-. , rust , .

zero-cost ?

, traits, . , , Golang. , , - pattern-matching, ( Golang, ). / . : . («borrowing»). , ( «read-write locks», ). , , , , .
slice , , , . — « » , , ; , .

:

• ,
• ( , )
• , ---,
• , , ,

, ( , ) … . / , C/C++ . .

, - , - . - , . Sync/Send, , : , , , .

, , 1-2 futures . , Node.js python async/await, , . , ?

unit

, unit . .

— cargo

Java, «Maven cargo » , : , . , , , .

Heap

, , heap. , , ( ) « » ( «lifetime»). , ( Swift). , — , heap . — , .

, , , . , (2 ) , , , , , AmazonWebServices c tls/ssl, .
, , , , , - . « » ( «lifetimes») .
, . IntelliJ rust , . Notepad++ — .

Rust

• Comprenda que realmente necesita escribir código de sistema muy rápido, trabajando bajo cargas elevadas y consumiendo un mínimo de recursos y sin ningún gasto adicional, como un recolector de basura. De lo contrario, escriba un script en python / PHP / Node.js y vuelva a la tarea después de 2-3 años (en el 97% de los casos no tiene que regresar).
• No tengas miedo a Rust. El punto culminante principal del lenguaje es un compilador muy inteligente y matemáticamente riguroso que NO FALTARÁ el código peligroso e incorrecto. Por prueba y error, evitando esquinas agudas, aprenderá a programar usando el compilador de forma estricta y segura :-)
• Comience a aprender el idioma con un " libro de óxido ". Un libro hermoso y sexy que es fácil de leer y divertido de leer. Pero es mejor leerlo 2 veces, "resolviendo" todos los ejemplos.
• El " libro de cocina Rust " ayuda mucho . También es deseable "resolverlo" y ver cómo funciona el código, para sentirlo.
• Existe literatura sobre Rust para usuarios avanzados, como Rustonimicon , pero no recomiendo molestarse innecesariamente con cosas técnicas realmente complicadas.

Comprenda una vez más: para dominar la tecnología, debe comenzar a escribir código útil para la empresa. El compilador Rust es tan inteligente que ofrece garantías (de hecho, es muy importante, el compilador C ++ no sabe cómo hacer esto) y no compila código peligroso / dañado por la memoria, así que experimenta todo lo que quieras, y obtendrás el código de forma rápida y segura, y aún mejor comenzarás a programar: )

Detalles de implementación del proyecto

Revelaré un pequeño detalle del proyecto. Amazon SQS derrama cientos de paquetes de datos por segundo. La cola es leída, analizada localmente por los trabajadores, cada mensaje es procesado por el intermediario y redirigido a otro servidor externo. Hay varios servidores externos. Inicialmente, la solución se implementó a través de secuencias de comandos: la secuencia de comandos, iniciar un proceso en el sistema operativo, leer mensajes, procesados ​​y enviados a través de la red. En varios servidores de hierro potentes (8 núcleos, 16 GB de RAM), se lanzaron cientos de scripts (¡en cada uno!), Leyendo simultáneamente de SQS, procesando y enviando datos. Simple, confiable, pero la ingesta de hierro comenzó a molestar. El costo del hierro aumentaba constantemente.

Rust utiliza principalmente bibliotecas y módulos estándar de carga:

• rusoto_sqs: para trabajar con Amazon Web Services, sin preguntas, funciona según sea necesario de inmediato
• rustls - para tls, incl. interacciones con los servicios TLS de Google, Apple y el uso de certificados de clientes
• enlace de señal: para interceptar kill y llevar al final de la transacción para enviar datos
• futuros, tokio-rustls: trabajo asincrónico, "diferido", multiproceso, con sockets TLS de red, ala Node.js
• clap - análisis de argumentos de línea de comando
• serde_json - formación json, nada interesante aquí

Desafortunadamente, no fue sin usar bloques "inseguros" y "std :: mem :: transmute": la biblioteca estándar no pudo encontrar herramientas para analizar datos binarios en árboles.

El principal, si puede llamarlo así, "enchufar" ocurrió en la compilación: las bibliotecas no se compilaron en CentOS6 debido al "ensamblador desactualizado" en binutils, pero no hubo problemas en CentOS7.

La impresión general es que el desarrollo en Rust se asemeja, más bien, a "secuencias de comandos estrictas" en lugar de a la programación del sistema, no mucho más que las secuencias de comandos o el desarrollo web, tanto en términos de recursos como de pruebas. En este caso, una compilación estática estricta, la ausencia de un recolector de basura y tipos de datos algebraicamente.

El sentimiento general es muy positivo. Aún así, en lugar de varios servidores de hierro (8 núcleos, 16 GB de RAM), el problema comenzó a resolverse mediante un proceso (con docenas de hilos) que no come más de 5 GB de RAM y crea una carga no muy notable en los núcleos, con tráfico en la región de 0.5-1 gigabits .

Conclusión

Bueno, eso terminó una publicación larga, pero, con suerte, inspiradora y útil sobre tecnología efectiva. Ahora conoce otra herramienta y puede usarla con mayor seguridad si es necesario. Revisamos la historia del desarrollo de lenguajes de programación, sus capacidades y características, y podemos haber sacado o sacaremos las conclusiones correctas. ¡Buena suerte con tus proyectos y bueno, no, buen humor!

PD:
* - Sí, casi lo olvido. Por supuesto, debe hablar sobre el bloqueo inseguro. En este bloque puedes:

• para programar cosas que no están disponibles en punteros ordinarios "sin referencia a la oxidación" y hacer algunas cosas potencialmente más peligrosas, a veces requeridas en la programación del sistema. Pero no todo es tan aterrador:
• los bloques inseguros son visibles y no hay ninguno, o el código responsable se concentra en ellos
• La biblioteca estándar de óxido se prueba exhaustivamente, lo que significa que creemos que los bloques inseguros funcionan en ella.
• Las bibliotecas populares en carga también se prueban a fondo (todo está integrado para pruebas de unidad e integración en óxido) y, por lo tanto, se pueden tomar y usar de forma segura

Es decir en el bloque "inseguro" no puede participar en libertinaje arbitrario, disponible en C, pero solo con ciertos tipos estrictamente ciertos de actividades peligrosas. Por lo tanto, puedes y debes dormir tranquilo :-)