Scala 3 / Dotty izelito

https://dotty.epfl.ch/docs/reference/overview.html

 

trait Functor[F[_]]
  def [A,B](a : F[A]) map(func : A => B) : F[B]

trait Monad[F[_] : Functor]
  def [A](a : A) identity : F[A]
  def [A](mma : F[F[A]]) flatten : F[A]
  def [A,B](ma : F[A]) flatMap(func : A => F[B]) : F[B] = 
    ma map func flatten

enum Maybe[T]
  case Some(t : T)
  case Empty()

object Maybe

  given Functor[Maybe] 

    def [A,B](ma : Maybe[A]) map(func : A => B) : Maybe[B] = 
      ma match
        case Maybe.Empty() => Maybe.Empty()
        case Maybe.Some(a) => Maybe.Some(func(a))

  given Monad[Maybe]

    def [A](a : A) identity : Maybe[A] = Maybe.Some(a)   

    def [A] (mma : Maybe[Maybe[A]]) flatten : Maybe[A] = 
      mma match 
        case Maybe.Empty()  => Maybe.Empty()
        case Maybe.Some(ma) => ma
      

@main def m = println(Maybe.Some("a").flatMap(_ => Maybe.Some("b")))

Hozzászólások

Nyugodtan fejezd ki magad bovebben, te is es +1-ezok is ;)

Mi hanyinger? Amit a kod kifejez? Vagy a Dotty a Scala 2-hoz kepest? Esteleg a Scala a Java-hoz kepest?

Mik azok a tenyezok amik ezt a testi erzetet valtottak ki beloled, es miert volt ilyen hatasuk rad? ;) 

Biztos nagyon tömör, de azon is gondolkodni kell, amit látok. Szerintem nem kifejező. Minden olyan törekvést gyűlölök, ami megpróbál valamiféle működést elfedni a felhasználó vagy a programozó elől. Ezért nem szeretem a Windows-t - lakásban nem is tűröm meg, nem való oda :) -, illetve ezért tetszik az assembly. Ott az történik, ami le van írva. Kivéve hardware hibát, de az már védhetetlen ebben az értelemben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

APL/K/J nelvekrol mi a velemenyed? Ugy hangzik mintha jo match lene szamodra. Nagyon tomorek, es ezt a tomorseget altalaban arra hasznaljak, hogy minel kevesebb absztrakcio felhasznalasaval oldjanak meg dolgokat. Minden a szemed elott van, mert elfer.

 

(disclaimer nem sok kozom van hozzajuk, lehet nem teljesen korrekt a velemnyem veluk kapcsolatban, de ezt latom bennuk)

Az APL jelöléseit szokni kell a kívülállónak, mert bár matematikából eredt, de a régimódi nyomtatók (több betűt leütni ugyanarra a helyre: pl.  O + /, amit mátrixtranszponálásra  szokás használni, míg a O + | -t pedig tükrözésre) korlátai miatt lett az, ami. Másrészt különféle nyelvjárások terjedtek el más és más jelölésrendszerrel, és elég problémás volt köztük átmenet, így a kódok publikálása is.

A J már redukálta a jelölést az ASCII-re, emiatt szimpla karakter helyett gyakran kettőt kell használni egy fogalomra. A k még nekem is fekete ló, a bankszektor viszont szereti, főleg a hozzá kapcsolt adatbázisokat (kdb) és lekérdező nyelvet (q). Az általános vélemény szerint ez egy write-only nyelv, ami persze csak sarkítása a dolgoknak. Elvileg kevés fejlesztővel igen hatékonyan lehet dolgozni. Legyen azért valami konkrétum is: az aktuális Advent of Code  k nyelvű megoldásai: https://bitbucket.org/ngn/k/src/master/aoc19/a.k

Azért ezekben a megoldásokban is elég sok függvény lett definiálva, ami szerintem  az absztrakció egy adott formája. Az pedig elég általános, hogy két-három függvény összekapcsolása már új (esetleg érthető) elnevezést kap. Persze a precedencia mentesség, és a jobbról-balra haladás sokak számára már túl van az elviselhetőség határán, bár a műszaki dolgok iránt érdeklődő, de nem a hagyományos programozói iskolákon nevelkedettek elég sikeresek benne.

