¿Qué es la oscuridad?

Dark es un lenguaje de programación holístico, editor estructurado e infraestructura, para construir servicios web backend. Está dirigido a ingenieros frontend, backend y móviles.

Nuestro objetivo es hacer que la codificación sea 100 veces más fácil, lo que creemos permitirá que miles de millones de personas creen software. Este es un gran desafío, que requiere un replanteamiento significativo de cómo escribimos el software.

Esta publicación es para hablar sobre cómo pensamos sobre el mundo. Estamos presentando nuestra filosofía central, dirección de alto nivel y nuestros objetivos. Vamos a entrar en más detalles en publicaciones futuras (ver abajo; o recibir una notificación siguiendo a Dark o mediante la lista de correo).

Complejidad accidental

El principio definitorio detrás de Dark es que queremos eliminar toda la complejidad accidental de la codificación. La creación de aplicaciones hoy en día es increíblemente compleja, y gran parte de esa complejidad es accidental.

La frase "complejidad accidental" (o complejidad incidental) proviene de un ensayo llamado "No Silver Bullet". En él, Fred Brooks dividió la complejidad en "complejidad esencial", que es el núcleo del problema empresarial que está resolviendo, y "complejidad accidental", que es todo lo que tiene que hacer para crear software.

Señaló que para mejorar la productividad 10 veces, tenemos que eliminar el 90% de las cosas que hacemos. En ese momento, sintió que el desarrollo de software no era un 90% de complejidad accidental, por lo que no era posible una mejora de 10x. De ahí el nombre "No Silver Bullet".

Cuando miro alrededor del software hoy, el 90% parece una estimación baja. La cantidad de complejidad accidental está fuera de control. Mire "Es el futuro" y "Cómo se siente aprender JavaScript en 2016". ¿Por qué necesitamos saber cómo usar todas estas herramientas para escribir software?

Básicamente, escribir software es solo recibir datos, manipularlos, almacenarlos y enviarlos a algún lugar, conceptos fáciles que aprendemos en nuestros primeros tutoriales de programación. ¿Por qué es que para construir una aplicación hoy necesitamos aprender Kubernetes, Docker, Git, balanceadores de carga, docenas de servicios de AWS, SQL, NoSQL, Kafka, Unix, GraphQL, gRPC, npm, Heroku, DNS, memcached, JWT, Nginx , y el resto de la lista interminable de herramientas y tecnologías que cada una proporciona una parte de una aplicación?

La complejidad está fuera de control y no ha mostrado signos de desaceleración. Ya está en el punto en que los desarrolladores frontend sienten que no pueden escribir backends. Tienen que lidiar con tanta complejidad propia que no pueden encontrar espacio para la complejidad del backend. ¿Cómo dejamos que esto sucediera?

Un lenguaje holistico

El problema central aquí es que las herramientas que hemos estado construyendo, como industria, son incrementales. Esto es natural: crea una nueva herramienta para rascarse una picazón, resolver problemas conocidos, y lo hace de una manera que se puede adoptar junto a las herramientas existentes de los usuarios. "Hacer una cosa y hacerlo bien" es el núcleo de la filosofía de Unix que hemos seguido desde los años 70.

Aquí está la evolución de las herramientas comunes en nuestra industria:

  • RCS → CVS → Subversion → Git
  • Servidores → Cajas unix compartidas → Servidores privados virtuales → Heroku → Lambda o Kubernetes
  • Script de compilación nocturno → BuildBot → Jenkins → CircleCI
  • Ed → Vi → Vim → Atom / Sublime / VSCode / etc

Cada nueva herramienta mejora en la herramienta anterior, pero llena el mismo espacio sin eliminar conceptos y complejidad. De hecho, a menudo aumentan la complejidad: Git es una herramienta mejor que Subversion, pero Subversion era mucho más simple.

Complejidad decreciente

En lugar de construir una mejor versión de las cosas existentes, la forma de disminuir la complejidad es eliminar completamente las cosas.

Si creamos una herramienta que hace dos cosas, elimina no solo la interfaz, sino que también reduce la superficie de ambos problemas. Si juntamos cuatro u ocho herramientas, podemos eliminar grandes extensiones de complejidad, interconexión y superposición entre las herramientas.

Dark es holístico: combina un editor con un lenguaje y una infraestructura. No es un lenguaje de propósito general, ni un editor de propósito general, ni una infraestructura de propósito general. Cada pieza está diseñada específicamente para trabajar con las otras piezas, y esta estrecha integración nos permite eliminar gran parte de esa complejidad:

  • Complejidad de infraestructura
  • Complejidad de implementación
  • Complejidad API
  • Complejidad de código como texto

Complejidad de infraestructura

La complejidad de la infraestructura es todo lo que implica trabajar con las máquinas en las que ejecutamos nuestro código, en lugar de solo trabajar con datos y clientes. Esto incluye Docker y Kubernetes, EC2 y todo el ecosistema AWS / GCP / Azure, que trata con colas, redes, cortafuegos, equilibradores de carga, descubrimiento de servicios, escalado, monitoreo, seguridad, bases de datos, fragmentación y optimización.

