Sender | Message | Time |
---|---|---|
30 Sep 2022 | ||
nikola | inače, tangencijalno, vidio sam da ljudi znaju dobiti baš kvalitetne i korisne code reviewove na /r/rust na Redditu (https://old.reddit.com/r/rust/) | 09:24:49 |
dkorunic | In reply to @nikolap:matrix.orgEj hvala puno! Pa, vec neko duze vrijeme mjerkam Rust (cca 3 godine) i dao sam si truda procitati prvo Programming Rust (Blandy and co.), Rust Bible (Klabnik) i Rust in Action (McNamara).. i jos sam isao rijesiti rustlingse i Exercismov Rust track (negdje pola, nisam jos stigao sve proci)... Sve u svemu, kao jezik vjerojatno mi je najslozeniji, najinteresantniji i najmocniji jezik u kojem sam radio do sad; sama ekspresivnost jezika i kombiniranje functionalnog i imperativnog programiranja, visookoptimizirani iteratori.. | 11:22:07 |
dkorunic | Inace sam razmisljao poslati na r/rust, ali sam mislio prvo pridruziti se lokalnoj zajednici i pingnuti za misljenje.. safe approach first :-) | 11:23:01 |
dkorunic | Eh sad sto se tice usporedbi Rusta sa nekim drugim jezicima, nije bas sve bez mana -- oslanjanje na C/C++ headere za razlicite sistemske crateove i razlike u toolchainovima kao i u sistemskim toolchainovima (msvc, xcode, llvm...) uzrokuju razlicite nuspojave prilikom cross-compilea i ruku na srce, cross-compile je znatno slozeniji i manje uniforman nego npr. kod Golanga. Hoce li binary biti moguce iskompilirati za ne znam, arm+musl ili aarch64+musl je lutrija; cross-compile na vlastitom stroju uvjetuje kombinacije Qemu/KVM/VirtualBox/HyperKit/etc. i sve skupa ne mogu reci da sam s tim odusevljen. Razumijem uzroke i sistemske razloge, ali svejedno kad usporedim druga rjesenja.. | 11:26:37 |
dkorunic | Takodjer, mogu primijetiti da neki drugi jezici idu u smjeru uniformnog API-ja izmedju syscallsa i funkcijskih poziva u jeziku; Rust sretno ima Unix-specific funkcije i traitove, a na nepodrzanim sustavima (MS) tih funkcija uopce nema, pa se izrada 100% cross-platform rjesenja komplicira, odnosno ili si na ruke moras dodati svoje "mock" traitove/funkcije ili raditi velike uvjetne compile blokove; Golang recimo u potpunosti ima uniformni interface izmedju svih OS-ova i cak i ako neceg "nema", stvari su implementirane kroz kakav workaround i/ili emulaciju funkcionalnosti, pa je developerov zivot jednostavniji | 11:29:57 |
istankovic |
Je li uistinu? Čini mi se da je to prilično dobar recept za leaky apstrakcije. | 11:33:01 |
dkorunic | Pa, primjerice stat() syscall moze vratiti strukturu koja na razlicitim OS-ovima moze imati razlicita polja popunjena. Cak i na istim OS-ovima ali razlicitim filesystemima. U Rustu jednostavno nemas neka polja (...) dok u Golangu ta polja sva postoje, ali su ili na 0 ili na "nil", primjerice. Da se diskutirati sto je sigurnije i/ili pametnije -- ali sa gledista razvoja cross-platform aplikacije imati u sourcetu hrpu compile-time specific blokova je cisti pain, vracamo se u doba C ifdefova :) | 11:35:45 |
dkorunic | No u svakom slucaju performanse barem za ovaj moj slucaj cisto I/O bound algoritma su prilicno odlicne. Use case je nas storage od 300PB na kojem nerijetko customeri ostave 1M+ datoteka u flat direktorijima, a clean room reimplementacija je oko 2-2.5x brza nego Go varijanta toola. | 11:40:48 |
istankovic | In reply to @dkorunic:matrix.orgHeh, da, to je tipična situacija biranja manjeg zla... | 11:42:59 |
istankovic | Moja (vjerojatno najveća) zamjerka kad je pitanju Rust je usmjerena više na kompajler: buildati bilo što netrivijalno je naprosto presporo. | 11:48:49 |
istankovic | Nadam se da će se tempo rada na tome promijeniti jednom kad horda Linux kernel developera počne galamiti. | 11:50:20 |
istankovic | (Uskoro bi patch trebao sletjeti.) | 11:50:28 |
dkorunic | Apsolutno, jos kad imas vise razlicitih targeta.. Koliko sam primijetio jedino je codegen paraleliziran, postalo po defaultu nije. | 11:50:29 |
dkorunic | Za usporedbu (a moram reci), Golang compiler cross-compilira netrivijalne projekte za red velicine brze, ako ne i vise :-) | 11:51:01 |
istankovic | Apsolutno vjerujem. :-/ | 11:51:32 |
dkorunic | Inace zanimljivo mi je bilo vidjeti da za Rust nema goreleaser za Github/Gitlab projekte, vec da se svodi na DIY sa Github actionsima + cross-om | 11:52:06 |
dkorunic | Jesam li sto propustio? | 11:52:14 |
dkorunic | * Apsolutno, jos kad imas vise razlicitih targeta.. Koliko sam primijetio jedino je codegen paraleliziran, ostalo po defaultu nije. | 12:02:08 |
istankovic | Prvi put čujem za goreleaser . | 13:07:59 |
istankovic | Izgleda cool. | 13:10:14 |
dkorunic | istankovic: Uber kul alat je i u stanju je izbuildati (cross-compile) i releaseati na mnogo strana odjednom, tipa na GitHub, Gitlab, Docker Hub, Homebrew, itd. Prakticni primjer: https://github.com/dkorunic/e-dnevnik-bot/blob/main/.goreleaser.yml | 13:42:25 |
6 Oct 2022 | ||
dkorunic | Vjerojatno ste probali/koristili Miri (https://github.com/rust-lang/miri) ali meni je pravo otkrice za FFI | 12:17:33 |
7 Oct 2022 | ||
nikola | dkorunic: hoćeš reći da koristiš Miri za testiranje programa koji rade pozive kroz FFI? | 16:30:46 |
nikola | ja sam vidio da postoji i malo čituckao kako se razvija, ali moram priznati da ga nisam ni probao upogoniti. :) | 16:31:12 |
dkorunic | nikola: A nesto sam slagao Rust FFI sa C bibliotekama i nesto unsafe koda, pa sam htio provjeriti koliko sam krsio/krsim relativno kompleksna pravila koristenja unsafea.. i otkrio sam Miri | 16:33:03 |
dkorunic | Koji je nevjerojatno praktican | 16:33:07 |
dkorunic | Mislim, bezveze primjer ali:
| 16:34:39 |
nikola | super! vidim da su složili da je to sad pitanje instalacije kroz rustup i cargo miri test . | 16:35:20 |
nikola | čini mi se da je prije to bilo... kompliciranije. :) | 16:35:28 |
dkorunic | Je, nightly je preduvjet | 16:35:31 |