Přechod z Javy na Rust. Ano či ne?

[Tomáš Crhonek]

Rust znám jen z přednášek, já jsem přešel na golang. Je jednodušší a má výborné možnosti multithredingu.

[Reklama]

[Radek Miček]

Co se tyce knihoven vs vlastní kod, je tu este vykonovy aspekt.

…

A ja se obavam, ze moje knihovny hy hyly este horsi, nez ty GOckove.

Na druhé straně vy byste to mohl psát kód přímo pro tu vaši konkrétní situaci.

Já jsem si třeba napsal vlastní parser pro JSON v F# a na určitých vstupech byl výrazně rychlejší než parser ze standardní knihovny System.Text.Json od Microsoftu. Ty vstupy byly JSONy, kde je v řetězci vnořený další JSON.

Dříve to navíc umělo poznat, že vstupní JSON obsahuje fieldy, které program neočekává (to už se System.Text.Json také naučil). Co většina knihoven stále neumí, je číst neomezeně dlouhá čísla - takže stále má výhody mít vlastní parser. Krom toho ten parser už dříve šlo přeložit do WASM a použít, což jiné parsery v C# ani F# neuměly (šlo je přeložit, ale často házely výjimky, protože používali reflexi, což ten můj parser nedělá).

A ještě jedna věc, JSON je dosti vágně specifikované, takže tím, že mám vlastní kód mám i kontrolu nad tím, jak se ošetří třeba slovníky s duplicitními fieldy, nebo s fieldy, co nejsou duplicitní, ale po Unicode normalizaci by byly.

[mm212]

Pokud se tím plánuješ živit, tak odpověď je "spíš ne". Full-time jobů v Rustu (ne RUSTu btw) je docela málo. Full-time jobů v Javě je hodně. Rust totiž za rychlost běhu programu platí větší pomalostí při psaní kódu (je fakt hodně přísnej) a to se na většině projektů nevyplatí.

jop ,je tak nevyužitelný ze  rust programatori jsou nejlépe ohodnoceni v oboru zatímco ta jista java se nedostala ani do první sedmičky a to tam najdeš jak go tak python + typescript a kotlin a bonus .. scalu

[Jožka Niemand]

Pokud se tím plánuješ živit, tak odpověď je "spíš ne". Full-time jobů v Rustu (ne RUSTu btw) je docela málo. Full-time jobů v Javě je hodně. Rust totiž za rychlost běhu programu platí větší pomalostí při psaní kódu (je fakt hodně přísnej) a to se na většině projektů nevyplatí.

jop ,je tak nevyužitelný ze  rust programatori jsou nejlépe ohodnoceni v oboru zatímco ta jista java se nedostala ani do první sedmičky a to tam najdeš jak go tak python + typescript a kotlin a bonus .. scalu

A to jste vzal kde? Zas nějaký pochybný žebříček, který se vždycky co měsíc totálně zpřehází? C++ a Java jsou z hlediska jobu sázky na jistotu a zároveň dobrého ohodnocení. Ani jeden z těchto jazyků přitom nemusím a nedělám v nich, i když se asi připravuju o peníze (duševní zdraví je mi cennější - správný objektový návrh umí udělat málo lidí, rozhodně mnohem méně, než kolik se jich o to pokouší, resp. se to po nich chce - mně tento design programu také není blízký a evidentně ani autorům většiny učebnic OOP; problém navíc je, že jen málokdo si to dokáže sebekriticky přiznat).

[Standa Blábol]

Pokud se tím plánuješ živit, tak odpověď je "spíš ne". Full-time jobů v Rustu (ne RUSTu btw) je docela málo. Full-time jobů v Javě je hodně. Rust totiž za rychlost běhu programu platí větší pomalostí při psaní kódu (je fakt hodně přísnej) a to se na většině projektů nevyplatí.

jop ,je tak nevyužitelný ze  rust programatori jsou nejlépe ohodnoceni v oboru zatímco ta jista java se nedostala ani do první sedmičky a to tam najdeš jak go tak python + typescript a kotlin a bonus .. scalu

A to jste vzal kde? Zas nějaký pochybný žebříček, který se vždycky co měsíc totálně zpřehází? C++ a Java jsou z hlediska jobu sázky na jistotu a zároveň dobrého ohodnocení. Ani jeden z těchto jazyků přitom nemusím a nedělám v nich, i když se asi připravuju o peníze (duševní zdraví je mi cennější - správný objektový návrh umí udělat málo lidí, rozhodně mnohem méně, než kolik se jich o to pokouší, resp. se to po nich chce - mně tento design programu také není blízký a evidentně ani autorům většiny učebnic OOP; problém navíc je, že jen málokdo si to dokáže sebekriticky přiznat).

A pritom je OOP tak strasne jednoduchy koncept.
Staci znat par pravidel a selsky rozum, objektovy je cely svet vukol.

Staci vedet, ze kdyz ten jazyk nejake moznosti nabizi, ze je veru neni potreba nasrat vsude.
Ze napr. dedeni se pouziva, kdyz potrebuju ROZSIRIT funkcionalitu existujiciho objektu, pokud potrebuju jenom polymorfismus, na 99% bude vhodnejsi prosty interface.

Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.

Pak je potreba v ramci mozkoveho mysleni este urcit, ze v danem kontextu objet User zrejme nebude clovek, alebrz vstupni karticka, co se strka do pichacky a kterou se oteviraji dvere, ze je treba lepsi ten objekt pojmenovat AuthToken a  tedy ze neni potreba do toho nasrat i cislo bot realneho Usera, to se klido strci do jineho objektu, co upravdu reprezentuje cloveka.

A ano, knizky o OOP jsou vetsinou blbe, tam prave dedi trojuhelniky a ctverce z obecneho polygonu, aby ve zdedenem objektu vymenili sakuprask vsecko, tady je lepsi prosty interface.

Chapu, ze treba Spring Boot potrebuje vsecky ficury javy vcetne introspekce a apod. Prave proto Spring vznikl, aby bezny programator business logiky se s tim prdolit nemusel.
Ja pri psani ve Springu z celeho OOP pouzivam interfacy (popr anotace, tedy interfacy v jinem formatu), encapsulaci a konec.

[Reklama]

[Kit]

A pritom je OOP tak strasne jednoduchy koncept.
Staci znat par pravidel a selsky rozum, objektovy je cely svet vukol.

Staci vedet, ze kdyz ten jazyk nejake moznosti nabizi, ze je veru neni potreba nasrat vsude.
Ze napr. dedeni se pouziva, kdyz potrebuju ROZSIRIT funkcionalitu existujiciho objektu, pokud potrebuju jenom polymorfismus, na 99% bude vhodnejsi prosty interface.

Slovo ROZŠÍŘIT je ošemetné, protože se do toho vejde zbytečně moc vztahů. Potom vznikají nesmysly typu BaseController jako rodič apod. Místo toho používám slovo JE, které je pro pochopení vztahu mnohem lepší a hlavně psychologicky zamezí vzniku dědictví tam, kde být nemá.