En Dark corremos la infraestructura para ti. Debido a que entendemos profundamente su aplicación (código, tráfico y datos), podemos tomar buenas decisiones sobre la arquitectura que necesita. Como tal, podemos eliminar todas las opciones de infraestructura: no necesita manejar máquinas, orquestación, almacenamiento, bases de datos o colas.

Además, deberíamos poder tomar grandes decisiones de escala automáticamente: pensamos en Dark como un compilador de infraestructura, compilando el sistema distribuido ideal para su aplicación. Esperamos poder abstraer y simplificar de maneras que Lambda, Kubernetes o Heroku no pueden.

Tomar bases de datos por ejemplo. Hoy en día, una aplicación y su base de datos deben ser administradas cuidadosamente juntas, a pesar de ser completamente diferentes en términos de preocupaciones operativas, idiomas, formatos y conjuntos de habilidades del operador. La combinación de una base de datos con su aplicación elimina muchas preguntas que ninguno de los componentes puede responder por sí solo, como qué índices se necesitan, cómo particionar, la mejor manera de escribir consultas y cómo administrar migraciones de datos de larga duración.

Del mismo modo, la interfaz con una base de datos desde una aplicación es compleja: necesito pensar si los tipos se alinean, cómo podría fallar mi ORM, cómo se escalará, qué índices necesita. ¿Por qué no puedo simplemente almacenar datos, consultar datos y acceder a datos cuando los necesito?

La estrecha integración del lenguaje, el editor y la infraestructura también nos permite proporcionar observabilidad en sus sistemas de producción en vivo directamente desde el editor Dark, que cambia por completo la forma en que las personas codifican y crean sistemas. También elimina la necesidad de monitoreo, rastreo, instrumentación, registro y manejo de errores por separado.

Complejidad de implementación

La complejidad de la implementación es el problema de sincronizar el código terminado de una máquina a otra. Esta es una de esas cosas que deberían ser triviales, pero hacerlo de manera segura y rápida causa tantos problemas que construí CircleCI para ayudar a resolverlo.

Las empresas dedican recursos masivos para reducir el tiempo de envío de un cambio a los clientes. Pero el acto del código de envío implica los pasos necesarios que llevan tiempo. Código de empaque (contenedor Docker, tarball, paquete web, AMI, git checkout, frascos), probándolo (CircleCI, cobertura de código, prueba de navegador / Selenium), sincronizándolo (git push a Heroku, registros Docker, alojamiento de artefactos, S3, CDN) , habilitar el nuevo código (Kubernetes, servidores proxy inversos, Capistrano, intercambio de enlaces simbólicos) y desplegarlo (banderas de características, despliegues azul-verde, migraciones de DB, versiones de API), implica no solo complejidad y herramientas masivas, sino también paredes inevitables Hora del reloj.

En Dark, rediseñamos el proceso de implementación para no requerir estos pasos. En cambio, la implementación es trivial. Tan pronto como escriba el código en el editor Dark, se implementará inmediatamente en producción, listo para habilitarse con un indicador de función. No hay un largo proceso de construcción, ni tarballs, ni contenedores. Es una diferencia simple de su editor a nuestra infraestructura.

Dark está diseñado para hacer que este proceso sea seguro. Las rutas, las API y las colas están todas escritas estáticamente, y cada función y tipo tiene versiones e inmutables. Las funciones de seguridad de implementación, como indicadores de características, pruebas unitarias y potentes migraciones de bases de datos, están integradas en las herramientas, el lenguaje y el editor. Aunque un despliegue toma solo ~ 50 ms, los despliegues son significativamente menos riesgosos en Dark que en cadenas de herramientas modernas.

Complejidad API

La complejidad de la API proviene de lo difícil que es usar una API frente a llamar a una función. El uso de API debería ser tan fácil como llamar a una función, pero tenemos que lidiar con la autenticación, la limitación de velocidad, el manejo de errores y los reintentos. La forma de manejarlos es diferente en cada API, desde el tipo de autenticación hasta el protocolo (HTTP + JSON / REST / Protobuf / gRPC / GraphQL / SOAP) y las convenciones de llamadas, y hay millones de API en el mundo para tratar (y cada vez más )

En Dark, hacer una llamada API es tan simple como una llamada de función. Nuestras herramientas para crear conectores para servicios de terceros manejan la limitación de velocidad, autenticación, manejo de errores y reintentos, con un excelente comportamiento predeterminado. La visibilidad de los costos y las fallas está integrada en el editor, al igual que el soporte para claves secretas e información de identificación personal.

Complejidad de código como texto

La complejidad del código como texto es un poco difícil de entender. Se refiere a todos los problemas diversos que tenemos en torno a cómo escribimos el código y las herramientas que lo rodean.

