Según lo solicitado, aquí están mis sugerencias para desarrollar Rust en 2019 en adelante.

Debo decir que solo hablo por mí mismo, y ni siquiera soy un participante muy activo en el proyecto. Además, estas propuestas se refieren en gran medida a muchos proyectos. El óxido es un caso especial, pero es él quien ahora conduce a algunos pensamientos.

También debo señalar que, en general, estoy satisfecho con el desarrollo de Rust, y esta propuesta se hace solo en aras de mantener una mayor prosperidad, a fin de evitar algunos de los problemas que ahora observo desde el exterior.

TL; DR: Es importante reconocer el problema y planificar mecanismos explícitos para limitar el crecimiento de dos cosas:

1. Artefactos técnicos generales obligatorios, especialmente la definición misma de un lenguaje.
2. La carga sobre las personas involucradas en la discusión de estos artefactos.

En particular, quiero llamar la atención sobre la imposibilidad e indeseabilidad del crecimiento ilimitado en ambas direcciones. Hay límites naturales. Como en todos los sistemas naturales que han alcanzado los límites del crecimiento, es mejor prepararse para este evento y llevarlo a cabo de manera controlada y planificada.

Tenga en cuenta que no estoy escribiendo sobre los límites de crecimiento de muchas otras áreas. Por ejemplo, un índice de paquete, el tamaño del sitio o incluso una comunidad de usuarios. No está claro qué tipo de amenaza representa esto para Rust, por lo que solo estamos hablando de dos problemas específicos anteriores.

Factores limitantes y fuga

Todo sistema natural tiene límites para el crecimiento. Es por eso que el Universo no es (por ejemplo) una sola ameba que se expande a la velocidad de la luz. El sistema crece (¡y a menudo la velocidad de expansión también crece!) Hasta que encuentra factores limitantes, y luego gradualmente el crecimiento se ralentiza hasta que el tamaño total del sistema alcanza una meseta. Los patrones de crecimiento típicos en este caso se parecen aproximadamente a una sigmoidea o una "curva en forma de S", acercándose gradualmente a una asíntota. Al menos si los factores limitantes ocurren gradualmente y de manera controlada.



Cuando un sistema encuentra un límite de manera incontrolada o repentina , puede ocurrir un fenómeno que se parece más a un vuelo de un objetivo o incluso a un retorno: el límite aún existe, pero su efecto se siente más como un colapso o una crisis. La curva S se eleva a un pico, seguido de un colapso. Me gustaría evitar esto.

Buenos ejemplos de control

El proyecto Rust tiene varias formas de control de procesos que esencialmente limitan la tasa de cambio y / o crecimiento. Creo que estas medidas son muy razonables: en parte gracias a ellas, el proyecto aún tiene éxito. Por analogía con ellos, quiero formular las siguientes recomendaciones. Formas actuales de gestión:

• La cola Bors omite los cambios de corrección para el programa.
• El cráter omite las versiones de corrección del ecosistema.
• Se prefiere que las versiones planificadas se publiquen a tiempo, incluso si la función planificada no está lista. La decisión se toma a tiempo y todo lo que no está preparado se corta.

Además, se han creado importantes estructuras sociales dentro del proyecto para limitar el número de participantes del proyecto.

• Código de conducta No todos lo recuerdan, pero él no solo postula la justicia social, etc. También establece límites en la relación señal-ruido en las conversaciones, la explotación de la atención y el tiempo de otra persona, y presiona por compromisos (después de todo, no todas las soluciones dan una cantidad cero).
• Proceso de RFC . Reglas sobre la forma, contenido, tiempo, reclutamiento de participantes, formas de discurso permitidas y esperadas cuando se discuten cambios significativos.
• Modelo de gestión . Delimitación de responsabilidades, delegación jerárquica, cuando sea necesario, roles y expectativas de los participantes, etc.

Todo esto, en esencia, es el reconocimiento de que en ausencia de problemas de control y crisis pueden ocurrir: al menos caos y disfunciones en cierta medida. Si es posible, el control es automático y completamente imparcial (para minimizar la mala voluntad y la evaluación subjetiva, la tentación de cortar atajos, etc.) Si no se puede evitar la subjetividad, al menos las reglas y los procesos se formulan claramente por escrito, en lugares bien documentados y conocidos. .

Áreas problemáticas