AL

"Biztos nagyon tömör [...] Szerintem nem kifejező."

Ez a ket dolog igy egyutt kicsit fura, tekintve, hogy altalaban a kettot egymas szinonimajakent hasznaljak. Kanonikus pelda a Perl, ami a kozvelekedes szerint nagyon kifejezo, es ez kez a kezben jar a sokak szerint olvashatatlanul tomor code golf jellegu egysorosokkal.

Nagyon kellemetlen, amikor egy probléma megoldása kapcsán nem a feladattal foglalkozol, hanem elveszi a fókuszt a fejlesztői felület bonyolultsága, vagy az adott nyelv fennkölt absztrakciója, amely elhiszem, hogy egyeseknek - elsősorban ezen nyelvek és eszközök megvalósítóinak - maga az önmegvalósítás, de én látni szeretném, mi az, amit csinálok, s nem szeretnék azon gondolkodni, hogy az amúgy látszólag egyszerű jelölés pont ott, abban a kontextusban mit jelent. Jó, ebben már a C-nek is van sara, amikor típust „szorzunk” változóval. :)

Az is szörnyű, amikor egy felület annyira az ember keze alá dolgozik, hogy ugyanarra a dologra kontextusfüggően más történik. Azért, mert az emberi agynak kényelmesebb a statikus gondolkodás, a rögzített célpontra lövés, minta dinamikusan változó környezethez alkalmazkodás. Így aztán jobb, hatékonyabb az a fapados felület, amely kevésbé szolgál ki, de nem változik, mint az, amelyik megpróbálja kitalálni a gondolataidat. Ez utóbbi azért sem jó, mert lehet, hogy nem azt akarod, amire ő gondol, s ekkor egyenesen küzdeni kell ellene. Mint a szövegszerkesztőkben az automatikus formázás ellen.

Konkrét példát ne kérj, egyszer magamnak csináltam olyan felületet, ami a legvalószínűbb választ tette alapértelmezetté, de hamar rájöttem, ez nagyon fárasztó agyban. Az sokkal jobb, ha a default statikusan ugyanaz, aztán majd kitalálom, akarok-e változtatni rajta.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Minden olyan törekvést gyűlölök, ami megpróbál valamiféle működést elfedni a felhasználó vagy a programozó elől.

Ez azért érdekes, mert a fenti példában szinte* semmi nincs elfedve, a kód pontosan annyit csinál ami le van írva, ez olyan 8 sor összesen. A többi a fordítónak szól, hogy hajlandó legyen ezt a néhány sor érdemi kódot értelmezni. Persze ahhoz képest, hogy mennyit csinál, ez rengeteg kód, de ennyiből kiindulva jó néhány adatstruktúra implementálható.

* az enum elfedi a konkrét implementációt, de olyan nagy varázslat ott nem történik, csak megspórolja a programozónak boilerplate kód implementálását

Ami inkább zavaró lehet, hogy kontextusfüggő, hogy ugyanaz a néhány karakter különböző helyeken mit jelent. Erre a legjobb példa a pattern matching Empty sora:

case Maybe.Empty() => Maybe.Empty()

A case utáni rész egy unapply, a nyíl utáni egy apply.

Ez persze nehézség annak, aki nem olvas minden nap hasonló kódot, de megszokható, szigorú coding style-lal segíthető.

Nyugodtan fejezd ki magad bovebben, te is es +1-ezok is ;)

En akkor nevesitem magam, en vagyok az egyik +1-ezo, szerintem a Scala szintaxisa egy hanyinger. Ettol meg nem egy rossz nyelv, tok sok feladatra alkalmas, de amit szintaxis teren osszehoztak a keszitok, arra nincs mentseg.

Sincerely,
egy Scala fejleszto :)

Mi nem tetszik benne es mi jo szintaxis szerinted? Az uj szintaxisrol mit gondolsz a regivel szemben?

