Wat is donker?

Dark is een holistische programmeertaal, gestructureerde editor en infrastructuur voor het bouwen van backend-webservices. Het is gericht op frontend, backend en mobiele ingenieurs.

Ons doel is om codering 100x eenvoudiger te maken, waarvan we geloven dat een miljard mensen hiermee software kunnen bouwen. Dit is een enorme uitdaging, die een belangrijke heroverweging vereist van hoe we software schrijven.

Dit bericht gaat over hoe we over de wereld denken. We introduceren onze kernfilosofie, richting op hoog niveau en onze doelen. We gaan op meer details in toekomstige berichten ingaan (zie onderaan; of ontvang een melding door Dark te volgen of via de mailinglijst).

Accidentele complexiteit

Het bepalende principe achter Dark is dat we alle toevallige complexiteit uit de codering willen verwijderen. Het vandaag bouwen van applicaties is ongelooflijk complex, en veel van die complexiteit is toevallig.

De uitdrukking "accidentele complexiteit" (of incidentele complexiteit) komt uit een essay genaamd "No Silver Bullet". Daarin verdeelde Fred Brooks complexiteit in "essentiële complexiteit", wat de kern is van het zakelijke probleem dat u oplost, en "toevallige complexiteit", wat al het andere is dat u hoeft te doen om software te maken.

Hij wees erop dat we om de productiviteit 10x te verbeteren, 90% van de dingen die we doen moeten verwijderen. Destijds was hij van mening dat softwareontwikkeling niet per ongeluk een complexiteit van 90% had, en dus was geen verbetering met 10x mogelijk. Vandaar de naam "No Silver Bullet".

Als ik vandaag rond software kijk, lijkt 90% een lage schatting. De hoeveelheid onbedoelde complexiteit is uit de hand gelopen. Kijk naar "Het is de toekomst" en "Hoe het voelt om JavaScript te leren in 2016". Waarom moeten we weten hoe we al deze tools kunnen gebruiken om software te schrijven?

In essentie is het schrijven van software gewoon gegevens ontvangen, manipuleren, opslaan en ergens naartoe sturen - eenvoudige concepten die we leren in onze eerste programmeer tutorials. Waarom moeten we vandaag om een ​​applicatie te bouwen Kubernetes, Docker, Git, load balancers, tientallen AWS-services, SQL, NoSQL, Kafka, Unix, GraphQL, gRPC, npm, Heroku, DNS, memcached, JWT, Nginx leren , en de rest van de eindeloze lijst met tools en technologieën die elk een deel van een applicatie bieden?

De complexiteit is uit de hand gelopen en er zijn geen tekenen van vertraging gebleken. Het is al op het punt waar frontend-ontwikkelaars het gevoel hebben dat ze geen backends kunnen schrijven. Ze hebben zoveel eigen complexiteit dat ze geen ruimte kunnen vinden voor de complexiteit van de backend. Hoe hebben we dit laten gebeuren?

Een holistische taal

Het kernprobleem hier is dat de tools die we hebben gebouwd - als industrie - incrementeel zijn. Dit is natuurlijk: je bouwt een nieuwe tool om jeuk te krabben, bekende problemen op te lossen, en je doet het op een manier die kan worden gebruikt naast de bestaande tools van gebruikers. "Doe één ding en doe het goed" is de kern van de Unix-filosofie die we sinds de jaren 70 volgen.

Hier is de evolutie van algemene tools in onze branche:

  • RCS → CVS → Subversion → Git
  • Servers → Gedeelde unix-boxen → Virtual-private servers → Heroku → Lambda of Kubernetes
  • Nightly build script → BuildBot → Jenkins → CircleCI
  • Ed → Vi → Vim → Atom / Sublime / VSCode / etc

Elke nieuwe tool verbetert de vorige tool, maar vult dezelfde ruimte zonder concepten en complexiteit te verwijderen. In feite verhogen ze vaak de complexiteit: Git is een beter hulpmiddel dan Subversion, maar Subversion was een stuk eenvoudiger.

