Názory k článku
Rust se dostává do systemd
-
Tak především pokud někdo nechápe, že tak jako stavební inženýr provádí pevnostní výpočty a nestačí jenom tvrdit, že to "umí", stejně tak programátor by měl být schopen podat formální důkaz a ne jenom očekávat, že před jeho egem ostatní padnou na zadek, takový člověk by skutečně neměl být programátorem.
A kromě toho když někdo evidentně nechápe podstatu bezpečnostních garancí v Růstu (a ani to, že se netýkají jenom paměti), tak by se k ní radši ani neměl vyjadřovat.
-
Ne, nic takového neslibovaly. Slibovaly jiné věci (C s OOP plus kvadrilionem dalších náhodných featur, toho C++ dosáhlo, ovšem jak moc je to dobře je přinejmenším otázka. Java slibovala "write once run everywhere", toho nikdy doopravdy nedosáhla).
Kromě toho u Rustu nejde o sliby, ale o vlastnosti které jsou jednak formálně teoreticky prokázané, jednak dneska už ověřené v praxi. K tomu patří i to, že Rust na rozdíl od C++ nebo Javy nikdy netvrdil, že je zázračný všelék nebo "the next big thing", je to jazyk s jasně danými cíly a filozofií který ví i to, čím být nechce a na které use cases se nikdy nebude hodit.
-
> Co vam v Jave nefunguje medzi platformami?
Slovenské eDane - aplikácia na vypĺňanie a podávanie daňových priznaní - je napísaná v Jave. Aby som bol presnejší, v Java 8 a vyžaduje webstart (t.j. niečo, čo zmizlo v Java 9 a novších).
Môj počítač má procesor ARM64 (t.j. najstaršie JRE je 16). OpenWebStart nefunguje tiež.
Pri poslednom daňovom priznaní nastalo kopec "srandy", mimo možnosti riešenia bežným používateľom.
-
Ondra Satai NekolaZlatý podporovatel"No a jeden z ukazovateľov neschopnosti je aj to, že to bolo postavené na Jave v prvom rade"
Neblabol.
-
Ondra Satai NekolaZlatý podporovatel
Ta zavorka uz s Javou nema co delat, protoze to je problem obecne. Java, nejava.
-
> nerieši problém používateľa
Ale ja neriesim a ani sa nebavime o problemoch uzivatelov. Ak chcete ja napisem kod v ktorokolvek programovacom jazyku s ktorym budu mat uzivatelia problemy.
Bavime sa o tom ze v Jave (resp. a akomkolvek JVM based jazyku ako Scala, Groovy, Clojure, ...) ide najlahsie napisat velmi prenosny kod. -
Odkial mate tieto VELKE poznatky? Kamarat hovoril, citali ste na facebooku ci ste si to iba s niecim pomylil? Ak niekto pise blby kod musi debugovat ale to nema nic spolocne s prenositelnostou. Kod bezne prenasame na novsie verzie Javy bez problemov samozrejme si vyzaduje trochu sledovat release notes ale nic mimoriadne nerobime a obvykle sa urobi aj velke upratovanie a upgrade velkeho mnozstva kniznic. Ale ziadne velke prepisovanie kodu sa nekona.
Koli problemom medzi platformami si uz roky napamatam ze by sme nieco upravovali.>podpora platforiem je o dosť širšia
A vy rozumiete vobec tomu co je to jednoducha prenositelnost a ako sa to lisi od sirky platforiem? -
> Kamarat hovoril, citali ste na facebooku ci ste si to iba s niecim pomylil?
Jasné, odkial inde? /s
> Ak niekto pise blby kod musi debugovat ale to nema nic spolocne s prenositelnostou.
Ah, univerzálna výhovorka rockstar programátorov.
> Kod bezne prenasame na novsie verzie Javy bez problemov samozrejme si vyzaduje trochu sledovat release notes
Zjavne nepoužívate knižnice a/alebo frameworky tretích strán. Keď sa dodávateľ rozhodne (zatiaľ?) neurobiť update pre JRE9+, lebo reasons, tak si môžete prečítať release notes trikrát denne a aj tak vám to nepomôže.
Takže máme napr. jednu aplikáciu, ktorá beží pod JBoss 6.x, JDK 8 a obsahuje Java 8 only knižnice. Určite taký veľký programátor a odborník na Javu poradí nášmu dodávateľovi; ten asi len číta na facebooku.
Alebo nie, tá aplikácia už má nasledovníka. Ten už nie je v Jave.
> A vy rozumiete vobec tomu co je to jednoducha prenositelnost a ako sa to lisi od sirky platforiem?
Keď to môžete prenášať medzi dvoma-troma architektúrami na VM od single vendora, tak mi tá prenositeľnosť nepomôže. Od kopca vecí dávajú vendori ruky preč keď to nebeží na Oracle Java a OpenJDK/Corretto/Azul nepodporujú vôbec. Asi nevedia programovať, mali by ste im urobiť školenie. Alebo že by to s tou prenositeľnosťou nebolo až také horúce?
-
Filip JirsákStříbrný podporovatelNo a jeden z ukazovateľov neschopnosti je aj to, že to bolo postavené na Jave v prvom rade
On neexistuje lepší způsob, jak implementovat elektronický podpis v prohlížeči, než právě Java. I nová řešení budou většinou používat Javu, akorát bude lépe zabalená. Protože nikomu se nechce vyvíjet podepisovací řešení v počtu X prohlížečů × Y operačních systémů a prostředí.31. 5. 2021, 14:27 editováno autorem komentáře
-
Môže sa to tak zdať z pohľadu jednoduchosti/zložitosti pre implementátora. Je to však tiež dobrý spôsob ako zabezpečiť, aby to bolo pre bežného Janka Mrkvičku nepoužiteľné.
Inak aplet na overovanie slovenského eID ("Aplikácia pre eID") je napísaný v C++ a Qt. Tam zjavne podmienky použiteľnosti boli nastavené tvrdšie.
-
Filip JirsákStříbrný podporovatel
Je to však tiež dobrý spôsob ako zabezpečiť, aby to bolo pre bežného Janka Mrkvičku nepoužiteľné.
Proč? Janek Mrkvička nebude zkoumat, jestli ten EXE, který se spouští, byl vyroben v Javě nebo v C++.Inak aplet na overovanie slovenského eID ("Aplikácia pre eID") je napísaný v C++ a Qt.
To je podle mne jiný druh aplikace, kde nestačí systémové služby pro práci s certifikáty. -
> Proč? Janek Mrkvička nebude zkoumat, jestli ten EXE, který se spouští, byl vyroben v Javě nebo v C++.
Skúmať ho samozrejme nebude, akurát mu to nebude fungovať po náhodných update systému. Alebo si kúpi nový počítač a neprečíta si drobné písmená, kde píšu, že verzia systému na ňom je príliš nová a ešte nie je podporovaná.
Veď koniec koncov presne toto bol prípad spomínaného eDane a M1-tkových počítačov Apple.
-
Filip JirsákStříbrný podporovatel
Skúmať ho samozrejme nebude, akurát mu to nebude fungovať po náhodných update systému. Alebo si kúpi nový počítač a neprečíta si drobné písmená, kde píšu, že verzia systému na ňom je príliš nová a ešte nie je podporovaná.
Jak to souvisí s tím, v čem je aplikace napsaná?Veď koniec koncov presne toto bol prípad spomínaného eDane a M1-tkových počítačov Apple.
Opět, myslím, že to, zda má nová platforma emulátor staré platformy nebo je potřeba pro novou platformu znovu přeložit aplikaci nijak nezávisí na tom, v jakém jazyce je ta aplikace napsaná.Jen pro jistotu, znáte věci jako jlink nebo GraalVM native-image? Jenom jestli se tu bavíme o současném stavu nebo o stavu před 6 lety.
-
> Jak to souvisí s tím, v čem je aplikace napsaná?
Súvisí to s tým, ako je runtime daného jazyka krehký a čo všetko ho dokáže rozhodiť.
Jetbrains napr. musel vynaložiť obrovské úsilie, aby priniesli svoje produkty na M1. Bežný korporát a ani dodávateľ štátnej správy toto neurobí.
> Opět, myslím, že to, zda má nová platforma emulátor staré platformy nebo je potřeba pro novou platformu znovu přeložit aplikaci nijak nezávisí na tom, v jakém jazyce je ta aplikace napsaná.
V prípade Javy ale nestačí znova preložiť aplikáciu; treba nové JVM, s novým JIT. Nové JVM tiež nie je pre verziu Java ktorú potrebujete, ale len pre tú budúcu (v prípade Java aarch64 je podporovaný až od Java 16, ktorá vyšla tento marec). Takže portujete aj ešte aj na novú Javu v situácií, keď množstvo dependencies ešte neprekročilo prah Java 8.
> Jen pro jistotu, znáte věci jako jlink nebo GraalVM native-image? Jenom jestli se tu bavíme o současném stavu nebo o stavu před 6 lety.
Bavíme sa o tom, aké som mal v praxi problémy pri používaní počítača s ARM64. Graal má rovnaký problém ako mal Python2->Python3, t.j. nie je to out of box kompatibilné riešenie. A keď vynakladám veľa práce na zmenu platformy, tak si môžem vybrať aj takú, kde sa zbavím Oracle.
-
-
> bez přezdívky: Ještě stále to srovnáváte s C++ a Qt?
Pri desktopovych aplikaciach? Ano. Alebo kludne aj s Electronom. Fakt si neviem predstavit horsiu volbu pre desktopovu aplikaciu ako Java.
(A znova si kopnem do eDane: oni do javaws zabalili embedded Chromium - a samozrejme ze v Rosetta emulacii jeho JIT engine hadzal vynimky. Urobili plny kruh: browser spusta javovu aplikaciu, ktora ma v sebe Chromium a pouziva ho na zobrazovanie obsahu.)
-
Filip JirsákStříbrný podporovatel
bez přezdívky: Zajímalo mne, jestli build Qt pro aarch64 prostě je, a to i pro starší verze knihovny, jestli se portace C++ aplikace na M1 udělala sama… Ona ta aplikace pro podepisování ani nemusí být desktopová v pravém smyslu – GUI může být ve webové stránce, ta Java aplikace může řešit opravdu jen přístup k certifikátům na daném zařízení a podpis hashe.
-
Filip JirsákStříbrný podporovatel
Java 8 je nepodporovana od 31.12.2018.
Java 8 má od Oraclu Premium Support do března 2022, Extended Support zatím do prosince 2030. Amazon Corretto 8 má podporu do května 2026. Asi jste si to popletl se změnou licenčních podmínek Oraclu. -
Filip JirsákStříbrný podporovatel
To uctovnik Ferko z Hornej Marikovej iste vie a zaplati si Premium support u Orakule aby si mohol raz do roka podpisat svoje danove priznanie.
Já jsem pouze opravil vámi chybně uváděné datum. Jestli účetního zajímá doba podpory jsem neřešil, s tím jste přišel vy. -
-
Vzhledem k tomu, kolik chyb se za poslední léta našlo v tak základním stavebním prvku, jako je OpenSSL, je otázka, kdo by všechny ty programy psal, kdyby ten výběr byl takto omezený. Problém je v tom, že programy dělají lidi a ti chybují. To je normální, ale špatné je, že některé jazyky tomu vycházejí vstříc. Rust to nedělá a přesto umožňuje psát brutálně rychlé aplikace (u velkých aplikací mu konkuruje jedině C++): https://www.techempower.com/benchmarks/
Existuje dobrý důvod nepsat větší věci v C a Rust je poměrně logická volba pro systémové aplikace, protože není nadmnožinou C (jako C++).
-
Filip JirsákStříbrný podporovatel
Já bych netroškařil. Kdo si není schopen navrhnout vlastní procesor, neměl by být programátorem.
-
Ondra Satai NekolaZlatý podporovatel
A nakonec se ukazalo, ze to nezvladne prakticky nikdo a chyby s pouzitim pameti (nejen uklid ale i preteceni a podobne radosti) jsou vsude, kde se to necha na programatorovi.
-
Ja vam poviem kde je chyba. Kniznice!
Kazda kniznica ma iny sposob ako uvolnovat pamat. Nikedy vam vrati pointer na vlastnu strukturu, inokedy vam da kopiu a mate sa o nu postarat vy alebo vrati pointer ale musite si urobit kopiu ak chcete hodnotu drzat lebo kniznica svoju pri inom volani uvolni ... . Niektore kniznice maju vlastny 'garbage collector' takze uvolnovat pamat musite cez nejake volanie. Pokial nepisete cely program sami je tom pekny bordel a ked poskladate 3-4 kniznice dokopy musite si pomaly kazde volanie nastudovat extra co s navratovou hodnotou robit.
Preto je RUST popularny lebo sice nema garbage collector ale je aspon hned jasne ako sa s pamatou pracuje. -
Rust to nechává plně na programátorovi. V podstatě má tytéž nástroje na správu paměti, jako současné C++. Akorát na rozdíl od C++ i ostatních jazyků provádí i vynucuje důkaz, že "živé" ukazatele skutečně odpovídají živým a přístupným objektům a že platí jisté invarianty (a ne jako v C++, kde není možné zaručit, že unique_ptr je skutečně jedinečný, že shared_ptr je doopravdy sdílený a že nějaký ukazatel není null nebo neinicializovaný). Tolik ke správě paměti, Rust nabízí i další garance mimo paměť. Někdo je holt machr r34L Pr0gR4mM3r a tyhle požadavky považuje pod svoji důstojnost, ale mě naopak připadá, že by se to mělo brát jako holá samozřejmost.
-
Když už to umí kernel, tak proč ne "kernel 2";) Ale trochu se bojím toho, že pak pomalu odsuneme nepodporovane platformy na druhou kolej, jelikož pro ně Rust není. Neříkám, že by byl dobrý nápad, spouštět systemd na m68k, ale i tak se můžeme dostat do stavu, že nějaká část systemd nepojede na něčem podobném. Ale podobná diskuze asi proběhla už i u jádra.
-
Tohle je samozřejmě pravda a je to asi nejvážnější argument proti Rustu v podobných projektech. U jádra se v dohledné budoucnosti Rust bude moci používat jen v "listových" modules, tj. takových, na kterých žádné další moduly už nezávisí (ovladače, FS apod), takže uživatelé nepodporovaných platforem budou mít v nejhorším případě přístup k podmnožině featur jádra ale nebudou od něj odříznuti úplně.
U systemd je to trochu jinak, ten pokud vím (zatím) žádnou takovou politiku nemá. Teoreticky se může stát, že na m68k nebo SPARC nebude možné systemd buildovat (přinejmenším ne oficiálně podporovaným překladačem). Jenomže doopravdy jsou tyhle architektury v každém případě časem odsouzené, navíc žádné ze stěžejních dister (= těch, co používají systemd) už na nich dávno stejně nefunguje. Jediná výjimka je Debian, který to bude muset nějak řešit. Ledaže by taky zařízl podporu takových platforem, případně je přenechal Devuanu.
-
To je (velmi) podrobně rozebíráno v diskuzi v odkazovaném pull requestu. Aktuální názor je, že se bude udržovat duální implementace některých celků (tj. C a Rust paralelně). První leaf moduly přejdou plně na Rust až v momentě, kdy bude hotový a stabilní Rust front-end pro GCC, čímž přestane existovat Vámi popsaný problém.
