Hvad er mørkt?

Dark er et holistisk programmeringssprog, struktureret editor og infrastruktur til opbygning af backend-webtjenester. Det er rettet mod frontend, backend og mobile ingeniører.

Vores mål er at gøre kodningen 100x lettere, hvilket vi tror vil give en milliard mennesker mulighed for at opbygge software. Dette er en enorm udfordring, der kræver en betydelig nytænkning af, hvordan vi skriver software.

Dette indlæg skal tale om, hvordan vi tænker på verden. Vi introducerer vores kernefilosofi, retning på højt niveau og vores mål. Vi kommer til at gå nærmere ind på i fremtidige indlæg (se bunden; eller få besked ved at følge Dark eller via postlisten).

Tilfældig kompleksitet

Det definerende princip bag Dark er, at vi ønsker at fjerne al tilfældig kompleksitet fra kodning. At bygge applikationer i dag er utroligt kompliceret, og meget af denne kompleksitet er utilsigtet.

Udtrykket "utilsigtet kompleksitet" (eller tilfældig kompleksitet) kommer fra et essay kaldet "No Silver Bullet". I det delte Fred Brooks kompleksitet op i "essentiel kompleksitet", som er kernen i det forretningsproblem, du løser, og "utilsigtet kompleksitet", som er alt andet, du skal gøre for at fremstille software.

Han påpegede, at for at forbedre produktiviteten 10x, må vi fjerne 90% af de ting, vi gør. På det tidspunkt mente han, at softwareudvikling ikke var 90% utilsigtet kompleksitet, og derfor var ingen forbedring på 10 gange mulig. Derfor navnet “Ingen sølvkugle”.

Når jeg ser omkring software i dag, virker 90% som et lavt skøn. Mængden af ​​utilsigtet kompleksitet er ude af kontrol. Se på "Det er fremtiden" og "Hvordan det føles at lære JavaScript i 2016". Hvorfor skal vi vide, hvordan vi bruger alle disse værktøjer til at skrive software?

Grundlæggende er at skrive software bare modtage data, manipulere dem, opbevare dem og sende dem et sted - lette koncepter, som vi lærer i vores første programmeringsvejledninger. Hvorfor er det sådan, at for at opbygge en applikation i dag er vi nødt til at lære Kubernetes, Docker, Git, load balancers, snesevis af AWS-tjenester, SQL, NoSQL, Kafka, Unix, GraphQL, gRPC, npm, Heroku, DNS, memcached, JWT, Nginx , og resten af ​​den uendelige liste over værktøjer og teknologier, der hver især leverer en del af en applikation?

Kompleksiteten er ude af kontrol, og det har ikke vist nogen tegn på afmatning. Det er allerede på det tidspunkt, hvor frontend-udviklere føler, at de ikke kan skrive backends. De har så meget af deres egen kompleksitet at håndtere, at de ikke kan finde plads til backend-kompleksiteten. Hvordan lod vi dette ske?

Et holistisk sprog

Kerneproblemet her er, at de værktøjer, vi har opført - som en industri - er trinvis. Dette er naturligt: ​​du bygger et nyt værktøj til at ridse en kløe, for at løse kendte problemer, og du gør det på en måde, der kan bruges ved siden af ​​brugernes eksisterende værktøjer. "Gør en ting og gør det godt" er kernen i Unix-filosofien, som vi har fulgt siden 70'erne.

Her er udviklingen af ​​fælles værktøjer i vores branche:

  • RCS → CVS → Subversion → Git
  • Servere → Delte unix-bokse → Virtuel-private servere → Heroku → Lambda eller Kubernetes
  • Natligt build-script → BuildBot → Jenkins → CircleCI
  • Ed → Vi → Vim → Atom / Sublime / VSCode / osv

Hvert nyt værktøj forbedres med det forrige værktøj, men udfylder det samme rum uden at fjerne koncepter og kompleksitet. Faktisk øger de ofte kompleksiteten: Git er et bedre værktøj end Subversion, men Subversion var meget enklere.

Faldende kompleksitet

I stedet for at opbygge en bedre version af eksisterende ting, er måden at mindske kompleksiteten på at fjerne ting helt.

Hvis vi bygger et værktøj, der gør to ting, fjerner det ikke kun grænsefladen, men reducerer også overfladen af ​​begge problemer. Hvis vi bringer fire eller otte værktøjer sammen, kan vi eliminere enorme skår af kompleksitet, grænseflade og overlapning mellem værktøjerne.

Dark er holistisk: det kombinerer en editor med et sprog og infrastruktur. Det er ikke et generelt sprog eller en generel redaktør eller generel infrastruktur. Hvert stykke er designet specifikt til at arbejde med de andre stykker, og denne stramme integration giver os mulighed for at skære en stor del af den kompleksitet ud:

  • Infrastrukturkompleksitet
  • Implementeringskompleksitet
  • API-kompleksitet
  • Kode-som-tekst kompleksitet

Infrastrukturkompleksitet