Afnemende complexiteit

In plaats van een betere versie van bestaande dingen te bouwen, is de manier om de complexiteit te verminderen, om dingen volledig te verwijderen.

Als we een tool bouwen die twee dingen doet, verwijdert deze niet alleen de interface, maar verkleint ook de oppervlakte van beide problemen. Als we vier of acht tools samenbrengen, kunnen we enorme complexiteit, interfacing en overlapping tussen de tools elimineren.

Dark is holistisch: het combineert een editor met een taal en infrastructuur. Het is geen algemene taal, geen algemene editor of algemene infrastructuur. Elk stuk is specifiek ontworpen om met de andere stukken te werken, en deze nauwe integratie stelt ons in staat veel van die complexiteit weg te nemen:

  • Complexiteit van infrastructuur
  • Implementatie complexiteit
  • API-complexiteit
  • Code-als-tekst complexiteit

Complexiteit van infrastructuur

Complexiteit van de infrastructuur is alles wat te maken heeft met het werken met de machines waarop we onze code uitvoeren, in tegenstelling tot alleen het werken met gegevens en klanten. Dit omvat Docker en Kubernetes, EC2 en het gehele AWS / GCP / Azure-ecosysteem, omgaan met wachtrijen, netwerken, firewalls, load balancers, service discovery, schaling, monitoring, beveiliging, DB's, sharding en optimalisatie.

In Dark beheren we de infrastructuur voor u. Omdat we uw toepassing - code, verkeer en gegevens - diepgaand begrijpen, kunnen we goede beslissingen nemen over de architectuur die u nodig hebt. Als zodanig kunnen we alle infrastructuurkeuzes weglaten: u hoeft geen machines, orkestratie, opslag, databases of wachtrijen aan te pakken.

Bovendien moeten we automatisch grote schaalbeslissingen kunnen nemen - we beschouwen Dark als een infrastructuurcompiler die het ideale gedistribueerde systeem voor uw toepassing compileert. We verwachten te kunnen abstracten en vereenvoudigen op manieren die Lambda, Kubernetes of Heroku niet kunnen.

Neem bijvoorbeeld databases. Tegenwoordig moeten een applicatie en de database zorgvuldig samen worden beheerd, ondanks dat ze volledig verschillen in operationele problemen, talen, formaten en vaardigheden van operators. Het combineren van een database met de toepassing ervan verwijdert veel vragen die geen van beide componenten op zichzelf kan beantwoorden, zoals welke indexen nodig zijn, hoe te scherpen, de beste manier om query's te schrijven en hoe langlopende gegevensmigraties te beheren.

Evenzo is de interface met een database vanuit een applicatie complex: ik moet nadenken over de vraag of de typen in een rij staan, hoe mijn ORM zou kunnen mislukken, hoe het zal schalen, welke indexen het nodig heeft. Waarom kan ik niet gewoon gegevens opslaan, gegevens opvragen en toegang krijgen tot gegevens wanneer ik deze nodig heb?

De nauwe integratie van taal, editor en infrastructuur stelt ons ook in staat om observatie in uw live productiesystemen te bieden, rechtstreeks vanuit de Dark-editor, die de manier waarop mensen code coderen en bouwen volledig verandert. Het elimineert ook de noodzaak voor afzonderlijke monitoring, tracing, instrumentatie, logging en foutafhandeling.

Implementatie complexiteit

Implementatiecomplexiteit is het probleem van het synchroniseren van voltooide code van de ene machine naar de andere. Dit is een van de dingen die triviaal moeten zijn, maar het veilig en snel doen veroorzaakt zoveel problemen dat ik CircleCI heb gebouwd om het op te lossen.