Az en velemenyem, hogy a method signature lehetne maskeppen is megoldva, a tipusok es a nevek keverese fajdalmas es hosszu olvasmanyokat eredmenyez.

Lehetne ehelyett

def [A,B](ma : Maybe[A]) map(func : A => B) : Maybe[B]

ez

[A,B] => Maybe[A] => (A => B) => Maybe[B] def (ma) map (func)

es akkor lehetnenek Haskell-szeruen kulon sorban a tipus es a arg nevek, ha ugy tartja az ember kedve. Ezerszer olvashatobb lenne.

[A,B] => Maybe[A] => (A => B) => Maybe[B] 
def (ma) map (func)

Nem a legjobb pelda, mert ez pont behozza az uj extension method-oket is, de megteszi. Ahol van ertelme ott a sor elejehez oda lehetne gondolni egy "implicit" this-t, extension-oknel epp nincs...

A curried `()()()()()()` szyntaxis is nagyon zajos a jelenlegi formajaban

Persze gondolom ez igy 1000 sebbol verzik, nem vagyok prognyelv designer... de bejonne. Hmm... lehet bekuldom a Scala Contributors forumra.

Vagy csak egyszerűen mi még mást tanultunk, abban vagyunk jók, és erre nem áll rá az agyunk, nem tolunk bele elég energiát.

Nekem a mai médialejátszók is ez a kategória. Szeretem tudni, mi melyik mappában van,... az alapján keresek, azaz keresnék, ha nem rejtenék el mindenféle varázslókkal.

ha neked nem egyertelmu h ez miert egy ordas nagy hanyinger, es miert alkalmatlan arra hogy ebben barki produktiv kodot irjon a szellemi maszturbalason tul, akkor sajnos kar magyaraznom.

mert azt vagod, hogy egy igazi cegben a buksisimi nem azert jar hogy Tomika milyen nagyon gyonyorure irja meg scala5++-ban, hanem arra, hogy a termek elkeszuljon, es a funkcio idore le legyen implementalva?

na, ebben ez a fostaliga nem segit.

teljesen komolyan gondoltam, amit irtam. amig az egyetemen tanitottam is, lattam sok hasonlo PhDs "kutatot" akik epp akkor F#-ra vertek, hogy dejo, azota pedig tobb kollegam is a haskellre onanizal. aztan?

ismerek tobb startupt is aki elindult hogy "na majd mi megmutatjuk", szoptak haskellban, aztan mi lett belole? semmi. vagy hamvaba halt a startup, vagy atvaltottak masra, mint a rust pl.

a szoftverfejleszto az bantuneger, akinek az a dolga, hogy a funkciot megvalositsa, SENKIT nem erdekel, hogy miylen szep a kodod. SENKIT.

(egy startupban raadasul vegkepp nem arra kene idot pazarolni hogy "ahhhh monad ahhhhh pure function ahahahhahahahhhhhhhh" hanem az uzleti logikat implementalni hogy legyen $$$$)

HTH

Ez egészen addig igaz, amíg a ronda kód karbantartása nem lesz drágább, mint újraírni az egészet 0-ról. Persze ilyenkor nem lehet felelősségre vonni a ronda kód elkövetőjét, főleg mert ez egy csapatmunka. Nálam a ronda kód kiadása nagyjából ekvivalens a szalvétán, szabad kézzel tervezett házzal. Csak utóbbit nem lehet keresztülverni egy főépítészen, előbbit picit könnyebb egy code review-n.

A stilust kifogasoltam, nem a tartalmat.

Nyilvan a melohely nem arra valo, hogy a kategoriaelmelet titkait furkesszuk ott. Az is igaz, hogy a technologiai adossag managementje mast-mast kivan meg kulonbozo helyzetekben. Mondjuk te nem ezt mondod, hanem azt, hogy a karbantarthatosag kerdese lenyegtelen. Igen, korai fazisban levo startupoknal eltorpul, de nem abbol all a vilag, valamint elobb-utobb nekik is igy vagy ugy meg kell fizetniuk ezt az adossagot. Nem gondolom hogy total hulyeseget mondasz, de szerintem nagyon extrem allaspontod van ami ebben a formaban csak limitalt korulmenyek kozott tud mukodni, limitalt ideig.