Volvamos a dos áreas problemáticas en las que el proyecto actualmente no cuenta con mecanismos o políticas adecuadas para controlar el óxido, lo que conlleva el riesgo de una posible disfunción o incluso una crisis. En ambos casos, no está del todo claro qué tan lejos está ahora el proyecto de tal crisis. Pero en cualquier caso, es mejor actuar con anticipación que llegar tarde.

1. El lenguaje en sí . Su definición Esto (a diferencia de muchas partes del proyecto) es un artefacto técnico común obligatorio . Todos están interesados ​​en él, y cada cambio potencialmente afecta a todos. Además, todos deberían estudiar y comprender su parte esencial: es imposible ignorar las partes poco interesantes. Incluso lo que desea ignorar existe en un contexto general: documentación y materiales de capacitación, ejemplos de prueba y material de prueba, componentes internos del compilador, modelos formales, bases de códigos, carga de mantenimiento general, etc.
   
   Aquí el crecimiento del lenguaje como artefacto está limitado por al menos los siguientes factores:
   
   
   • Una oportunidad para que un principiante aprenda un idioma.
   • La capacidad del usuario promedio para sentirse seguro, adaptarse a las bases de código de otras personas.
   • La capacidad de un experto o mantenedor para conocer todos (o la mayoría) de los cambios.
   • La relación de costos y beneficios de cada nuevo cambio en términos de trabajo nuevo y en curso. El número de personas o casos de uso que se benefician de él. Los costos son combinatorios en muchas dimensiones de diseño y tamaño del lenguaje. Casi siempre aumentan.
   
   Si no cumple con estos límites, puede enfrentar riesgos muy graves:
   
   
   • Cambios de idioma irrazonables, hasta la imposibilidad de mantener garantías de seguridad críticas.
   • Reputación de excesiva complejidad, pérdida de usuarios. Riesgo de convertirse en el próximo C ++ o Haskell.
   • Funciones de baja calidad con definición incompleta, pruebas, documentación.
   • Funciones subutilizadas que requieren el esfuerzo necesario en otros lugares.
   • Aplastamiento en dialectos, programas aislados, reducción de valor.
2. La carga sobre las personas que trabajan en el idioma. Algunas partes del proyecto pueden delegarse, distribuirse entre todos los desarrolladores disponibles. Estos no son artefactos técnicos comunes. Hasta cierto punto, muchas personas (y cada vez más) tienen que participar en casi todos los cambios. Esto significa mucha presión sobre todos en este grupo: deben seguir todas las discusiones, y la cantidad de cambios y la cantidad de participantes en las discusiones están creciendo.
   
   Algunas restricciones sobre el crecimiento de esta carga para los participantes del proyecto:
   
   
   • El número de horas por día.
   • El número de horas pagas por día.
   • Responsabilidad e intereses fuera del proyecto.
   • Una reserva de energía mental para entender lo que está sucediendo.
   • Confianza en la opinión de todos los involucrados en la conversación.
   • Una reserva de energía psicológica y emocional para la lectura y la discusión.
   • Presunción de buena fe de todos los involucrados en la conversación.
   
   Los riesgos de exceder estos límites también son potencialmente muy graves:
   
   
   • Malas decisiones tomadas debido al agotamiento o al agotamiento.
   • Desigualdad creciente: solo los participantes más privilegiados, asequibles, enérgicos, bien pagados o bien organizados pueden realizar un seguimiento de todo.
   • Reduciendo el discurso: de una cuidadosa consideración a "ganar una disputa".
   • La gente pierde el tiempo, se quema, se porta mal, abandona el proyecto.
   • Decepción, acusación de deshonestidad, resentimiento, pensamiento conspirador, tenedores.
   
   Quiero enfatizar que las limitaciones y los riesgos descritos no son completamente específicos para personas específicas o incluso para el proyecto Rust en su conjunto. En mayor o menor grado, se encuentran en cualquier lugar. Simplemente reemplazar los mantenedores actuales (por ejemplo) con los que te gustan realmente no resolverá el problema: las restricciones permanecerán. La única solución es una gestión reflexiva en caso de colisión con un límite. Toma el control.

Posibles opciones de control