Bedrijven zetten enorme middelen in om de end-to-end tijd van het verzenden van een wijziging naar klanten te verminderen. Maar de handeling van de verzendcode omvat noodzakelijke stappen die tijd kosten. Code van de verpakking (Docker-container, tarball, webpack, AMI, git-checkout, potten), testen (CircleCI, codedekking, browsertesten / Selenium), synchroniseren (git push naar Heroku, Docker-registers, artefacthosting, S3, CDN's) , het inschakelen van de nieuwe code (Kubernetes, reverse proxy's, Capistrano, swapping symlinks) en het uitrollen (kenmerkvlaggen, blauwgroene implementeert, DB-migraties, API-versiebeheer), omvat niet alleen enorme complexiteit en tooling, maar ook onvermijdelijke wall- klok tijd.

In Dark hebben we het implementatieproces opnieuw ontworpen om deze stappen niet te vereisen. In plaats daarvan is implementatie triviaal. Zodra u code in de Dark-editor schrijft, wordt deze onmiddellijk in productie genomen, klaar om te worden ingeschakeld met een functievlag. Er is geen lang bouwproces, geen tarballs, geen containers. Het is een eenvoudig verschil tussen uw editor en onze infrastructuur.

Dark is ontworpen om dit proces veilig te maken. Routes, API's en wachtrijen zijn allemaal statisch getypt en elke functie en elk type heeft een versie en onveranderlijk. Implementatieveiligheidsfuncties, zoals functievlaggen, unit tests en krachtige database-migraties, zijn ingebouwd in de tooling, taal en editor. Hoewel een implementatie slechts ~ 50 ms duurt, zijn implementaties in Dark aanzienlijk minder riskant dan in moderne toolchains.

API-complexiteit

API-complexiteit komt van hoe moeilijker het is om een ​​API te gebruiken versus een functie aan te roepen. Het gebruik van API's zou ongeveer net zo eenvoudig moeten zijn als het aanroepen van een functie, maar we hebben te maken met authenticatie, snelheidsbeperking, foutafhandeling, nieuwe pogingen. De manier om hiermee om te gaan is in elke API anders, van het type authenticatie tot het protocol (HTTP + JSON / REST / Protobuf / gRPC / GraphQL / SOAP) tot het aanroepen van conventies, en er zijn miljoenen API's in de wereld om mee om te gaan (en groeit) ).

In Dark is een API-aanroep net zo eenvoudig als een functieaanroep. Onze tools voor het bouwen van connectoren voor services van derden verwerken snelheidsbeperking, authenticatie, foutafhandeling en nieuwe pogingen, met een uitstekend standaardgedrag. Zichtbaarheid rond kosten en fouten is ingebouwd in de editor, evenals ondersteuning voor geheime sleutels en persoonlijk identificeerbare informatie.

Code-als-tekst complexiteit

De complexiteit van code-als-tekst is een beetje een vangst. Het verwijst naar alle verschillende problemen die we hebben rond hoe we code schrijven en de tooling eromheen.

Een voor de hand liggend voorbeeld zijn syntaxisfouten. Er zijn syntaxisfouten omdat we code als tekst schrijven en de compiler vervolgens vragen deze te lezen, wat soms niet kan. Om nooit meer een syntaxisfout te hebben, hebben we een editor nodig waarmee ze niet kunnen worden toegevoegd - een die de taal spreekt, niet alleen gewone tekst.

Dit concept kan worden uitgebreid tot vele delen van de gereedschapsketen. We hernoemen functies met de zoek- en vervangfuncties van onze editors, die het verschil tussen een functie en een variabele niet begrijpen; we voegen branches samen met Git, die de syntaxis of semantiek van onze code niet begrijpt. We schrijven code in Python of Node of Rust, maar moeten ook rekening houden met een volledig besturingssysteem dat eronder draait. We gebruiken tientallen op tekst gebaseerde tools die we nauwelijks begrijpen, zoals git, bash, grep, sed - omdat geen van onze tools onze code echt begrijpt.