Infrastrukturkompleksitet er alt, hvad det drejer sig om at arbejde med de maskiner, som vi kører vores kode på, i modsætning til bare at arbejde med data og kunder. Dette inkluderer Docker og Kubernetes, EC2 og hele AWS / GCP / Azure-økosystemet, der beskæftiger sig med køer, netværk, firewalls, belastningsbalancere, serviceopdagelse, skalering, overvågning, sikkerhed, DB'er, afskærmning og optimering.

I Dark kører vi infrastrukturen for dig. Fordi vi dybt forstår din applikation - kode, trafik og data - kan vi tage gode beslutninger om den arkitektur, du har brug for. Som sådan kan vi fjerne alle infrastrukturvalg: du behøver ikke at håndtere maskiner, orkestrering, opbevaring, databaser eller køer.

Derudover skulle vi være i stand til automatisk at tage store skaleringsbeslutninger - vi tænker på Dark som en infrastrukturkompiler, der sammensætter det ideelle distribuerede system til din applikation. Vi forventer at være i stand til at abstrahere og forenkle på måder, som Lambda, Kubernetes eller Heroku ikke kan.

Tag f.eks. Databaser. I dag skal en applikation og dens database administreres omhyggeligt sammen, på trods af at de er helt forskellige med hensyn til driftsmæssige bekymringer, sprog, formater og operatørens kompetencegrupper. Ved at kombinere en database med dens applikation fjernes mange spørgsmål, som ingen af ​​komponenterne kan besvare i sig selv, såsom hvilke indekser der er behov for, hvordan man klipper, den bedste måde at skrive forespørgsler på, og hvordan man styrer langvarige datamigreringer.

Tilsvarende er grænsefladen med en database fra en applikation kompliceret: Jeg er nødt til at overveje, om typerne stiller op, hvordan min ORM muligvis mislykkes, hvordan den skalerer, hvilke indekser den har brug for. Hvorfor kan jeg ikke bare gemme data, forespørgseldata og få adgang til data, når jeg har brug for dem?

Den stramme integration af sprog, redaktør og infrastruktur giver os også mulighed for at give observerbarhed i dine live-produktionssystemer lige fra Dark-editoren, som fuldstændigt ændrer, hvordan folk koder og bygger systemer. Det fjerner også behovet for separat overvågning, sporing, instrumentering, logning og fejlhåndtering.

Implementeringskompleksitet

Implementeringskompleksitet er problemet med at synkronisere den færdige kode fra en maskine til en anden. Dette er en af ​​de ting, der skal være trivielle, men at gøre det sikkert og hurtigt forårsager så mange problemer, at jeg byggede CircleCI for at hjælpe med at løse det.

Virksomheder afsætter enorme ressourcer til at reducere end-to-end-tiden for levering af en ændring til kunderne. Men forsendelseskoden involverer nødvendige trin, der tager tid. Emballagekode (Docker container, tarball, webpack, AMI, git checkout, krukker), test den (CircleCI, kodedækning, browser test / selen), synkroniserer den (git push til Heroku, Docker registreringer, artefakt hosting, S3, CDNs) , aktivering af den nye kode (Kubernetes, reverse proxies, Capistrano, udskiftning af symlinks) og rulling ud (funktionsflag, blågrøn deploys, DB-migrering, API-versionering), involverer ikke kun massiv kompleksitet og værktøj, men også uundgåelig væg- ur tid.

I mørke redesigner vi installationsprocessen for ikke at kræve disse trin. I stedet for er distribution trivial. Så snart du skriver kode i Dark Editoren, distribueres den straks til produktion, klar til at blive aktiveret med et funktionsflag. Der er ingen lang bygningsproces, ingen tarballs, ingen containere. Det er en simpel forskel fra din editor til vores infrastruktur.

Dark er designet til at gøre denne proces sikker. Ruter, API'er og køer er alle statisk indtastet, og hver funktion og type er versioneret og uforanderlig. Implementeringssikkerhedsfunktioner, såsom funktionsflag, enhedstest og kraftfulde databasemigrationer, er indbygget i værktøjet, sproget og editoren. Selvom en indsættelse kun tager ~ 50 ms, er distributioner betydeligt mindre risikabelt i Dark end i moderne værktøjskæder.

API-kompleksitet

API-kompleksitet kommer fra, hvor meget sværere det er at bruge en API versus at kalde en funktion. Brug af API'er skal være så let som at kalde en funktion, men vi er nødt til at håndtere autentificering, hastighedsbegrænsning, fejlhåndtering, gentest. Måden til at håndtere disse er forskellig i hver API, fra autorisationstype til protokol (HTTP + JSON / REST / Protobuf / gRPC / GraphQL / SOAP) til opkaldskonventioner, og der er millioner af API'er i verden at tackle (og vokse) ).

I Dark er det at foretage et API-opkald så simpelt som et funktionsopkald. Vores værktøjer til at bygge forbindelser til tredjeparts tjenester håndterer hastighedsbegrænsning, autentificering, fejlhåndtering og forsøg med stor standardadfærd. Synlighed omkring omkostninger og fejl er indbygget i editoren, ligesom understøttelse af hemmelige nøgler og personlig identificering af oplysninger.