Felhoztal ket jo peldat. A monad azert jo, mert ha tudod mi az lett egy olyan kalapacsod ami rengeteg probelmat szogge varazsol, ami csokkenti a cognitive load-ot, ami atfordul sebessegbe. Az, hogy pl nem kell continuation passing style-t irni es olvasni ha eloveszed, szinten. Ami a pure function-oket illeti, az is rengeteg idot sporol meg, ha nem kell kibogaraszni, hogy a fuggvenyed hol valtoztat meg mit 8 osztallyal odebb es ez hogy interagal minden massal, az is rengeteg idot sporol meg. Mondjuk ez sarkitas mert amugy is antipattern, law of demeter meg minden, de kevesbe extrem esetekben is rengeteg idot sporolok meg, ha tudm, hogy x, y bemegy, z kijon, es mas nem tortenik.

Innen nezve a kodminoseg es karbantarthatosag mar-mar csupan hab a tortan, az altala megsporolt ido penzesitheto valtozo.

Amire nincs szukseg, az az hogy tenyleg tele legyen tomve a kod mindenfele kategoriaelmelettel meg absztrakt algebraval, semigroupoidokkal meg prepromorfizmusokkal, az a masik extrem, maskepp megterhelo/lassito es tenyleg atcsap intellektualis onanizalasba.

Ez egy spektrum, es en eleg hatarozottan az egyik fele mellett teszem le a garast.Te viszont ugy tunik ennek a spektrumnak az egyik extrem vege mellett ervelsz, ami szerintem csak limtalt korulmenyek kozott mukodokepes, limitalt ideig.

kifogasolhatod a stilust amennyire akarod, ez van. en legalabb megmondom a frankot, te pedig elbujsz technicus terminusok moge. okosabbnak erzed tole magad? ;-)

az en allaspontom a gyakorlat szulte, szoftverfejlesztok kozott vagyok illetve en is ezt csinalom mar lassan 15 eve, lattam kis ceget, startupot, multit, lattam olyat ahol a penz volt szarasig, termek sose kellett igazabol, ido meg mint a tenger (tipikusan egyetemi illetve kutatohelyek).

na, amit irsz, az ezekre igaz. ott lehet ilyenekkel jatszani. minden mashol le van szarva, mert az ido diktal, ott a PM, hogy ez a funkcio tegnapra kell, es bele kell takolni, ahogy irtam: senki nem fogja Tomika buksijat simogatni hogy de gyonyoru ez a kod, meg van bocsatva a 3 honap keses ;-)

Pont akartam írni, hogy ez kb. annyira élvezhető, mint anno a Prolog/SML volt. Kívánom, hogy hajlani háromkor valakinek ilyen kódot kelljen néznie, aztán majd leszokik róla...

Én nagyon régóta java-zom, és meg kell erősítenem, hogy azt eléggé jól eltalálták: egyszerű, átlag fejlesztő számára is megugorható szint, amiben bizonyítottan lehet nagy

rendszereket építeni. Elég gyors, van hozzá baromi jó tooling, és fejlesztőt is lehet találni.

Nekem a Koltin sokkal jobban bejött mint a Scala. Éreztem, hogy vagy én vagyok túl buta, vagy a Kotlin sokkal inkább ipari és nem tudományos célú :)

arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout

Ezek a koncepciok egybkent tobbnyire amugy Scalaban is el vannak rejtve a programozo elol es nem is tudjak, hogy hasznaljak oket.

Hacsak nem valamilyen functional librarynek vagy a contributora, az elejen semmikeppen nem kell beleasnod magad, utana meg ugy is bele fogod, mert erdekes tema.

 

Egyebkent akarmikor amikor meghivsz egy map functionat Kotlinban egy Functort hasznalsz, csak nem erdekel, nem tudsz rola, ugyanigy Scalaban is hivhatsz te Option-re map-et, flapMap-et, meg fold-ot anelkul, hogy tudnad hogy az Option egy Monad.