De donkere taal is hand in hand gebouwd met een gestructureerde editor en infrastructuur. Als zodanig is autocomplete op de hoogte van uw hele programma en zijn syntaxisfouten niet mogelijk. Refactoring-tools zijn ingebouwd, evenals samenwerking en toegangscontrole. Versiebeheer is eersteklas en nauw geïntegreerd met de rest van de taal, inclusief functievlaggen en versiebeheer van functies en typen.

Voor wie bouwen we Dark?

Op lange termijn bouwen we Dark voor iedereen - ervaren codeerders, nieuwe codeerders en niet-codeerders - maar we moeten kleiner beginnen dan dat. Op dit moment bouwen we Dark voor bestaande ontwikkelaars die backends willen bouwen, gericht op twee belangrijke gebieden.

De eerste is backends voor client-apps, zoals mobiele apps, of webpagina's met één pagina geschreven in React, Vue, Angular, etc. Als je een frontend / mobiele ontwikkelaar bent die niet tevreden is met hoe moeilijk het is om een ​​backend te maken, je zult waarschijnlijk Dark leuk vinden.

De tweede is het bouwen van nieuwe services in bestaande op microservices gebaseerde architecturen. Het bouwen van een nieuwe service betekent aanmelden voor een toekomst van yaml-bestanden, implementatiepijplijnen, 2am-pagina's, zero-day beveiligingswaarschuwingen en eeuwig onderhoud. Als je op zoek bent naar nieuwe talen en hulpmiddelen (zoals Lambda) om deze last te verminderen, zou Dark moeten helpen. Daar is Dark voor gebouwd, zodat u backend-services kunt bouwen met weinig tot geen schaal- en onderhoudskosten.

Natuurlijk moeten ontwikkelaars die gloednieuwe webstartups of nevenprojecten maken ook een geweldige tijd hebben met Dark. Aan de andere kant, als je dingen bouwt zoals ingebedde systemen, theorema-bewijzen of machine learning-modellen, ondersteunt Dark dit soort applicatie al vele jaren niet.

Dark heeft een missie om codering bij een miljard mensen te brengen. Onze overtuiging is dat we moeten beginnen met bestaande ontwikkelaars en uitbreiden: als we codering voor bestaande ontwikkelaars 100x eenvoudiger maken, dan verlagen we de toegangsdrempel voor iedereen die probeert te leren coderen, of mensen in 'coding-aangrenzend' aanzienlijk banen, zoals ontwerpers, PM's, analisten en informatiewerkers in het algemeen.

Meer informatie over Dark

Dit is een inleiding geweest op hoe we met Dark over de wereld denken. We zijn van plan om de komende maanden nog veel meer details en plannen uit te brengen naarmate we dichter bij een openbare release komen. Hier zijn enkele berichten waaraan we werken:

  • "Het probleem met tekst"
  • "Hoe is de wereld zo complex geworden?" (Rails monoliths vs microservices)
  • "De nadelen van Dark - open source, selfhosting en potentiële lock-in"
  • "Dingen zoals en in tegenstelling tot Dark" (vergelijking met vergelijkbare concepten zoals Eve, Glitch, Smalltalk of het werk van Bret Victor)
  • Hoe Dark wordt geïmplementeerd in 50 ms
  • "Doe niets nieuws uit" en "Innoveren op de grenzen"
  • 'Impliciet versus expliciet in donker' (dynamisch versus statisch typen)
  • Echte problemen met functionele talen
  • "Waarom Dark geen lage code of geen code is"
  • “Een stringtype ontwerpen voor een Unicode-wereld”
  • “Een terugblik op onze experimenten met een grafische taal”
  • "Waarom onze eigen taal maken?"

Als er een is waarvan je wilt dat we deze prioriteit geven, of als je vragen hebt over Dark, zeg dan hallo op Twitter. Je moet ook meedoen aan onze bèta en ons volgen op Twitter of Medium of via RSS, of volg mij of Ellen op Twitter.

Met dank aan 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 en Vaibhav Sagar voor het beoordelen van de ontwerpen van dit bericht .