Fórumok
Egy új, forradalmi nyelv van születőben, a Unison.
A forradalmi ötlet az, hogy az egyes definíciókat nem névvel azonosítjuk, hanem az absztrakt szintaxis fájuk hash-ével.
Ennek nagyon érdekes következményei vannak:
- Az elosztott rendszerek létrehozása és kezelése rendkívüli módon egyszerűsödik. A microservice architektúra számos hátránya eltűnik.
- Nincs build idő, vagyis gyakorlatilag nulla. Az erősen statikusan típusolt nyelveknél elég sokáig tart egy nagyobb alkalmazás buildelése. Itt gyakorlatilag nincs build, mivel az egyes definíciók ellenőrzés és átalakítás után, egyből bekerülnek a közös kódbázisba, ahol azonnal használhatóvá válnak.
- Nincs függőségi konfliktus. Egy-egy definíciónak tetszőleges sok verziója létezhet és futhat egymás mellett.
- Típusolt, tartós tárolás. Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani, gyakorlatilag az adott adat közvetlenül tárolható, akár elosztott rendszerben is.
- Gazdagabb kódbázis eszközök. A Unison kódbázis egy megfelelő adatbázis, amely ismeri minden tárolt dolog típusát, tökéletes fordítási gyorsítótárral, tökéletes tudással rendelkezik a függőségekről, a típusalapú keresés indexeiről és még sok másról. Ez lehetővé teszi számunkra, hogy egyszerűen készítsünk sokkal gazdagabb eszközöket a böngészéshez és a kóddal való interakcióhoz. Gyakorlatilag nem szükséges IDE, egy egyszerű szövegszerkesztővel is az IDE szolgáltatások elérhetőek, sőt még annál többek is.
- Struktúrált refaktorálás. Mivel a kódbázisban eltárolva van az összes függőség, strukturált módon, így segítséget kapunk a refaktorálás folyamatán, hogy mikor mit módosítsunk. Plusz előny, hogy a kódbázisunk folyamatosan futtatható állapotban van, sosincs törött állapotban.
Ui.:
Ebből a videóból sokkal jobban megérthető az ötlet és a működése:
"Unison: a new distributed programming language" by Paul Chiusano
Hozzászólások
Ismertetők:
A look at Unison: a revolutionary programming language
Unison: program differently by Adam Warski | Lambda Days 2023
Hát... ez max azoknak a haskel rajongóknak lesz érdekes, akik nem akarnak on-premise felhőt. :)
A Haskell rajongók meg azért nem fogják használni, mert nem teljesen pure ;-)
Akkor halott projekt. ;)
Az "érdekes következmények" tele vannak ellentmondásokkal és bullshittel:
Nincs build idő, vagyis gyakorlatilag nulla. vs. az egyes definíciók ellenőrzés és átalakítás után - ez utóbbi talán nem idő?
Nincs függőségi konfliktus. vs. Struktúrált refaktorálás.
Egy-egy definíciónak tetszőleges sok verziója létezhet és futhat egymás mellett. vs. segítséget kapunk a refaktorálás folyamatán, hogy mikor mit módosítsunk - de hát minden függőség eleve benne van, akkor minek refaktorálni? Ha meg a logikai réteget kell refaktorálni, abban meg úgysem tud segíteni a típusadatbázis.
Típusolt, tartós tárolás. Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani, gyakorlatilag az adott adat közvetlenül tárolható, akár elosztott rendszerben is. - konkrét bullshit. Lássuk, hogy olvas be valaki egy GIF-et például így, átalakítás nélkül.
Ez egy kamu, nem egyéb parasztvakításnál. Hozzáértő szem elsőre kiszúrja, az AST előállítása is része a build időnek, aztán meg akármit varázsolsz, csak kell egy kódgenerátor is, ami az AST-t natív binárissá alakítja, vagy egy interpreter, ami értelmezi. Önmagában az AST nem is futtatható program.
Ha valamiről semmi tudásod nincs, akkor nem javasolt határozott véleményeket megfogalmazni. ;-)
Azért megpróbálok válaszolni a tévedéseidre.
Igen, idő, de nem build idő. Ahogy az sem build idő, amikor egy forrást feltöltesz forráskezelő (pl. git) tárolóba. Ez pontosan ugyanakkor történik, csak nem forrásként tárolja, hanem szintaxis faként.
Itt nem értem mi az ellentmondás.
Ha az egyik verzió helyett egy másikat akarnál használni. Ilyenkor felsorolja neked az összes helyet, ahol az egyik verzió van használva, illetve ha kompatibilis, akkor automatikusan ki is cseréli a referenciát, ha nem, akkor sorrendbe rakja, hogy mikor mit írjál át.
Nem erről van szó. Arról van szó, hogy van egy adatod, amit el szeretnél tárolni, majd vissza akarod olvasni. Ilyenkor nem kell átalakítanod mondjuk json-ba, letárolni, majd visszaolvasáskor visszaalakítani adatszerkezetté, hanem az adott szerkezetet tárolod el és olvasod vissza pontosan ugyanazt. Ez nem arra való, hogy a külső világgal kommunikálj, hanem csak a belső adatok tárolására, visszaolvasására.
Ez pontosan így van. Jelenleg csak interpreter van, ami értelmezi. Tervben van a binárissá alakítás is, nyilván ott lesz valamennyi build idő is.
LOL, sejtelmed sincs, kivel beszélsz :-D
Ha a forrás ellenőrzése, átalakítása és az AST előállítása belőle nem a build időhöz tartozik, akkor hova? Írtál te már fordítóprogramot? Én igen.
Ezt bármelyik fejlettebb IDE megteszi neked bármelyik programozási nyelv esetén. Ebben semmi forradalmi sincs.
Úgy van. Van egy kép adatom, amit GIF-két szeretnék eltárolni majd visszaolvasni. Hogy akarod ezt megoldani átalakítás nélkül?
Az, hogy az Unison képes egy memdumpot lementeni és visszaolvasni nem nagy kunszt, ezt bármelyik programozási nyelven megteheted és mindenhol piszok gyors. Csak épp ugye a lementett adat használhatatlan bármilyen más környezetben. Ebben sincs semmi forradalmi, már ősidők óta használnak memdumpokat.
Az sem újdonság, hogy közvetlenül az AST-t tárolják, a .pyc fájlok ugye pontosan ezt teszik, binárisan szerializált Python AST fák. Adatok tárolására sem újdonság, a Blender által mentett .blend fájlok lényegében strukturált Python memdumpok például. Semmi forradalmi.
Nem tudtam, hogy Unison szakértő vagy ;-) Ugyanis arról tettél határozott kijelentéseket, pedig láthatóan fogalmad sincs róla, miként működik.
Ugyanoda, ahová a git-re felrakáskor futó ellenőrzések tartoznak. Az build idő?
Nem erről van szó még mindig. Arról, hogy kvázi adatbázisba ments dolgokat, amiket aztán kereshetsz, szűrhetsz, visszatölthetsz, ...
Igen, ez nem újdonság. Az az újdonság, hogy ezt egy kódbázisba teszik be, amit a hash-ük azonosít. Így a kódbázisba betevéskor már meglesz az összes függőség, mi mihez, hogyan kapcsolódik. Onnan közvetlenül futtatható, akár távoli gépeken is.
Össze-vissza beszélsz. A gitbe tudsz pusholni build nélkül is, és build-et is tudsz csinálni git push nélkül.
Tipikus babzsákfotelfejlesztő vagy, csak mert a git push során lefuthat egy build, már nem is tudsz különbséget tenni a kettő között.
A forrás ellenőrzése, átalakítása és az AST előlállítása belőle AZ IGEN, az biza build idő, de ennek semmi köze a CI-hez. Mondjuk aki ennyire nincs tisztában az alapfogalmakkal, az nem csoda, hogy bedőlt ennek az Unison bullshitnek.
Adatokról volt szó, nem kódról, de abban sincs semmi újdonság. Ősidők óta a fordítók hash-el tárolják a kód definícióit, DT_HASH már olyan régi, hogy el is avult, manapság már mindenki DT_GNU_HASH-t használ.
Mégegyszer, ebben semmi, de semmi forradalmi újdonság sincs. Csúnyán megvezettek, felültél a bullshitnek.
Azzal egyetértek, hogy kicsit túl van hype-olva, de ettől függetlenül az ötlet (ami nem új, csak újszerűen használva) megold egy csomó problémát.
A fordító csak a saját munkáját könnyíti meg a fejlesztő gépén vagy a ci/cd pipeline rövid életű elemeként, de utána nem kezd vele semmit. Ha jól értem itt mivel erősen kikényszerített módon vagy kötelezve a funkcionális programozás használatára, a kód, a függőség kezelés, a fordítás és a futtatás egysége is a függvény. Emiatt a fordítási idő az egy módosult függvényedre vonatkozik, a push szintén, az artefact feltöltés szintén, a futtatás előtt/alatt letöltött program szintén. Azaz baromi pici immutable komponensek kezelése van végig vezetve az egész láncon, ami tényleg új, ilyet más lépésenként csinál, de egyben nem tudok hasonlóról. Hogy ezzel minden megoldható-e, főleg hatékonyan, az egy jó kérdés. A mellékhatások elkerülése adatok állapotával dolgozó rendszerek esetén kb lehetetlen, így azért sérül a funkcionális programozás ígérete. De ennek ellenére architektúrális szempontból elosztott rendszerek esetén törekedni kell a szabályai betartására az architektúra minden szintjén, különben egy időzített bomba az egész.
Nem jól érted. Ez a nyelv nem is teljesen pure funkcionális. Ez az elv működne bármely más nyelv esetén is.
kontra
Na tessék, egy újabb ellentmondás. Akkor most funkcionális vagy sem?
Funkcionális, de nem teljesen pure funkcionális. Lehet benne nem referential transparent megoldást is írni.
Igen, egyetértek. Nem véletlen, hogy egy csomó IDE és fordítóprogram is tudja már ezt. Nekem is főként a "forradalmi" jelző böki a csőrömet, és nem maga a hash ilyettén használata.
Ezzel is egyetértek. Konkrét összehasonlító mérések kellenének, hogy kiderüljön, lépésenként végrehajtva vagy egyben kezelve jobb-e, megéri-e a hozzáadott bonyolultságot.
Egy kicsit ott sántít szerintem a dolog, hogy mi van, ha több verziót is használ egy függvényből a program, de ez rossz, és a refaktor során egységesíteni kellene. (Tipikus példa, a proggi úgy lett megírva, hogy egy .so X függvényét használja, de az az .so frissül, ezért az új kód már az X függvény új verzióját használja. Ekkor nyilván más a hash, ezért ha "az egyes definíciókat nem névvel azonosítjuk, hanem az absztrakt szintaxis fájuk hash-ével", akkor esély sincs rá, hogy az Unison észrevegye, hogy e kettőt igazából egységesíteni kellene és nem külön tárolni).
Persze lehet nyilvántartani azt is, hogy melyik hash-ből melyik hash lett, de ez olyan bonyolultságot ad, ami miatt nem biztos, hogy megéri: egyrészről itt az összes függőség (saját kódbeli + összes .so) összes függvényének összes history-járól van szó, ami nem kevés és drasztikusan növekedő adatbázist igényel, másrészről kérdéses az implementáció hatékonysága is, azaz vissza az előző ponthoz, konkrét mérések kellenének, hogy megéri-e egyáltalán.
Ezzel is egyetértek. De tovább mennék, nekem a "Ha adatot el akarunk tárolni, akkor nem szükséges oda-vissza alakítani," bullshit szagúnak tűnik, mert az Unison adatokat nem lehet egy-az-egyben tárolni a már meglévő formátumokban (nincs olyan - és nem is lehet - már létező formátum, amiben lenne helye az Unison specifikus típus kódoknak az értékek mellett, mondjuk egy PNG-ben, WAV-ban stb. így egész biztos lehetetlen a feldolgozás az adatok oda-vissza alakítása nélkül).
Ugyanez igaz az összes már létező erősen típusos nyelvre is, ebben sincs semmi újdonság. Ráadásul nem is egyformán tárolják a típuskódot, lásd pl CPython, WASM ByteArray stb. stb. stb. Elég csupán csak arra gondolni, hány, de hány különböző módon tárolják a string típust a memóriában (akár egy nyelven belül is) és hogy hogyan vannak ezek tárolva a fájlokban. Az átalakítás csak akkor úszható meg, ha memdump-ot használsz és semmilyen más környezetben nem akarod feldolgozni az így mentett adatokat. Minden más esetben elkerülhetetlen az oda-vissza átalakítás, tehát ez az ígéret biztosan hazugság.
Idézném bazsot:
Ha arra se veszed a fáradtságot, hogy a magyarázataimat megértsd, pláne azt nem, hogy utánanézz mi is ez valójában és miként működik, akkor kár személyeskedned, mert csak magadat égeted.
Öcsém, miről beszélsz amikor még a build-et sem vagy képes megkülönböztetni a CI-től? A magyarázataid úgy rosszak, ahogy vannak, tele vannak tévedéssel és önellentmondásokkal. Gondolkodj el ezen kicsit.
Az a probléma, hogy az Unison mélyebb ismerete nélkül is vannak problémák a magyarázataiddal, és nem válaszolod meg a kérdéseket/oldod fel az ellentmondásokat, hanem megsértődsz. Értem, hogy ez természetes reakció egy általad kedvelt valaminek a bántására, de biztos, hogy nem professzionális. Ha az Unisont nem is láttuk még, a szálban mindenki dolgozott már több programnyelvvel, több különböző adatbázissal, több különböző fájlformátummal. Ha ebből indulsz ki, és nem abból, hogy csak te lehetsz a helikopter, akkor lehet, hogy kialakul egy értelmes szakmai beszélgetés. Ha neked van tapasztalatod vele, vagy jobban utána olvastál, akkor akár meg is oszthatnád ezt a tudást velünk. Már persze, ha méltónak találod méltatlan személyünket bölcsességed fényének kiterjesztésére.
Blog | @hron84
via @snq-
Sajnálom, ennyi telik tőlem.
Ha megnézed, rengeteg helyen próbáltam, több módon is megmagyarázni, illetve a félreértéseket tisztázni. Egyedül bzt személyeskedésére sértődtem meg, mivel az pont, hogy "nem professzionális" és nem "alakul ki egy értelmes szakmai beszélgetés".
Éppen ezen igyekeztem ebben a topikban, nem sok sikerrel.
Az ilyen megjegyzések sem igazán viszik előre a szakmaiságot, már ne is haragudj!
Igen, én sem értem. Egyfelől írja, hogy nem névvel ellátott definíciók vannak, de aztán a linkelt oldalon a forráskódban kapásból több helyen van definíció, pl. list, tempmain, stb..
Ez sem tiszta nekem sem, hogy hogy ne lenne fordítási idő. Az még Assembly-nél is van, ott is át kell fordítani az opkódokat gépi kódra, meg össze kell az egészet linkelni, nehogy már egy magas szintű funkcionális nyelvnek ne legyen. Nonszensz.
Bár nem kizárt, hogy csak én nem értem, hogy mi ez a hash-elés. A funkcionális programozás amúgy is meghaladja a tudásom, többször nekiduráltam magam (Haskell, Common Lisp), de mindig lepattanok róla. Az alapokat megtanultam, de képtelen vagyok általános problémákat tisztán funkcionálisan leprogramozni, mert ugyebár teljesen eltér a hagyományos imperatív, strukturális nyelvektől, nincsenek ciklusok, elágazások, nem adhatsz értéket változóknak, mindent függvényeken keresztül kell használni, meg rekurzióval trükközni. Nem bírok hozzászokni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
En nem jartam nagyon utana, szoval tevedhetek is, de az eddig leirtak alapjan a forditasi ido annyi, amig az egy fajl/csomag/whatever lefordul, ami egy relative rovid ido (~= azonnal), ellentetben azzal, amikor mondjuk le kell buildelni egy komplett Docker image-t, es azt feltolni valahova, ami siman lehet orakban is merheto, ha eleg nagy a kodbazis.
Ha elég nagy az unison fájl/csomag/whatever, annak is lesz fordítási ideje. Nem a hello.c docker image -be csomagolása és feltöltése a leggyakrabban megoldandó probléma általában.
Blog | @hron84
via @snq-
Igen, errol beszelek. Nalunk az egyik projektnel nagyon nagy a varakozasi ido egy-egy uj valtoztatas kiprobalasakor, mert serverless functionoktol Kubernetesen at minden fiszemfaszom van benne.
Ha az Unison tudna azt, amit a marketing anyag iger, akkor szerintem napi 1 orat meg tudnank sporolni per fo. Azert az nem gyenge. Fel tudnek belole venni +3 embert, vagy ki lehetne osztani a 12%-ot extra fixuemeleskent. Es el lehet utni azzal, hogy de a hello.c meg a Docker, de nem mindenki ilyenen dolgozik, oda ez nyilvan felesleges, ezt asszem nem is vitatja senki, aki kicsit is ertelmes.
Egy másik fórumon feljött a Darklang nyelv, hogy kb. ugyanaz lehet.
Sok a hasonlóság, de alapvetően egészen más. Ezt az összehasonlítást írja AI-ranka:
"hanem azonnal élesbe küldhetik a kódot"
Ahammmm.... nem kell félni, jóóóóóólesssssssssssszzzzzzzzzz!!!! :)
Itt az "elesbe kuldeni" szerintem csak egy szofordulat arra, hogy megirod a kodot, aztan egybol mehet ki "valahova", de ez lehet akar a sajat gepeden futo jatszos sandbox is, nem?
Igen, így van.
Ezt kicsit kifejtem, mert félreérthető. Egy hagyományos nyelvnél kb. ilyen a build folyamata:
Ezeket minden egyes esetben el kell végezni, ha csak a kódbázis (git) van meg, de nincs futtatható állomány és/vagy módosul valamelyik része. Utóbbi esetben sok build rendszer képes bizonyos dolgokat ilyenkor a korábbi buildből felhasználni, így gyorsabb lehet a folyamat.
Unison esetén, amikor a kódot írjuk és elmentjük a fájlt, máris megtörténik a fordítás, ez alapján történik a hibák jelzése (mint IDE-nél). Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető, akkor feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is. Tehát elegendő mindig egyetlen egy fájlban szerkesztenünk az épp fejlesztendő kódot.
Ebben az egy esetben futott a fordítás és a teszt az adott kódra. Többször már nem lesz rá szükség, amíg meg nem változik, de akkor az már új kód. Linkelni sem kell, mert, ha a függőség nincs a kódbázisban, és az adott forrásban sincs, akkor nem fog fordulni sem.
Tehát a kódbázis mindig egy összeépített, futó kódot tartalmaz. A fordítás és teszt futtatás csak egyszer történik meg, a kódbázisba feltöltéskor, többször sohasem.
Ui.:
A kódbázisba tetszőleges definíciót felrakhatunk, pl. akár egyesével a megírt függvényt, vagy típust, ...
Pl. megírunk egy típust, felrakjuk, kitöröljük a forrását, megírunk egy fv-t, felrakjuk, kitöröljük a forrását, ...
Én még így sem egészen értem, de mindegy. Mondjuk ez a Darklang sem világosabb, ezzel a backend rizsával. Ezek most tényleg az évszázad zsenialitásai, és csak én vagyok hozzá túl hülye, vagy oltári nagy kamuk. Mindegy, még nem írom le őket, próbálok nézni róluk anyagokat, hátha megértem, hogy mi hajtja.
Van egy olyan érzésem, hogy ezek a Rust-nál is szarabbak lesznek, mondtam én pár napja a Rust ekézős topikba, hogy vissza fogjuk még sírni azt.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nekem ebből a leírásból olyasmi jön le, mint ha eleve lefordított java class fájlokat tárolgatnánk gitben, amiket utána nem org.example.MyUserImpl67, hanem 0xCAFEBABE formában hivatkozhatnánk meg a későbbiekben (az implementáció részleteitől függően, tehát content-addressed módon). Aztán, hogy a class fájlban egy interface vagy egy metódus implementációja van (granularitás), az már kb. mindegy is. Ilyesmiről van szó?
Igen, ilyesmiről van szó.
Ez egész konkrétan NEM IGAZ. Naponta százszor build-elek annélkül, hogy pl. függőségeket telepítenék vagy kódbázist töltögetnék le (ezeket elég egyszer az elején, nem kell "minden egyes esetben", minden build előtt megtenni).
Mondom én, az a bajod, gőzöd sincs róla, mi a különbség a build és a CI között, mert babzsákfotelfejlesztő vagy és még csak CI által hívott build-et láttál, semmi mást.
Ha egy mondatot kiragadsz és azt sem érted meg, ráadásul a következő mondatot már el sem olvasod, akkor teljes tévképzeteid lesznek.
Kár fröcsögnöd, ha két mondatot egyben már nem tudsz értelmezni!
"Unison esetén, amikor a kódot írjuk és elmentjük a fájlt, máris megtörténik a fordítás, ez alapján történik a hibák jelzése (mint IDE-nél). Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető, akkor feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is. Tehát elegendő mindig egyetlen egy fájlban szerkesztenünk az épp fejlesztendő kódot."
> minden függőség elérhető
Tehát akkor ezt nem spóroljuk meg:
> feltehetjük a kódbázisba az így lefordított kódot. Amint feltettük a kódbázisba, a forrást törölhetjük is.
Valószínűleg ez nem fogja segíteni a fejlesztést. A git se azért checkoutol teljes repositorykat, mert ne tudnánk 1-1 fájlt letölteni és szerkeszteni (a buildot meg megoldja a build szerver) hanem azért is, mert általában a fejlesztés kontextusában történik. Azaz emberként kell látnom a kód többi részét, hogy én tudjam írni a saját kódomat, hiszen függvényeket hívok, változókat használok, stb... Amúgy ezt bármelyik nyelvvel meg tudnám tenni.
> Ebben az egy esetben futott a fordítás és a teszt az adott kódra.
Itt nagyon nagy kérdés, hogy a teszt alatt milyen tesztet értünk. Mert ugye van unit teszt, integration teszt, stb. A teszt külön function?
> Linkelni sem kell, mert, ha a függőség nincs a kódbázisban
Mivel a te scenariodban csak 1 fájlt töltesz le, így a "kódbázis" nem biztos, hogy rendelkezésre áll, tehát valamilyen szintű linkelés kell, legalább annyira, hogy megnézze a "kódbázisban", hogy minden fasza-e. És igen, lehet, hogy ez a fájl mentésekor lezajlik, de a fájl mentése nem atomi művelet, _van_ benne fordítás _és_ linkelés is.
A másik, hogy ha van fordítás-visszafordítás, akkor egy komplexebb függvény esetén ennek a költsége nagyobb is lehet, elképzelhető, hogy érdemesebb lenne a "szerkeszthető", "olvasható" kódot külön is elmenteni, nem csak a compile-olt (byte)kódot.
Blog | @hron84
via @snq-
Szerintem te ezt nem erted (de lehet, hogy en sem)
Nem az a nagy truvaj, hogy egy desktop appon, vagy egy generikus 41684641784. php webshopon kivaltsa a "build idot" ez a cucc. Szerintem ez olyan dolgokra lett kitalalva, ahol nem 1 db jol korulhatarolt git repo van, hanem mindenfele microservice meg akarmi ossze van boritva, es Jenga-zol, hogy ha itt meghuzod az egyik fadarabot, akkor osszedol-e az egesz torony.
Erre a use case-re baromi jo az a logika, amit ebben felfedezni velek. Hogy a Unison konkretan jo-e, arrol fogalmam sincs, de az elkepzeles mindenkeppen eloremutato.
Offtopik, de nagyon regen nem lattam olyan architekturat, ahol a teljes kodbazis ismerete/meglete szukseges lett volna egy-egy feladat megoldasahoz. Kit erdekel, hogy a Hold tuloldalan milyen valtozoneveket hasznalnak? Dolgoztam olyan projekten, ahol 700 fejleszto dolgozott, szerinted erdekelt engem, hogy melyik modul melyik microservice-eben milyen valtozonevek vannak? :)
Az Unison kb arról szól, hogy a saját felhőjükre befizetsz és ők meg az egész felhőbe való natív app fejlesztésre/üzemeltetésre/... (a saját platformjukhoz) adnak egy programozási nyelvet, ami jó sok döntést meghoz helyetted és mindent "lekezel" (helyetted). Ezt lehet tekinteni kb a Serverless/Fn/Lambda/hogyhívjákmég továbbfejlesztésének és úgy néz ki, hogy kellett hozzá még egy ötlet a dep-kezelésre.
De alacsony(abb) szintű dolgokkal nem kell foglalkozni, mert azt "intézi" a platform. ;D
A felhős üzletpolitikájuk nekem sem tetszik egyáltalán. Emiatt könnyen lehet, hogy számomra csak az érdekesség szintjén fog megmaradni.
Akkor neked lehet hogy valójában az Erlang+OTP/Elixir kell (ha ajánlhatok valamit). :D
Igen, a használandó külső library-k megkeresését, letöltését, telepítését nem ússzuk meg, de nem is írtam ezt, az a rész feltételes:
Ha minden rendben, az esetlegesen megírt teszt is rendben lefut és minden függőség elérhető,
Tudod látni a kódot, nagyon jó keresője van, pl. még szignatúrára is tudsz keresni: azon függvényeket listázd, ami Person-t kap és Boolean-t ad vissza. Majd megnyithatom ezeket megnézhetem a kódját, akár át is írhatom.
Kizárólag a unit tesztet.
Biztosan rendelkezésre áll a kódbázis, mert ebben nagyon hasonlít a gitre, van a home könyvtáradban egy saját, oda tudod belepakolni a dolgokat, majd onnan tudod feltölteni egy központi kódbázisba. A nálad lévő kódbázisban is mindennek "faszának" kell lennie.
A fájl mentésekor csak fordítás történik, a kódbázisba tevéskor ellenőrzi, hogy minden függőség rendben van és nem törik-e valami. Ha törne, akkor előbb ki kell javítanod és csak a javítással együtt tudod betenni a kódbázisba. A kódbázisban nem lehet olyan, hogy valami törik.
Itt kb. csak annyi történik, mint IDE-kben az ellenőrzésekkor (igazából még szerintem annyi sem). Nincs számottevő ideje.
Van még kérdés :D
Fedora 40, Thinkpad x280
Tetszik. Architektként kifejezetten élvezem, amikor egy környezetbe egy olyan megoldást hoz be valaki, ami egy teljesen másik környezetben született és annyira más világ, hogy az asszociációt is magyarázni kell.
Ez kb a k8s és az application streaming ötleteinek lehozása forrás szintre.
Egy dolog viszont zavar. Ha minden igaz, akkor ehhez kell egy szent központi "kód" (valójában artefact) tár, ami szigorúan monoton nő. Mindenki ide rakja a cuccait és a futtatás is ettől függ az első indításkor, mert innen húzza be a még hiányzó darabokat. Ez a szent kódtár hogyan skálázható és hogyan nem lesz SPoF? Hasonló volt a docker hub, amíg bele nem pusztultak a storage árába és ennek következtében el nem kezdtek takarítani és az ingyenes hozzáféréseket durván korlátozni.
Igen. Ami érdekes, hogy nem is a program nyelv maga, ami nagy változást okoz, az szinte teljesen Haskell szerű, kivéve az effect kezelés, az egy kicsit újdonság; hanem egy pici szemléletváltás, ami alapjában borítja fel az eddigi gondolkodásunkat a szoftver készítés menetéről.
A legjobb analógia a git (kódbázis) tároló. Ha mindent egy kódbázisba teszel, akkor végtelen méretűre is nőhet, de teheted sokba is akár. Egy nagyot is ki lehet szolgálni egyébként, ahogy a github, gitlab is meg tudja oldani. Ha egy cég összes forrása és annak összes története elfér egy git tárolóban, akkor ebben is el fog férni szerintem. Ám, nem szükséges mindent egybe rakni.
De ha behúzok egy külső függőséget, az lejön az én tárolómba, vagy majd futásidőben kérődik le a gyártótól, azaz egy tőlem független kód tárolóból? Ez a rész elég elnagyolt volt a bevezető anyagban és inkább úgy tűnt, mintha az utóbbi lenne.
Először le kell húznod a függőséget magadhoz, utána tudsz rá hivatkozni csak. Az így lehívott függőség bekerül a tárolódba és akár át is írhatod, átnevezheted, több verzióját is berakhatod, ...
A tárolódba csak úgy kerülhet be bármi is, ha az összes függősége már benn van, vagy vele együtt bekerül.
És hogy fog a függőség frissülni? Ha az adott dependencia külső tárolóban van, honnan fogja az én tárolóm tudni, hogy van új fejlesztés?
Blog | @hron84
via @snq-
Magatol (remelem) sehonnan, hanem amikor en, mint fejleszto ugy dontok, hogy X fuggoseg Y verziojat lecserelem, akkor majd megmondom neki.
Én nem hiszek azokban a "nyelvekben" ahol a nyelvvel együtt egy ökoszisztémát - nopláne terméket - le akarnak tolni a torkodon.
Így hiányzik mögüle az "akadémiai háttér", a valódi elvi újdonság.
Nem hiszem hogy valaha is fog jönni az iparból ilyesmi, az iparnak nem dolga az alapkutatás. A világon néhány cég van ami csinál ilyet (pl IBM) ők lehetnek kivételek.
Néhány dolga nekem is tetszik, szerintem kubernetesék, java-ék le fognak nyúlni belőle ötleteket de önmagában ez a sztori nem áll meg.
Az igazi nagy problémát - mikor szabadulunk meg végre az RDBMS-ektől? - ez se oldja meg.
Stateless "izékkel" a hülye is tud "hősködni". :)
Gábriel Ákos
Ennél a nyelvnél nem akarják az egész ökoszisztémát lenyomni a torkodon. Itt egyedül az az újdonság, hogy git helyett ucm van. Az ucm (Unison Codebase Manager) gyakorlatilag a git, a fordító, az értelmező és a dokumentáció kezelő egyben.
Ez a része nyílt forrású (MIT), bárki szabadon átírhatja, továbbviheti.
Van egy Unison Cloud nevű termékük, ami kb. egy Kubernates szintű dolog, az zárt forrású és fizetős. Ez utóbbi elvileg az RDBMS-ektől is megszabadíthat, mivel elosztott adattárolást is lehetővé tesz. Kis teljesítménnyel tudod használni ingyen ezt felhős szolgáltatással. Részletesebben nem ismerem ezt a részt.
Ui.: Itt nem "stateless izékkel" kell "hősködni". Minden lehet teljesen stateful.
kontra
Na tessék, még egy újabb önellentmondás.
Jobban belegondolva ez a működés teljesen életképtelen.
Legyen például egy egyszerű grafikus alkalmazás, amivel adatokat rögzítenek. A megrendelő azt kéri, adjunk hozzá egy új mezőt. Ekkor módosítani kell:
- a megjelenítést tartalmazó fájlt (pl. Windows-on .res, Mac-en .nib)
- a kontrollert tartalmazó fájlt, hogy az új adatot átadja
- a modellt tartalmazó fájlt, hogy az új adatot fogadja
- az adatsémát kezelő fájlt, hogy tárolja és betöltse az új adatot (mégha memdump is, kezelni kell a korábban lementett, új mezőt nélkülöző adatfájlok betöltését, vagy sikeres teszthez minimum konvertálni kell a korábbi tesztfájlokat)
Egy rakat fájlt kell módosítani ahhoz, hogy a program újra konzisztens állapotba kerüljön és egyáltalán meg lehessen kísérelni a fordítást és a tesztelést (persze belehányhatod az összes komponenst egyetlen egy fájlba...).
Elképzelni sem tudok rosszabb dolgot annál, mintsem hogy azzal pazaroljuk egy programozó drága idejét, hogy minden fájlmentés után várakoznia kell a fordításra és a tesztelésre, még akkor is, ha eleve tudja, hogy garantáltan nem fog menni, mert még nem vitte végig a teljes változtatást.
Nem érted miként működik, így az egész eszmefuttatásod téves.
Ugyan komplett üzleti feature szempontjából igazad lenne, de ha minden elem funkcionális, akkor belülről indulva egy komponens változtatása nem tör működést. Mivel még senki nem hivatkozik rá, mehet élesbe. A sorozat utolsó eleme a felület, így a felhasználó már egy működő láncot kap. Na az viszont érdekes szívásnak tűnik, hogy ez nem is tud másképp működni, tehát ha épp nagyon ráér a frontendes, akkor sem nyúlhat a feladathoz, amíg a többi rész el nem készült, mert még a repo-ba sem tudja feltölteni. Ennek feloldása lehetne, hogy üres mock definíciók készülnek minden komponenshez, ekkor viszont ugye amikor cseréled a mock-ot, változik a hash, az egész lánc összes eleméből új verziót kell kiadni, hogy már az új hash-ekkel legyenek láncolva. Hát nem mondom, hogy az eddigi infók alapján kerek a világkép, de ez lehet betudható annak, hogy nagyon felszínes információk alapján akarjuk megszakérteni azt a részét, ami már jócskán túlmutat a hello world szintjén
Ezzel a részével tökéletesen egyetértek!
Amik kiigazításra szorulnak a fentiekből:
Azt még hozzátenném, hogy itt az ötlet és az abból adódó következmények a forradalmiak, nem a konkrét nyelv és a konkrét megvalósítás. Azért is nehéz még konkrét véleményt mondani, mivel erősen fejlesztés alatt van, még nem egy kikristályosodott rendszer.
> futtatható kell legyen
Valójában itt törik az elmélet. Ugyanis csak úgy tudsz meggyőződni arról, hogy futtatható valami, hogy megfuttatod. Lehet bármilyen okos compilered, hibakeresőd, stb, lehet a kódban olyan logikai hiba, ami a statikus/AST elemzés során nem jön ki, de a nap végén nullával osztunk. Viszont, nem tudod megfuttatni, ha a függőségként behúzott függvények hashei(?) még nem állnak rendelkezésre. Ez kicsit a CD-n szállított CD driver esetének tűnik.
Itt ugyanis nem az önálló fejlesztésről van szó, hanem egy ökoszisztéma elemeinek párhuzamos fejlesztéséről. Ez kicsit mást jelent, ugye van külön backendes és frontendes fejlesztő, a backendes dolgozik az üzleti logikán a frontendes a megjelenítésen, és a jelenlegi nyelveknél ideiglenesen mindketten tudnak stubokkal/scaffoldokkal dolgozni, és majd egyszer a végtelenben találkoznak, viszont a fent vázolt ökoszisztéma esetén nem tudják összelinkelni/összekapcsolni függőség szinten a munkájukat, hogy egyben tudják tesztelni.
Blog | @hron84
via @snq-
A futtatható nem azt jelenti, hogy nem történik benne elszállás a futás során. Ha elindul, akkor futtatható.
Ha a függőséget behúzod, akkor az bekerül a kódbázisba, nem csak a hivatkozás hozzá, hanem a teljes kódja. Tehát a kódbázisban mindig ott van minden, külső dolgot nem kell behozni a futtatáshoz.
Szerintem ugyanúgy lehet fejleszteni, mint minden más alkalmazás esetén. Annyi itt a feltétel, hogy mindig csak futtatható kód kerülhet be a kódbázisba, de a legtöbb helyen ez elvárás, hogy git alá ne tegyünk nem futó (forduló) kódot. A bonyolítást az okozhatja, ha valami több verzióban van, akkor figyelni kell, hogy mi melyiket használja és ne legyen olyan, hogy valami a régi verzión ragad, mert nem figyeltünk oda.
Ezt egy mock implementációval éppen meg tudod kerülni, nem?
Gábriel Ákos
Most mar csak azt kellene elfogadni, hogy nem mindenki desktop appot fejleszt, a mi projektunkben pl. egesz hasznos lenne egy ilyen workflow, amit az Unison tud. Nyilvan nem fogjuk mar a nullarol ujrairni, de belegondolni sem merek, de belengondolni sem merek, mennyi emberora megy el azokkal a pocsolesekkel, amit ez (elvileg) kivaltana.
Lisp szagot érzek! Szerintem már ezt is feltalálták.
Ebből a videóból sokkal jobban megérthető az ötlet és a működése:
"Unison: a new distributed programming language" by Paul Chiusano