Un ejemplo obvio son los errores de sintaxis. Los errores de sintaxis existen porque escribimos código como texto y luego le pedimos al compilador que lo lea, lo que a veces no puede. Para nunca volver a tener un error de sintaxis, debemos tener un editor que no permita que se agreguen, uno que hable el idioma, no solo texto sin formato.

Este concepto puede extenderse a muchas partes de la cadena de herramientas. Cambiamos el nombre de las funciones con las funciones de búsqueda y reemplazo de nuestros editores, que no entienden la diferencia entre una función y una variable; Fusionamos ramas con Git, que no comprende la sintaxis o la semántica de nuestro código. Escribimos código en Python o Node o Rust, pero también tenemos que considerar un sistema operativo completo que se ejecuta debajo de él. Utilizamos docenas de herramientas basadas en texto que apenas entendemos, como git, bash, grep, sed, porque ninguna de nuestras herramientas realmente comprende nuestro código.

El lenguaje oscuro está construido de la mano con un editor estructurado y una infraestructura. Como tal, el autocompletado está al tanto de todo su programa, y ​​los errores de sintaxis no son posibles. Las herramientas de refactorización están integradas, al igual que los controles de colaboración y acceso. El control de versiones es de primera clase y está estrechamente integrado con el resto del lenguaje, incluidos los indicadores de características y el control de versiones de funciones y tipos.

¿Para quién estamos construyendo Dark?

A largo plazo, estamos construyendo Dark para todos: codificadores experimentados, nuevos codificadores y no codificadores, pero necesitamos comenzar más pequeños que eso. En este momento, estamos construyendo Dark para desarrolladores existentes que desean construir backends, apuntando a dos áreas principales.

El primero es backends para aplicaciones cliente, como aplicaciones móviles, o aplicaciones web de una sola página escritas en React, Vue, Angular, etc. Si usted es un desarrollador frontend / móvil que no está satisfecho con lo difícil que es hacer un backend probablemente te gustará Dark.

El segundo es construir nuevos servicios en arquitecturas existentes basadas en microservicios. Crear un nuevo servicio significa suscribirse a un futuro de archivos yaml, canalizaciones de implementación, páginas de 2 am, alertas de seguridad de día cero y mantenimiento eterno. Si está buscando nuevos idiomas y herramientas (como Lambda) para reducir esta carga, Dark debería ayudar. Para eso está diseñado Dark, lo que le permite crear servicios de backend con escasa y mínima sobrecarga de mantenimiento.

Naturalmente, los desarrolladores que realizan nuevas empresas web o proyectos paralelos también deberían pasar un buen rato con Dark. Por otro lado, si está creando cosas como sistemas integrados, demostradores de teoremas o modelos de aprendizaje automático, Dark no admitirá este tipo de aplicación durante muchos años.

Dark tiene la misión de llevar la codificación a mil millones de personas. Creemos que debemos comenzar con los desarrolladores existentes y expandirnos: si hacemos que la codificación para desarrolladores existentes sea 100 veces más fácil, entonces reducimos significativamente la barrera de entrada para todos los que están tratando de aprender a codificar, o las personas en "codificación adyacente" empleos, como diseñadores, PM, analistas y trabajadores de la información en general.

Aprende más sobre Dark

Esta ha sido una introducción a cómo pensamos sobre el mundo con Dark. Planeamos lanzar muchos más detalles y planes en los próximos meses a medida que nos acerquemos a un lanzamiento público. Aquí hay algunas publicaciones en las que estamos trabajando:

  • "El problema con el texto"
  • "¿Cómo se volvió el mundo tan complejo?" (Monolitos de Rails versus microservicios)
  • "Las desventajas de Dark: código abierto, alojamiento propio y posible bloqueo"
  • "Cosas como y a diferencia de Dark" (comparación con conceptos similares como el trabajo de Eve, Glitch, Smalltalk o Bret Victor)
  • Cómo se despliega Dark en 50 ms
  • "No inventes nada nuevo" e "Innova en los límites"
  • "Implícito vs explícito en la oscuridad" (tipo dinámico vs estático)
  • Problemas reales con lenguajes funcionales
  • "¿Por qué Dark no es Low Code o No Code?"
  • "Diseño de un tipo de cadena para un mundo Unicode"
  • "Una retrospectiva sobre nuestros experimentos con un lenguaje basado en gráficos"
  • "¿Por qué hacer nuestro propio idioma?"

Si hay una que le gustaría que prioricemos, o cualquier pregunta sobre Dark, dígale hola en Twitter. También debe unirse a nuestra versión beta y seguirnos en Twitter o Medium o vía RSS, o seguirme a mí o a Ellen en Twitter.

Gracias a Corey Montella, Dan Bentley, Evan Conrad, Geoffrey Litt, James Tamplin, Jeff Dickey, Jennifer Wei, Justin Poirier, Mike Plotz, Paul Stefan Ort, Ramin Keene, Russell Smith, Steve Krouse y Vaibhav Sagar por revisar los borradores de esta publicación. .