A problema inkabb az, hogy a kozoseseg nagyresze aki hasznalja ezt a nyelvet elegge elitista/egoista modon teszi ezt es nagyon szereti felhozni ezeket a koncepciokat a halando programozoknak, hogy ezzel is erositse sajat felsobbrenduseg tudatat.

 

A valosagban Scalaban is lehet Java szeru/szintu kodot irni, mit ahogyan Kotlinban is es ezt is lehet hybrid OOP-FP nyelvkent hasznalni.

A legtobb helyen ahol valamilyen tenyleges problemat oldanak meg a nyelvvel es nem a sajat vallukat veregetik ott tobnyire igy is van hasznalva.

 

- A type inference adta okossagokat hasznaljak, hogy minel tobb problemat kiszurjenek forditasi idoben.

- Probalnak immutable adatstrukturakat hasznalni

- Probalnak minel tobb functiont irni lehetoleg side effect nelkul

- Van meg egy kis function composition, currying 

 

Es ennyi...

 

Szoval igazabol Java utan a Kotlin lenne a gateway drog a Scalahoz, csak cumminity elriasztja az embereket.

A Kotlin jobb "jobb Java" mint a Scala.

A Scala rosszabb "jobb Java" mint a Kotlin.

A Scala jobb prognyelv mint a Kotlin (es a Java).

 

En igy latom a harom nyelv kapcsolatat, amibol az kovetkezik szamomra, hogy mas-mas preferenciara alapozva mindketto lehet a jobb valasztas a masikkal szemben. Viszont mindkettot szigoruan jobbnak tartom a Java-nal. 

Maradok az assembly, C, awk, bash környékén. Azt hiszem, megöregedtem. Engem kifejezetten irritál, ha a jelölésen is gondolkodnom kell. Szeretem a földhöz ragadt dolgokat, amelyben látom, mi a fene történik többé-kevésbé pontosan.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mindenkinek a sajat izlese szerint, en meg a bash-t kerulom amennyire csak lehet. Nincs olyan negativ erzelmi (lol) reakciom amikor szembejon, mint Javascript/Typescript/stb eseten, de utoljara amikor azt mondtam magamnak, csak meg kene tanulni rendesen szkriptelni, 30 percre ra valahogy megintcsak itt talaltam magam, elment tole a kedvem.

Szoval... nehez a js-nel lejjebb menni a szememben prognyelv minoseg teren (php-t hal' isten nem probaltam meg), de a shell scripting legtobb formajat rosszabbnak tartom. Szerencsere fokepp interaktivan hasznalom, es ugy nincs vele bajom.

C-t se szeretnem a tobb a footgun mint a feature termeszetevel, de a vashoz kozeli vagy embedded programmozas erdekes, es sajnos nem volt sok szerencsem hozza. Majd egyszer, ha rakapok a Rust-ra :)

Nincs baj azzal ha ket ember mast gondol, amig el tudjak fogadni, hogy mint a sajat mint a masik velemenye szubjektiv. Kicsit meta, de a hetekben kezdett kicsit kikezdeni, hogy a legcsekelyebb egyetnemertes is vallasi haborukent van kezelve jelen tarsadalmunkban.

 

Szerk.: Scala2 problemairol is kulon konyv van amugy, es Odersky is vallat rantott kamera elott azt mondva, volt koztuk olyan amire o sem tudta a valaszt, ezert (is) lesz Scala 3

Az, hogy a JavaScript mennyire jó vagy sem szerintem a TypeScripten keresztül mérhető le tökéletesen. Utóbbi gyakorlatilag egy típusrendszer a JS felett, nem nagyon* tudsz olyan kódot írni TS-ben ami a típusok strippelése után ne lenne valid JS, és nem nagyon* tudsz olyan JS kódot írni amihez ne lehetne TS típusdefiníciókat írni. A TS kétségtelenül jobb nyelv, de JS-ben is rendelkezésre áll az összes TS-ben engedélyezett nyelvi konstrukció. Ha meg már egy nyelv van annyira konzisztens, hogy teljesen le lehet írni a típusrendszerét, annyira talán nem lehet rossz.

