Kyiv Go Meetup majo 2018:
Plumbo: - Saluton al ĉiuj! Dankon pro esti ĉi tie! Hodiaŭ ni havas du oficialajn parolantojn - Lyosha kaj Vanja. Estos du pliaj, se ni havos sufiĉe da tempo. La unua parolanto estas Alexey Grachev, li rakontos al ni pri GopherJS.
Alexey Grachev (ĉi-poste - AG): – Mi estas Go-programisto, kaj mi skribas retservojn en Go. Kelkfoje vi devas trakti la fasadon, foje vi devas eniri ĝin permane. Mi volas paroli pri mia sperto kaj esploro pri Go sur la fasado.
La legendo estas jena: unue ni parolos pri kial ni volas ruli Go sur la fasado, poste ni parolos pri kiel tio povas esti farita. Estas du manieroj - Web Assembly kaj GopherJS. Ni vidu, kia estas la stato de ĉi tiuj solvoj kaj kion oni povas fari.
Kio estas malbona kun la fasado?
Ĉu ĉiuj konsentas, ke ĉio estas en ordo kun la fasado?
Ĉu ne estas sufiĉe da provoj? Malrapida konstruo? Ekosistemo? Bone.
Koncerne la fasadon, mi ŝatas la citaĵon, kiun unu el la fasadprogramistoj diris en sia libro:
Javascript ne havas tipsistemon. Nun mi nomos la problemojn, kiujn mi renkontis dum mia laboro, kaj klarigos kiel ili estas solvitaj.
La tipsistemo ĝenerale apenaŭ povas esti nomita tipsistemo en Javasript - estas linioj kiuj indikas la tipon de la objekto, sed fakte tio havas nenion komunan kun tipoj. Ĉi tiu problemo estas solvita en TypeScript (aldonaĵo al Javasript) kaj Flow (statika-tipa kontrolilo en Javaskripto). Fakte, la fasado jam atingis la punkton de solvi la problemon de malbona tipa sistemo en Javascript.
Ne ekzistas norma biblioteko en la retumilo kiel tia - ekzistas kelkaj enkonstruitaj objektoj kaj "magiaj" funkcioj en retumiloj. Sed en Javascript ne ekzistas norma biblioteko kiel tia. Tiu ĉi problemo jam estis solvita unufoje per jQuery (ĉiuj uzis jQuery kun ĉiuj prototipoj, helpantoj, funkcioj, kiuj estis bezonataj por funkcii). Nun ĉiuj uzas Lodash:
Revoko infero. Mi pensas, ke ĉiuj vidis Javascript-kodon antaŭ ĉirkaŭ 5 jaroj, kaj ĝi aspektis kiel "nudelo" de nekredebla kompliko de revoki. Nun ĉi tiu problemo estas solvita (kun la liberigo de ES-15 aŭ ES-16), promesoj aldoniĝis al Javascript kaj ĉiuj povas spiri pli facile dum iom da tempo.
Ĝis la infero de Promice alvenis... Mi ne scias kiel administras la antaŭa industrio, sed ili ĉiam veturas sin en iun strangan ĝangalon. Ni ankaŭ sukcesis fari inferon pro promesoj. Tiam ni solvis ĉi tiun problemon aldonante novan primitivon - async/wait:
La problemo kun malsinkronio estas solvita. Async/wait estas sufiĉe populara primitivo en diversaj lingvoj. Python kaj aliaj havas ĉi tiun aliron - ĝi estas sufiĉe bona. Problemo solvita.
Kiu problemo ne estas solvita? La eksponente kreskanta komplekseco de kadroj, la komplekseco de la ekosistemo kaj la programoj mem.
- Javascript-sintakso estas iom stranga. Ni ĉiuj scias la problemojn kun aldono de tabelo kaj objekto kaj aliaj ŝercoj.
- Javascript estas mult-paradigmo. Ĉi tio estas precipe urĝa sistemo nun kiam la ekosistemo estas tre granda:
- everyone writes in different styles - iuj skribas strukture, iuj skribas funkcie, malsamaj programistoj skribas diversmaniere;
- de malsamaj pakoj, malsamaj paradigmoj kiam vi uzas malsamajn pakojn;
- estas multe da "amuzo" kun funkcia programado en Javasript - la rambda biblioteko aperis kaj nun neniu povas legi programojn skribitajn en tiu ĉi biblioteko.
- Ĉio ĉi havas grandan efikon sur la ekosistemo, kaj ĝi kreskis nekredeble. La pakaĵoj estas nekongruaj unu kun la alia: iuj baziĝas sur promesoj, iuj baziĝas sur async/wait, iuj baziĝas sur revokoj. Ili ankaŭ skribas en malsamaj paradigmoj!
- Ĉi tio faras la projekton malfacile konservi. Estas malfacile trovi cimon se vi ne povas legi la kodon.
Kio estas Reta Asembleo?
La kuraĝaj uloj de la Fondaĵo Mozilla kaj kelkaj aliaj kompanioj elpensis tian aferon kiel Web Assembly. Kio estas ĉi tio?
- Ĉi tio estas virtuala maŝino enkonstruita en la retumilo, kiu subtenas la binaran formaton.
- Binaraj programoj alvenas tie kaj estas ekzekutitaj preskaŭ denaske, tio estas, la retumilo ne bezonas ĉiufoje analizi ĉiujn "nudelojn" de Javaskripto-kodo.
- Ĉiuj retumiloj deklaris subtenon.
- Ĉar ĉi tio estas bajtokodo, vi povas skribi kompililon por iu ajn lingvo.
- Kvar ĉefaj retumiloj jam ekspediĝas kun subteno de Web Assembly.
- Ni atendas denaskan subtenon en Go baldaŭ. Ĉi tiu nova arkitekturo jam estis aldonita: GOARCH=wasm GOOS=js (baldaŭ). Ĝis nun, kiel mi komprenas ĝin, ĝi ne estas funkcia, sed estas deklaro, ke ĝi certe estos en Go.
Kion fari nun? GopherJS
Kvankam ni ne havas subtenon por Web Assembly, ekzistas transpililo kiel GopherJS.
- Go-kodo estas transigita en "puran" Javascript.
- Funkcias en ĉiuj retumiloj - ne ekzistas novaj funkcioj, kiuj estas subtenataj nur de modernaj retumiloj (ĉi tio estas Vanilla JS, kiu funkcias per io ajn).
- Estas subteno por preskaŭ ĉio, kion Go havas, inkluzive de gorutinoj kaj kanaloj... ĉio, kion ni tiom amas kaj scias.
- Preskaŭ la tuta norma biblioteko estas subtenata, krom tiuj pakaĵoj, kiujn ĝi havas neniun sencon subteni en la retumilo: syscall, retaj interagoj (estas net/http kliento, sed neniu servilo, kaj la kliento estas kopiita per XMLHttpRequest). Ĝenerale, la tuta norma biblioteko disponeblas - jen ĝi estas en la retumilo, jen la stdlib de Go, kiun ni amas.
- La tuta paka ekosistemo en Go, ĉiuj triaj solvoj (ŝablonaj ktp.) povas esti kompilitaj per GopherJS kaj rulitaj en la retumilo.
GopherJS estas tre facile akiri - ĝi estas nur regula Go-pakaĵo. Ni iras akiri, kaj ni havas GopherJS-komandon por konstrui la aplikaĵon:
Ĉi tio estas tiel malgranda saluta mondo...
...Norma Go-programo, regula norma biblioteko fmt-pakaĵo kaj Binding Js por atingi la retumilon API. Println finfine estos konvertita al konzola protokolo kaj la retumilo skribos "Saluton gophers"! Estas tiel simpla: ni faras GopherJS-konstruadon - ni lanĉas ĝin en la retumilo - ĉio funkcias!
Kion vi havas nuntempe? Ligiloj
Estas ligoj por ĉiuj popularaj js-kadroj:
- JQuery;
- Angular.js;
- D3.js por komploti kaj labori kun grandaj datumoj;
- React.js;
- VueJS;
- ekzistas eĉ subteno por Electron (tio estas, ni jam povas skribi labortablajn aplikaĵojn sur Electron);
- kaj la plej amuza afero estas WebGL (ni povas fari plen-grafikajn aplikojn, inkluzive de ludoj kun 3D-grafikaĵoj, muziko kaj ĉiuj bonaĵoj);
- kaj multaj aliaj ligoj al ĉiuj popularaj javaskriptokadroj kaj bibliotekoj.
kadro
- Estas interreta kadro jam evoluigita specife por GopherJS - Vecty. Ĉi tio estas plentaŭga analogo de React.js, sed nur disvolvita en Go, kun la specifaĵoj de GopherJS.
- Estas ludsakoj (surprizo!). Mi trovis la du plej popularajn:
- Engo;
- Ebiten.
Mi montros al vi kelkajn ekzemplojn pri kiel ĝi aspektas kaj kion vi jam povas skribi en Go:
Aŭ ĉi tiu opcio (mi ne povis trovi 3D-pafanton, sed eble ĝi ekzistas):
Kion mi proponas?
Nun la antaŭa industrio estas en tia stato, ke ĉiuj lingvoj, kiuj antaŭe kriis de Javascript, rapidos tien. Nun ĉio estos kompilita en "Retaj Asembleoj". Kion ni bezonas por preni nian ĝustan lokon tie kiel Gophers?
Go tradicie supozis ke ĝi estas Sistemo programlingvo, kaj ekzistas preskaŭ neniuj bibliotekoj por labori kun la UI. Estas io, sed ĝi estas duone forlasita, duone nefunkcia.
Kaj nun estas bona ŝanco fari UI-bibliotekojn en Go, kiuj funkcios sur GopherJS! Vi povas finfine skribi vian propran kadron! Ĉi tiu estas la tempo, kiam vi povas skribi kadron, kaj ĝi estos unu el la unuaj kaj ricevos fruan adopton, kaj vi estos stelo (se ĝi estas bona kadro).
Vi povas adapti multajn malsamajn pakaĵojn, kiuj jam estas en la Go-ekosistemo, al la specifaĵoj de la retumilo (ekzemple Ŝablona motoro). Ili jam funkcios, vi povas fari oportunajn ligojn por ke vi facile povu redoni la enhavon rekte en la retumilo. Plie, vi povas fari, ekzemple, servon kiu povas prezenti la samon sur la servilo kaj sur la front-end, uzante la saman kodon - ĉion, kion front-end-programistoj ŝatas (nur nun en Go).
Vi povas skribi ludon! Nur por amuzo…
Tion mi volis diri.
Viaj demandoj
Demando (ĉi-poste nomata Q): – Ĉu mi skribas en Go aŭ Js?
AG: – Vi skribas rutinojn, kanalojn, strukturojn, enkonstruadon – ĉion en Go... Vi abonas eventon, pasas funkcion tie.
En: – Do mi skribas per “nudaj” Js?
AG: – Ne, vi skribas kvazaŭ en Go kaj konektas al la retumilo API (la API ne ŝanĝiĝis). Vi povas skribi viajn proprajn ligadojn por ke mesaĝoj estu senditaj al la kanalo - ne malfacilas.
En: – Kio pri poŝtelefono?
AG: – Mi nepre vidis: estas ligiloj por la Kordova flikaĵo, kiun Js kuras. En React Native - mi ne scias; eble ekzistas, eble ne (mi ne estis precipe interesita). La ludmotoro N-go subtenas ambaŭ moveblajn aplikojn - ambaŭ iOS kaj Android.
En: – Demando pri Reta Asembleo. Pli kaj pli da spaco estas okupata, malgraŭ la kunpremado kaj "zipo"... Ĉu ni ne mortigos la antaŭan mondon tiamaniere eĉ pli?
AG: – Web Assembly estas duuma formato, kaj duuma defaŭlte ne povas esti en la fina eldono pli ol teksto... Vi estas altirita al rultempo, sed ĉi tio estas la sama kiel treni la norman Javascript-bibliotekon kiam ĝi ne estas tie, do ni uzu iom da Lodash. Mi ne scias kiom Lodash prenas.
En: – Evidente malpli ol rultempo...
AG: – En “pura” Javascript?
En: - Jes. Ni kunpremas ĝin antaŭ ol sendi ĝin...
AG: – Sed ĉi tio estas teksto... Ĝenerale, megabajto ŝajnas multe, sed jen ĉio (vi havas la tutan rultempon). Poste, vi skribas vian propran komercan logikon, kiu pliigos vian binaron je 1%. Ĝis nun mi ne vidas tion mortigi la fasadon. Plie, Web Assembly funkcios pli rapide ol Javascript pro la evidenta kialo - ĝi ne bezonas esti analizita.
En: – Ĉi tio ankoraŭ estas polemika punkto... Ankoraŭ ne ekzistas referenca realigo de “Vasma” (TTT-Asembleo), por ke oni povu juĝi senambigue. Koncipe, jes: ni ĉiuj komprenas, ke duuma devus esti pli rapida, sed la nuna efektivigo de la sama V8 estas tre efika.
AG: - Jes.
En: – Kompilo tie funkcias vere tre bonega kaj ne estas fakto, ke estos granda avantaĝo.
AG: – Reteja Asembleo ankaŭ estas farita de grandaj uloj.
En: – Ŝajnas al mi, ke estas ankoraŭ malfacile juĝi Web Assembly. Estas konversacioj okazantaj jam de multaj jaroj, sed estas malmultaj realaj atingoj kiuj povas esti sentitaj.
AG: - Eble. Ni vidos.
En: – Ni ne havas problemojn sur la backend... Eble ni devus lasi ĉi tiujn problemojn sur la fasado? Kial iri tien?
AG: – Ni devas konservi stabon de unualiniaj laboristoj.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com