Kode-som-tekst kompleksitet

Kode-som-tekst kompleksitet er lidt af en fangst alle. Det refererer til alle de diverse problemer, vi har omkring hvordan vi skriver kode og værktøjet omkring det.

Et indlysende eksempel er syntaksfejl. Syntaksfejl findes, fordi vi skriver kode som tekst, og beder derefter kompilatoren om at læse den, som nogle gange ikke kan. For aldrig at have en syntaksfejl igen, skal vi have en editor, der ikke tillader dem at blive tilføjet - en, der taler sproget, ikke kun almindelig tekst.

Dette koncept kan udvides til mange dele af værktøjskæden. Vi omdøber funktioner til vores redaktører 'søg-og-erstatt-funktioner, som ikke forstår forskellen mellem en funktion og en variabel; vi fusionerer grene med Git, som ikke forstår syntaks eller semantik for vores kode. Vi skriver kode i Python eller Node eller Rust, men skal også overveje et helt operativsystem, der kører under det. Vi bruger dusinvis af tekstbaserede værktøjer, som vi næppe forstår, såsom git, bash, grep, sed - fordi ingen af ​​vores værktøjer faktisk forstår vores kode.

Det mørke sprog er bygget hånd i hånd med en struktureret editor og infrastruktur. Som sådan er autofuldførelsen opmærksom på hele dit program, og syntaksfejl er ikke mulige. Refactoring værktøjer er indbygget, ligesom samarbejde og adgangskontrol. Versionsstyring er førsteklasses og er tæt integreret med resten af ​​sproget, inklusive funktionsflag og funktion og typeversionering.

Hvem bygger vi Dark for?

På lang sigt bygger vi Dark for alle - erfarne kodere, nye kodere og ikke-kodere - men vi er nødt til at starte mindre end det. Lige nu bygger vi Dark til eksisterende udviklere, der ønsker at bygge backends og målrette mod to hovedområder.

Den første er backends til klient-apps, såsom mobile apps, eller web-apps med en side, der er skrevet i React, Vue, Angular, osv. Hvis du er en frontend / mobiludvikler, der er utilfreds med, hvor svært det er at lave en backend, du vil sandsynligvis lide mørke.

Den anden bygger nye tjenester i eksisterende mikroservice-baserede arkitekturer. At opbygge en ny tjeneste betyder, at du tilmelder dig en fremtid med yaml-filer, installationsrørledninger, 2 am sider, nul-dages sikkerhedsadvarsler og evig vedligeholdelse. Hvis du ser på nye sprog og værktøjer (som Lambda) for at reducere denne byrde, bør Dark hjælpe. Det er, hvad Dark er bygget til, så du kan bygge backend-tjenester med lidt-til-ingen skalering og vedligeholdelsesomkostninger.

Naturligvis burde udviklere, der laver helt nye webstarter eller sideprojekter, også have det sjovt med Dark. På den anden side, hvis du bygger ting som indlejrede systemer, teorem provers eller maskinlæringsmodeller, understøtter Dark ikke denne form for anvendelse i mange år.

Dark har en mission at bringe kodning til en milliard mennesker. Vores tro er, at vi er nødt til at starte med eksisterende udviklere og udvide: hvis vi gør kodning for eksisterende udviklere 100x lettere, sænker vi markant adgangsbarrieren for alle, der prøver at lære at kode, eller folk i "kodning-tilstødende" job som designere, premierminister, analytikere og informationsarbejdere generelt.

Lær mere om Dark

Dette har været en introduktion til, hvordan vi tænker på verden med Dark. Vi planlægger at frigive mange flere detaljer og planer i løbet af de næste par måneder, når vi kommer nærmere en offentlig udgivelse. Her er nogle indlæg, vi arbejder på:

  • “Problemet med tekst”
  • “Hvordan blev verden så kompleks?” (Rails monoliths vs microservices)
  • “Ulemperne ved Dark - open source, self hosting og potentiel lock-in”
  • "Ting som og i modsætning til mørke" (sammenligning med lignende koncepter som Eve, Glitch, Smalltalk eller Bret Victor's arbejde)
  • Sådan deployes mørke på 50ms
  • "Find ikke noget nyt" og "Innovere ved grænserne"
  • “Implicit vs Explicit in Dark” (dynamisk vs statisk indtastning)
  • Reelle problemer med funktionelle sprog
  • "Hvorfor Dark er ikke lav kode eller ingen kode"
  • “Designe en strengtype til en Unicode-verden”
  • “Et tilbageblik på vores eksperimenter med et grafbaseret sprog”
  • ”Hvorfor lave vores eget sprog?”

Hvis der er en, du gerne vil have os til at prioritere, eller spørgsmål om Dark, skal du sige hej på Twitter. Du skal også deltage i vores beta og følge os på Twitter eller Medium eller via RSS, eller følge mig eller Ellen på Twitter.

Tak til 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 og Vaibhav Sagar for at gennemgå udkast til dette indlæg .