Esta es la parte difícil, donde trataré de evitar un lenguaje claro. Al final, es importante tomar el control del libre albedrío y no imponerlo desde el exterior. Creo que los participantes del proyecto deberían pausar, reflexionar, considerar colectivamente y establecer algunos controles. Por lo tanto, solo ofreceré varias opciones posibles, no muy estructuradas, pero con un espíritu festivo navideño: como un montón de regalos potencialmente interesantes para desenvolver, ver y decidir, salir o cambiar por algo más interesante.

1. Espacio definido negativamente . Tome el proceso de discutir funciones y conceptos de los planes para el desarrollo futuro del lenguaje. Permita (o aliente) RFC que digan "Rust nunca tendrá X" por algún valor de X. Por lo tanto, obtenemos una ronda única para una discusión justa y consideración de las objeciones al cambio a largo plazo (¡"nunca" es bastante tiempo!). Entonces esta discusión terminará para siempre. No se convertirá en una fuente eterna de conflicto prolongado. Algunos ejemplos donde se definen espacios negativos:
   
   
   • eliminar permanentemente ciertas categorías de expresividad del sistema de tipos (por ejemplo, tipos dependientes, HKT, etc.);
   • de sintaxis (por ejemplo, claves de parámetros, argumentos posicionales o con nombre);
   • de un conjunto de vistas de elementos (por ejemplo, tipos de publicaciones anónimas);
   • desde un conjunto de obligaciones de salida hasta el extremo medio (por ejemplo, síntesis de constantes, argumentos implícitos).
   
   Establezca algunas restricciones estrictas: para evitar estos objetos, así como a las personas que establecen el objetivo de "hacer todo bien".
2. Los costos de desarrollo deben especificarse explícitamente. Tomando una página de la lista de cambios en WebAssembly, aclare que en una etapa temprana, tal RFC requerirá inversiones apropiadas en la implementación, formalización, revisión de documentación, revisión de materiales de capacitación, pruebas de escritura, mantenimiento, etc. Si los costos no pueden cubrirse, en esta etapa posponer los cambios "hasta que se encuentre un patrocinador".
3. Establezca metas para la velocidad de aprendizaje y el volumen de material . Intente trabajar en la dirección opuesta: proceda de la cantidad de tiempo y la cantidad de páginas necesarias para aprender el idioma o para convertirse en un experto en él, y luego elimine todo lo que vaya más allá de este marco. Si "aprender óxido en 21 días" no funciona, encuentre el intervalo correcto. Tres meses? Seis? Año? Piense en idiomas cuyo aprendizaje "definitivamente toma demasiado tiempo" y elija un número más bajo. ¿Está bien el manual de 1000 páginas? 500? 300?
4. Establezca otros límites automáticos : el número de líneas de código en el compilador, el tiempo de carga total, dólares por día para instancias de AWS, el número de reglas en la gramática, en el sistema de tipos, el porcentaje de cobertura de prueba, el porcentaje de documentos que se pueden marcar como "incompletos", etc. Sea creativo, descubra las cosas relevantes que se pueden medir y luego implemente mecanismos para limitarlas.
5. Límite de tiempo personal : cuántas horas aproximadamente (o tiempo pagado) una persona realmente puede dedicar a un proyecto sin agotamiento o agotamiento, incluidos los participantes con derechos mínimos. Establezca restricciones similares en grupos, lanzamientos individuales y planes de trabajo relacionados. Luego, elimine o posponga todo lo que no se ajuste al límite.
6. Permita que los moderadores establezcan límites en la frecuencia de las publicaciones o establezcan períodos de silencio en discusiones específicas. A veces, desde el exterior, parece que la discusión es demasiado candente. Para reducir el conflicto, es más fácil establecer un límite común que aplicar sanciones a los participantes individuales.
7. Al igual que con los moderadores: cree un equipo adicional entre proyectos que participe en la presupuestación y auditoría de los niveles de carga en otros equipos . Puede ser eficaz: el equipo de auditoría ayudará a las personas a decir que no cuando sea necesario y no aguantará, como lo hacen la mayoría de los miembros del equipo, aceptando demasiado.

Estas son solo algunas ideas en la dirección general de las restricciones de crecimiento. Estoy seguro de que puede encontrar formas más realistas de controlar las restricciones sobre el tamaño del idioma y las cargas personales. Con los años, la comunidad Rust ha demostrado ser deliciosamente creativa, mental y autocrítica. Deberías ser alabado por esto. Espero que este artículo sea aceptado con el mismo espíritu de crítica constructiva.

Feliz año nuevo y buena suerte!