* nyilván vannak kivételek

A shell scripting**, legnagyobb problémája szerintem, hogy ez az egyetlen általam ismert típustalan nyelv. Bármi érdemi dolgot akarsz csinálni a nyelvben azt csak stringmanipulációval teheted meg mivel nem ismer más típust. A visszatérési értékre inkább mint program state tekintek, ha változóba rakod onnantól az is string.

** feltételezem bash, mint de-facto standard *nix shell script nyelv

Nem a TypeScriptről beszéltünk és nem is az ECMAScriptről, hanem a JavaScriptről. Irreleváns, hogy a nyelv mennyire konzisztens, ha az implementáció nem az. Azonfelül maga a nyelv is agyrém.

var kecske = document.getElementById("ilyen_nincs");
alert(typeof kecske); // will alert "object"
alert(Math.pow(Math.random(), kecske)); // will alert "1"

 

(Rosszul feltételezed: sosem írok bash-only kódot. Amúgy is, mi az, hogy a "de-facto standard *nix shell script nyelv"? A bash nem a nyelv, hanem az interpreter; a nyelv, az a UNIX shell script, a bash-only nyelvi elemek, azok kiterjesztések, amik az interpreterben vannak. Azonfelül a POSIX leírja, hogy mi az igazi standard, tehát nincs szükség de-facto standardekre.)
Látod, erre mondtam, hogy rosszul használják és rosszra. Shellben nem "programozunk", shellben automatizálunk valamit; a shellt arra találták ki, hogy a különféle programok/(non-shell )scriptek ki és bemeneteit összekötögethesd, hogy automatizálhass bizonyos folyamatokat és ezzel megspórold azt a csomó munkát, amíg ezeket begépelted volna a terminálba.
És itt jön képbe, hogy az, hogy shellben minden string, az nem probléma, hanem szükségszerű, mert egy terminálban nem is lehet más egy változó, mint string, azaz bytestream, hiszen a programok a terminállal az stdin/stdout/stderr descriptorokon keresztül kommunikálnak, egy descriptor számára meg nem létezik semmi más, csak byteok sorozata. Azonfelül shellben tkp. nem nagyon létezik olyan változókkal kapcsolatos művelet (hangsúlyozom változókkal való operálásról beszélek, nem a csövek ide-oda kötögetéséről) ami nyelvi elem és nem egy parancs, vagy annak argumentuma. (Úgy egész konkrétan a stringek konkatenációját leszámítva hirtelen nem is jut eszembe semmi.) Ennek megfelelően a típusoknak sincsen az ég egy adta világon semmi értelme, hiszen a műveletet végző parancsprogram is stringként kapja meg a bemenetet és stringként is adja vissza a kimenetet; ha lennének típusok az csak hóttfelesleges typejugglinghoz - és overheadhez - vezetne. Az if-nek is, amit beadsz feltételnek, azt nem a shell vizsgálja, hanem a test parancs, vagy a [ parancs. Aritmetikai műveletet is az expr (és tsai.) segítségével végzel. És ezek a parancsok mind stringekkel operálnak. Nincs értelme más "típusnak".
Nagyon sokan azt hiszik, hogy a shell az Yet Another Scripting Language, ami orbitális tévedés. A shellscripting egy teljesen más műfaj, mint a "normál" scripting.

Szerkesztve: 2019. 12. 20., p - 19:39

Mellékszál: ahogy elnézem, tükörben átítható ez a példa Rust-ra.

enum Maybe[T] ---> Rust Option<T> ... https://doc.rust-lang.org/std/option/
map --> Rust iterátor map ... https://doc.rust-lang.org/std/iter/struct.Map.html
flatten --> Rust iterátor flatten ... https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flatten
flatmap --> Rust iterátor flatmap ... https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flat_map
trait és object --> Rust trait és impl: https://doc.rust-lang.org/rust-by-example/trait.html

Szóval minden rendelkezésedre áll, hogy tükörben átírd Rust-ra ezt a példát.

Nem csodalkozom. Rust jo cucc. Szerintem egy olyan vilagban ahol az emberek velemenyet kevesbe hataroza meg mit szoktak meg [1] C/C++/embedded/systems programming korokben futotuzkent kene terjednie evek ota.

Na de majd a Rust#, ugy hallom a manapsag jofej (tm) Microsoft sajat verzion dolgozik ahelyett hogy betolna az eroforrasait a kozosbe, mint anno a J# majd kesobb (a Javanal amugy jobb) C# eseten :(

 

[1] -  Dotty eseten is volt hajciho egyebek mellett pl. amikor opcionalissa  tettek a {}-t, ha mar itt tartunk

A Go-t annó megnéztem, azon kívül hogy automatikus memóriafoglalása van, meg néhány modern dolog alapból való támogatása, nyelvileg nem láttam semmi egetrengető újdonságot a C++ vonalhoz képest. Rust esetén a borrowing, lifetime, alapból safe megoldások, a makacs típusosság ahol például az f32 és f64 is csak explicit konverzió után hozható össze, a "force UTF8", ... Szóval sok dolog, ami megkerülhetetlenül*** fegyelmet teremt az "okosban megoldjuk" kísértés letörésére.

*** megkerülhetetlenül: unsafe { ... } kulcsszóval jelzett rész az egyetlen (forráskódban így könnyen megtalálható) megkerülési lehetőség, amire vannak esetek hogy szükség van. Viszont ekkor ez a kulcsszó látványosan ott van, amit illendő kizárólag olyan esetben használni, ahol tényleg indokolható.

Persze innentől nem az "átlag indiai" nyelve, ezt a nyelvet tényleg szokni kell. Ha a megszokás sikerül, onnantól megszereted.

Ha például Regexp-et csinálsz, abban az esetben nem a Python algoritmuson van a hangsúly, hanem a C-ben írt regexp rész. Ezért ebben az esetben nincs különbség.

Az FFT tesztemet megnézve, ahol magát az FFT algoritmust programoztam le, azaz mindent a nyelv csinált, 4-szeres tempó van a Rust és PyPy3 között. Rust és cPython3 között 75-szörös a különbség.

Egy spéci mérésiadat log elemzőm esetén a PyPy3-hoz képest 6-szoros sebesség különbséget mértem ARM Cortex A8 lapkán. Így ott is a Rust nyert.

Igen, többször lemértem és ezért módosítottam.
Az viszont általánosságban elmondható, hogy cPython --> PyPy --> Rust ha kell a tempót növelni. És amint írtam, ha nem a nyelv, hanem a háttere dolgozik, akkor kevésbé lesz nyereség.

Felvázolom a legegyszerűbb szélsőséges teszt kódot, tisztán aritmetikára: 47 másodperc cPython3 esetén, 0.84 PyPy3 esetén és 0.135 másodperc Rust-1.40 fordítóval i5-3337u procin (time ./teszt.py).

#!/usr/bin/python3

def szamol(v):
    res = 0
    for i in range(v):
        for j in range(v):
            res += i + (j^1)
    return res

print (szamol(20_000))

 

Alábbi Rust kód lefordítása:  rustc -O teszt.rs

fn szamol(v: i64) -> i64 {
    let mut res = 0;
    for i in 0..v {
        for j in 0..v {
            res += i + (j^1);
        }
    }
    return res;
}

fn main() {
    println!("{}", szamol(20_000));
}

Minden sort imadok. Lehet kene futnom meg egy kort a Scalaval.

Ezek inkább a library fejlesztőknek szóló jóságok.
A sima programozókat, akik inkább csak napi szinten használják a nyelvet, vagy még inkább azokat, akik csak hagyományos nyelveket és megoldásokat ismernek, azokat csak elijeszti a fenti.

Opaque type alias, intersection és union type -os példák sokkal inkább vonzóvá tudják tenni az újdonságok közül.

Összességében egyébként egyszerűbb és könnyebben érthető lesz a nyelv.