Jer pitanje nije: koji će thread imati pristup objektu, već koliko će thread-ove imati pristup objektu u istom trenutku. Ako izuzmeš globalne objekte, objekti su uglavnom dostupni samo jednoj niti - ona koja ih je napravila. Ukoliko želiš da deliš podatke između niti, moraš proslediti objekat kroz kanale (čime daješ ownership thread-u na drugom kraju kanala i source thread ne može više da mu pristupi), ili koristiti mutex koji garantuje da samo jedan thread ima pristup u jednom trenutku - svaki drugi pokušaj rezultuje u greški u prevođenju.
Kod koji daje neočekivani rezultat
Zaključano
Zakačeno
Citat:
Burgos:
Ne, Rust jezik (bez stdlib dodataka kao Rc) ne koristi reference counting (koji se dešava prilikom runtime-a) već praćenje vlasništva nad objektima tokom kompajliranja. Pravila koja nameće nisu tu da bi sprečili kružna pokazivanja (iako je to nuspojava) već radi sigurnosti i efikasnosti izvršavanja:
1. pošto samo jedan entitet može biti vlasnik objekta, kada se završi život objekta, objekat se može uništiti, bez brige da li neki drugi entitet drži isti objekat - nema potrebe za reference countingom.
2. Ukoliko je vlasništvo preneseno drugom entitetu, prvobitan vlasnik ne može ni na kakav način da pristupi objektu, jer to može dovesti do situacije da je novi vlasnik uništio objekat, i pritom omogućava drugom vlasniku da uništi objekat kada želi/čim mu više nije potreban.
Sve ovo se dešava prilikom kompajliranja, i zna se da, ako se program uspešno kompajlira, program radi ispravno bez ikakve provere/reference counting-a/skupljanja đubreta tokom izvršavanja programa.
Citat:
Koliko znam, Rust koristi reference counting, a pravila koja nameće, a koja se proveravaju u fazi prevođenja, sprečavaju pravljenje kružnih pokazivanja, tako da reference counting može da funkcioniše
Ne, Rust jezik (bez stdlib dodataka kao Rc) ne koristi reference counting (koji se dešava prilikom runtime-a) već praćenje vlasništva nad objektima tokom kompajliranja. Pravila koja nameće nisu tu da bi sprečili kružna pokazivanja (iako je to nuspojava) već radi sigurnosti i efikasnosti izvršavanja:
1. pošto samo jedan entitet može biti vlasnik objekta, kada se završi život objekta, objekat se može uništiti, bez brige da li neki drugi entitet drži isti objekat - nema potrebe za reference countingom.
2. Ukoliko je vlasništvo preneseno drugom entitetu, prvobitan vlasnik ne može ni na kakav način da pristupi objektu, jer to može dovesti do situacije da je novi vlasnik uništio objekat, i pritom omogućava drugom vlasniku da uništi objekat kada želi/čim mu više nije potreban.
Sve ovo se dešava prilikom kompajliranja, i zna se da, ako se program uspešno kompajlira, program radi ispravno bez ikakve provere/reference counting-a/skupljanja đubreta tokom izvršavanja programa.
No to ne sprecava Rust implementore da naprave Rc/Arc strukturu :P
Znaci nije deo jezika ali funkcionise kao shared_ptr kod C++-a.
Bez Rc strukture tesko da bi mogla da se implementira bilo kakva dinamicka struktura podataka....
mmix:"Na kapiram, kako onda ti sa Rustom mozes da napravis multi-threaded kod? kako moze kompajler da predividi koji thread ce u kom trenutku imati pristup objektu?"
vrlo lako, samo pokrenes thread i kraj, sad ima i async koji krije mt kod u okviru jezika. E sad kveker sa threadovima je isti kao i ostala pravila koja je Burgos naveo +
sto mora objekt neki da podrzava Send i Sync traitove da bi se predao threadu i mogao da ih menjas inace nista iz threada ne mozes da promenis.
Naravno imas Mutex/Arc i slicne pomagalice koje prikrivaju to pa mozes menjati.
vrlo lako, samo pokrenes thread i kraj, sad ima i async koji krije mt kod u okviru jezika. E sad kveker sa threadovima je isti kao i ostala pravila koja je Burgos naveo +
sto mora objekt neki da podrzava Send i Sync traitove da bi se predao threadu i mogao da ih menjas inace nista iz threada ne mozes da promenis.
Naravno imas Mutex/Arc i slicne pomagalice koje prikrivaju to pa mozes menjati.
Inace Rust ima raw (* pointer-e) koje mozes zawrapovati u unsafe blokove i nista od restrikcija onda za njih ne vazi. To se zakopava
u lib i onda odozgo imas privid da je sve dendi. Zapravo bez raw pointera malo sta fundamentalnmo moze da se implementira u Rustu.
Da bi zeznuo reference checker ljudi prave clone metode koji samo prave laznu kopiju da bi kompajler mogao da se prevari :P
u lib i onda odozgo imas privid da je sve dendi. Zapravo bez raw pointera malo sta fundamentalnmo moze da se implementira u Rustu.
Da bi zeznuo reference checker ljudi prave clone metode koji samo prave laznu kopiju da bi kompajler mogao da se prevari :P
Ali to je BS. Ja vidim da se ljudi nesto loze na taj Rust, ali meni deluje kao potpuno retardiran jezik namesten da javascript-level mindsetovi mogli da prave metal-level i sistemski code. Dalja idiokratizacija struke.
U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC. Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.
U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC. Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.
Potpis
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Poenta je sledeća:
Rust je razvila Mozilla fondacija za potrebe razvoja FireFox-a. Otkako je izašao FireFox Quantum, koji je napisan u Rust-u, nasuprot ranijem FireFox-u, koji je bio pisan u C++-u, FireFox Quantum radi dosta brže, a možda se i brže razvija.
To je poenta.
Rust je razvila Mozilla fondacija za potrebe razvoja FireFox-a. Otkako je izašao FireFox Quantum, koji je napisan u Rust-u, nasuprot ranijem FireFox-u, koji je bio pisan u C++-u, FireFox Quantum radi dosta brže, a možda se i brže razvija.
To je poenta.
Potpis
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
Pa poenta je onda da je stari Mozilla kod bio trash. Ne znaci da Quantum ne bi bio brzi da je krsteno napisan ispocetka u C++u i da je zasluga ubrzanja u Rust-u. Stalno se potencira ta brzina, a sve je "should" and "would". "Mi smo bajbolje ali LLVM nas zeza", itd, itd.
Malo se brkaju teze ovde. Jedna je stvar sto firme hoce da predju sa C++ na Rust zbog prevalentnog raspadanja IT skolstva fokusiranog na davanje fakultetskih diploma pyhon/javascript imbecilima. Taj aspekt mogu da razumem, da si kao firma u problemu da nadjes ljude koji znaju dobro da programiraju dalje od osnovnih struktura i pozivanja biblioteka koje je neko treci napisao, taj problem i mi imamo kontinuirano. A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio. Mogao si onda da napravis i biblioteku za python i da je pozoves iz pythona. Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.
Malo se brkaju teze ovde. Jedna je stvar sto firme hoce da predju sa C++ na Rust zbog prevalentnog raspadanja IT skolstva fokusiranog na davanje fakultetskih diploma pyhon/javascript imbecilima. Taj aspekt mogu da razumem, da si kao firma u problemu da nadjes ljude koji znaju dobro da programiraju dalje od osnovnih struktura i pozivanja biblioteka koje je neko treci napisao, taj problem i mi imamo kontinuirano. A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio. Mogao si onda da napravis i biblioteku za python i da je pozoves iz pythona. Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.
Potpis
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
1Sviđa mi se :thumbsup: 1
Citat:
Branimir Maksimovic:
No to ne sprecava Rust implementore da naprave Rc/Arc strukturu :P
Znaci nije deo jezika ali funkcionise kao shared_ptr kod C++-a.
Bez Rc strukture tesko da bi mogla da se implementira bilo kakva dinamicka struktura podataka....
No to ne sprecava Rust implementore da naprave Rc/Arc strukturu :P
Znaci nije deo jezika ali funkcionise kao shared_ptr kod C++-a.
Bez Rc strukture tesko da bi mogla da se implementira bilo kakva dinamicka struktura podataka....
Da, zato sam rekao "bez stdlib dodataka kao Rc" koje se implementiraju vani :-).
Citat:
Ali to je BS. Ja vidim da se ljudi nesto loze na taj Rust, ali meni deluje kao potpuno retardiran jezik namesten da javascript-level mindsetovi mogli da prave metal-level i sistemski code. Dalja idiokratizacija struke.
Ne znam, ne delim isto mišljenje. Mislim da bi osobe sa JS pozadinom imale velikih problema sa Rustom. Dolazeći iz C i C++ sveta, oberučke prihvatam svaku pomoć
u tome da sam više siguran kada prosledim softver na stotine hiljada (možda i milione) mašina, da će raditi najbolje što može. Ne radi se ovde o osnovnim strukturama i pozivanju biblioteka, mi pišemo naše biblioteke, implementiramo nove algoritme i pripadajuće strukture podataka, ali je kompleksnost ogromnog projekta nešto što strašno jede produktivnost. Pomoć jezika u ovome je nešto vrlo dobrodošlo.
Citat:
U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC.
U većini slučajeva ne moraš :-). Kao što ni u većini slučajeva u C++ kodu ne koristiš raw pointere, već value-based semantiku. Čak ni za polimorfizam u C++-u (slično kao i u Rust-u), nisu potrebne reference. Sada, kao i u C++u, i u Rust-u su potrebni hardware abstraction layer-i, optimizovani vektori, itd. Kao i u C++u, Rust omogućava da se dođe do samog hardvera. Pogledaj ovu moju škrabotinu sa kojom sam pre par godina se igrao sa rust-om i ARMom: https://github.com/Burgos/micoos/ - svi viši layeri (kao što je process, msgbox, timer, scheduler ...) nemaju unsafe delove, dok za samo rvanje sa registrima korisim asm. Što znači da mi kompajler daje sigurnost kako rade viši delovi, naravno, sve dok mogu da garantujem za niže delove. U C++-u, sigurnosti nema ni za više, ni za niže slojeve.
Citat:
Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.
Send/Sync su deo tipa i nemaju runtime overhead, koliko znam.
Citat:
A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio
Ne znam na osnovu čega misliš da si primoran da radiš protiv njega? Naravno da ne možeš da pišeš na isti način na koji bi pisao u C-u, ali možeš vrlo lako i produktivno da pišeš kod, bez da se osećaš oštećen i da radiš protiv kompajlera, samo je paradigma drugačija. Meni je teže da pišem kod u Python-u, nego u Rust-u, a provodim slično vremena nad oba jezika (~10% nedeljno).
Citat:
Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.
Kao nekome ko je proveo malo vremena sa njim, meni deluje sasvim drugačije. Ne kažem da je panacea, ali ne mislim ni da je drop in zamena za C da bi se JS programeri osposobili za bare metal programming.
Citat:
mmix:
Ali to je BS. Ja vidim da se ljudi nesto loze na taj Rust, ali meni deluje kao potpuno retardiran jezik namesten da javascript-level mindsetovi mogli da prave metal-level i sistemski code. Dalja idiokratizacija struke.
U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC. Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.
Ali to je BS. Ja vidim da se ljudi nesto loze na taj Rust, ali meni deluje kao potpuno retardiran jezik namesten da javascript-level mindsetovi mogli da prave metal-level i sistemski code. Dalja idiokratizacija struke.
U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC. Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.
Pazi, Rust uopste nije za pocetnike. Ja sam se jedno par godina mucio da skapiram kako sta da izvedem a da ne radim thinkering i botbu sa kompajlerom. Overhead nema za send i sync to je samo formalnost,
tj kompajler samo proveri da li je trait implementiran za strukturu nista od toga ne postoji u kodu kad se iskompajlira. U rustu se traitovi koriste za genericko programiranje, vrlo retko
ih koristis bas kao interface( kao u C# ili Javi) pa da ima taj dynamic dispatch overhead.
Citat:
mmix:
Pa poenta je onda da je stari Mozilla kod bio trash. Ne znaci da Quantum ne bi bio brzi da je krsteno napisan ispocetka u C++u i da je zasluga ubrzanja u Rust-u. Stalno se potencira ta brzina, a sve je "should" and "would". "Mi smo bajbolje ali LLVM nas zeza", itd, itd.
Malo se brkaju teze ovde. Jedna je stvar sto firme hoce da predju sa C++ na Rust zbog prevalentnog raspadanja IT skolstva fokusiranog na davanje fakultetskih diploma pyhon/javascript imbecilima. Taj aspekt mogu da razumem, da si kao firma u problemu da nadjes ljude koji znaju dobro da programiraju dalje od osnovnih struktura i pozivanja biblioteka koje je neko treci napisao, taj problem i mi imamo kontinuirano. A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio. Mogao si onda da napravis i biblioteku za python i da je pozoves iz pythona. Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.
Pa poenta je onda da je stari Mozilla kod bio trash. Ne znaci da Quantum ne bi bio brzi da je krsteno napisan ispocetka u C++u i da je zasluga ubrzanja u Rust-u. Stalno se potencira ta brzina, a sve je "should" and "would". "Mi smo bajbolje ali LLVM nas zeza", itd, itd.
Malo se brkaju teze ovde. Jedna je stvar sto firme hoce da predju sa C++ na Rust zbog prevalentnog raspadanja IT skolstva fokusiranog na davanje fakultetskih diploma pyhon/javascript imbecilima. Taj aspekt mogu da razumem, da si kao firma u problemu da nadjes ljude koji znaju dobro da programiraju dalje od osnovnih struktura i pozivanja biblioteka koje je neko treci napisao, taj problem i mi imamo kontinuirano. A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio. Mogao si onda da napravis i biblioteku za python i da je pozoves iz pythona. Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.
Znas kako, mnogi C/C++ programeri se slazu sa tobom. Ali stvar je u tome da kad jednom napises Rust program on nema klasicnih problema kao recimo C++. No delepoing time je veci u Rustu zbog toga. Nisam bas siguran
da jezik koji je sebe napravio takvim da produzava vreme razvoja i ne koristi GC, da je usmeren Python/JS programerima, al ajde. Jezik koji jeste usmeren Python programerima je Go i to je sasvim druga kategorija.
Rust je prevenstveno namenjen za funkcionalno programiranje, a ne objektno-orjentisano. Nije ista paradigma.
Dakle, nudi sigurnost za safe deo, koji je gro projekta, pod pretpostavkom da su osnovne strukture koje su ostale unsafe dobre, a one čine mali deo projekta.
Sve to može i u C-u ručnim vođenjem računa o svemu, ali ovde jezik pomaže oko te provere.
Dakle, nudi sigurnost za safe deo, koji je gro projekta, pod pretpostavkom da su osnovne strukture koje su ostale unsafe dobre, a one čine mali deo projekta.
Sve to može i u C-u ručnim vođenjem računa o svemu, ali ovde jezik pomaže oko te provere.
Potpis
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
Tako je, ML deo jezika je baš puslica, mada je Rust imperativan, kao uostalom ML familija...
Cini mi se da pukovnik Linus rekao jednu-dve pohvalne reci o Rustu
https://www.theregister.com/20...nux_maintainers_says_torvalds/
https://www.theregister.com/20...nux_maintainers_says_torvalds/
Ocekivano, ako misli da se sa ovim nastavi:
he said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."
Ko god je kompajlirao kernel zna koliko se kompajliraju drajveri, pausalno 90% vremena se provodi kompajlirajuci drajvere...
Citat:
he said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."
Ko god je kompajlirao kernel zna koliko se kompajliraju drajveri, pausalno 90% vremena se provodi kompajlirajuci drajvere...
@Branimir Maksimovic
Pa, funkcionalno programiranje je takođe imperativno. Skoro svo programiranje je imperativno.
Imperativno programiranje podrazumeva da se mašini ne opisuje problem koji rešava, već postupak rešavanja problema.
Deklarativno programiranje podrazumeva da se mašini opisuje problem koji se reševa, a ne postupak njegovog rešavanja.
Primer ovog drugog je prolog. Tamo se opisuje problem u vidu sistema logičkih formula i definicija u određenoj sintaksi, pri čemu su te formule takve da postoji opšti algoritam za rešavanje takvih sistema, koji je ugrađen u implementaciju jezika.
Pa, funkcionalno programiranje je takođe imperativno. Skoro svo programiranje je imperativno.
Imperativno programiranje podrazumeva da se mašini ne opisuje problem koji rešava, već postupak rešavanja problema.
Deklarativno programiranje podrazumeva da se mašini opisuje problem koji se reševa, a ne postupak njegovog rešavanja.
Primer ovog drugog je prolog. Tamo se opisuje problem u vidu sistema logičkih formula i definicija u određenoj sintaksi, pri čemu su te formule takve da postoji opšti algoritam za rešavanje takvih sistema, koji je ugrađen u implementaciju jezika.
Potpis
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
Nedeljko:"Pa, funkcionalno programiranje je takođe imperativno. Skoro svo programiranje je imperativno."
Nije. U Haskell-u recimo da bi uveo sekvence imas specijalan tip: Monade. Znaci u pravom f-nalnom jeziku
se sekvence uvode preko nekih metoda koja nisu u okviru samog jezika.
No u Haskell-u nemas petlje, varijable i te stvari koje cine imperativno programiranje.
Svakako da mozes implementirati petlje preko rekurzije ili varijable preko hendlova
ali to nije native u jeziku.
Nije. U Haskell-u recimo da bi uveo sekvence imas specijalan tip: Monade. Znaci u pravom f-nalnom jeziku
se sekvence uvode preko nekih metoda koja nisu u okviru samog jezika.
No u Haskell-u nemas petlje, varijable i te stvari koje cine imperativno programiranje.
Svakako da mozes implementirati petlje preko rekurzije ili varijable preko hendlova
ali to nije native u jeziku.
Ja ovde kao neocekivano vidim kako razna ubrzanja pisanja koda samo uspore na kraju :)
Krenuli ste u offtopic, ajde napravite temu za smaranje sta je bolje ili c.
Krenuli ste u offtopic, ajde napravite temu za smaranje sta je bolje ili c.
Potpis
CHUPCKO
Pa, naravno da je bolje "ili c".
Da li si hteo da kažeš da
"Razna ubrzanja pisanja koda samo uspore izvršavanje na kraju."
ili možda da
"Razna ubrzanja pisanja koda samo uspore pisanje koda na kraju."?
Da li si hteo da kažeš da
"Razna ubrzanja pisanja koda samo uspore izvršavanje na kraju."
ili možda da
"Razna ubrzanja pisanja koda samo uspore pisanje koda na kraju."?
Potpis
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
FF postoji za različite platforme, ne znam koliko su zajedničkog C++ koda imale verzije za različite platforme, a koliko kod Rust-a.
Ono, kad bi se bar kod svih OS-ova uniformisao API što se tiče osnovnih elemenata GUI-a (prozor, meni, osnovne kontrole, itd.), tj. da nazivi API metoda i parametri budu isti, ili da bar postoji neki prevodilac između različitih platformi.
S obzirom na rast popularnosti .NET Core kad bi dodali mogućnost kreiranja makar elementarnog GUI-a na različitim platformama, ali to bi zahtevalo različite implementacije tih delova biblioteke na različitim platformama, što otežava dalji razvoj, a i vidim da su kod .NET Core 5 planirali da integrišu Xamarin. Međutim, kako je kod .NET Core 3 dodata mogućnost kreiranja Win formi (tj. Win GUI aplikacije), sa naglaskom da to za sada radi samo na Windows-u, možda je u planu da u nekoj budućoj verziji dodaju tu mogućnost za Linux i MacOS.
Eto, možda sam sabajle jutros malo nalupetao nekih stvari koje se neće ostvariti, ali nikad se ne zna sa MS-om. Ako naprave .NET Core verziju sa kojom može da se kreira normalan GUI na različitim platformama (ne Xamarin forms), C# će postati još popularniji.
Ono, kad bi se bar kod svih OS-ova uniformisao API što se tiče osnovnih elemenata GUI-a (prozor, meni, osnovne kontrole, itd.), tj. da nazivi API metoda i parametri budu isti, ili da bar postoji neki prevodilac između različitih platformi.
S obzirom na rast popularnosti .NET Core kad bi dodali mogućnost kreiranja makar elementarnog GUI-a na različitim platformama, ali to bi zahtevalo različite implementacije tih delova biblioteke na različitim platformama, što otežava dalji razvoj, a i vidim da su kod .NET Core 5 planirali da integrišu Xamarin. Međutim, kako je kod .NET Core 3 dodata mogućnost kreiranja Win formi (tj. Win GUI aplikacije), sa naglaskom da to za sada radi samo na Windows-u, možda je u planu da u nekoj budućoj verziji dodaju tu mogućnost za Linux i MacOS.
Eto, možda sam sabajle jutros malo nalupetao nekih stvari koje se neće ostvariti, ali nikad se ne zna sa MS-om. Ako naprave .NET Core verziju sa kojom može da se kreira normalan GUI na različitim platformama (ne Xamarin forms), C# će postati još popularniji.
Potpis
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
Kod ozbiljnih projekata kao što je FF i koji su od početka cross-platform, gro koda je zajednički, jer gro koda nema veze sa specifičnostima OS-a.
Ako si pravio nešto ozbiljno, tipa AutoCAD, ali što nije odpočetka cross platform, pa si prosipao Win32 API pozive po projektu, onda naravno da portovanje može biti problem.
Ako si pravio nešto ozbiljno, tipa AutoCAD, ali što nije odpočetka cross platform, pa si prosipao Win32 API pozive po projektu, onda naravno da portovanje može biti problem.
Potpis
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.