Rust - std::ANY alebo lepší návrh?

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #30 kdy: 18. 11. 2021, 11:46:41 »
Jak by se to dělalo se Set-ou v C++ STL?
V tomto případě stejně, insert v std::set taky indikuje, jestli se prvek přidal.


Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #31 kdy: 18. 11. 2021, 11:49:00 »
Můžeš rozvést, co myslíš v tomhle případě runtimem, a k čemu by měl být Rustu užitečný?
... ale právě lidi od App Engine si stěžují na absenci alespoň elementární dynamické reflexe ...

Pod dynamickou reflexi se toho může schovat hodně (v extrému třeba smalltalkovský #become: , #allInstances, #selectors, metatřídy, reifikovaný callstack), ale v Rustu si ani základnější věci příliš představit nedovedu, těžko třeba zjišťovat typ nějaké hodnoty když se optimalizátor rozhodl ji úplně vyhodit, a i kdyby ne tak k ní stejně nejsou metadata. No, uvidíme, co se vymyslí.
« Poslední změna: 18. 11. 2021, 11:51:51 od registrovany_ava »

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #32 kdy: 18. 11. 2021, 11:58:50 »
Můžeš rozvést, co myslíš v tomhle případě runtimem, a k čemu by měl být Rustu užitečný?
... ale právě lidi od App Engine si stěžují na absenci alespoň elementární dynamické reflexe ...
Pod dynamickou reflexi se toho může schovat hodně (v extrému třeba smalltalkovský #become: , #allInstances, #selectors, metatřídy, reifikovaný callstack), ale v Rustu si ani základnější věci příliš představit nedovedu, těžko třeba zjišťovat typ nějaké hodnoty když se optimalizátor rozhodl ji úplně vyhodit, a i kdyby ne tak k ní stejně nejsou metadata. No, uvidíme, co se vymyslí.
No právě, jde o metadata. Třeba Go má velký runtime, ale hlavně kvůli GC. Ideální runtime má ObjC, ten je malý, flexibilní, elegantní, prostě skvěle navržený a implementovaný. Nebo microsoftí metadata u C++ se taky povedly, než to zrušili :) Ale Rust je v podstatě asembler s GADT, tak v nic moc nedoufám :)

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #33 kdy: 18. 11. 2021, 13:59:45 »
třeba smalltalkovský #become: , #allInstances, #selectors, metatřídy, reifikovaný callstack
BTW takhle daleko asi nikdo jít nechce — to už může rovnou použít Smalltalk nebo ObjC :) — ale reifikované invokace jsou ještě před hranicí užitečnosti a neprůhledné magie :) Jinak u Rustu bych fakt moc neřádil, ostatně mantra jeho autorů je abstrakce bez ztráty efektivity (nebo tak nějak) a dává smysl mít bezpečné a efektivní C s mocnými makry ;)

Ink

  • ****
  • 494
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #34 kdy: 18. 11. 2021, 17:16:47 »

Ano, spravne. Jednotlive typy (XYZ) poznam uz v dobe prekladu, nevedel som spravne namodelovat Trait tak, aby som vedel "nacpat" XYZ do funkcie "push", a teda, vyuzil som mne zname std::Any.
Proč nepoužiješ enum?
Este niesom v Ruste spravne "zabehnuty" takze, neviem/netusim ako konkretne by som pouzil Enum ako nahradu za Struct ( tomto konkretnom priklade)

Očividně jsme se nepochopili, enum v Rustu je, jak správně poznamenal Idris, součtový typ, tedy něco jako variantní typ v jiných jazycích - můžeš na základě zvolené varianty (typicky pattern matching) vzít vnitřek (např. instanci struktury X, Y nebo Z) a pracovat s ním "hezky" namísto toho řešení, které jsi měl původně. Struktura a enum se v Rustu doplňují a to dost elegantně.

Tvoje nové řešení používá enum a la C, což není samozřejmě nic špatného, ale já jsem si představoval něco jiného - muselo by se to ale celé překopat. Jinak doporučuju se mrknout na Diesel a podobná řešení DB v Rustu - ať už pro náhradu nebo inspiraci.


Ink

  • ****
  • 494
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #35 kdy: 18. 11. 2021, 17:17:46 »
Prosím případně smazat (ignorovat), nevím, jak se tento příspěvek vytvořil.
« Poslední změna: 18. 11. 2021, 17:20:45 od Ink »

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #36 kdy: 18. 11. 2021, 17:21:22 »
Tvoje nové řešení používá enum a la C
Podle mě je totiž matoucí nazvat součtové typy "enum", člověk si nese z C (a podobných jím ovlivněných) nějakou představu, která je velice daleko od součtových typů ve funkcionálním pojetí (a nepomáhá ani nazvat je "indirect enum" jako ve Swiftu, spíše naopak...).

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #37 kdy: 18. 11. 2021, 17:34:26 »
Očividně jsme se nepochopili, enum v Rustu je, jak správně poznamenal Idris, součtový typ, tedy něco jako variantní typ v jiných jazycích - můžeš na základě zvolené varianty (typicky pattern matching) vzít vnitřek (např. instanci struktury X, Y nebo Z) a pracovat s ním "hezky" namísto toho řešení, které jsi měl původně. Struktura a enum se v Rustu doplňují a to dost elegantně.

Tvoje nové řešení používá enum a la C, což není samozřejmě nic špatného, ale já jsem si představoval něco jiného - muselo by se to ale celé překopat. Jinak doporučuju se mrknout na Diesel a podobná řešení DB v Rustu - ať už pro náhradu nebo inspiraci.
Nakolko v tomto pripade sa mi jedna o navrh, tak reimplementacia do Rustovskeho Enumu je taka studijna vyzva :). Pozrem co ponuka doc rustu na Enum, pattern matching a pod. Postnem to sem na reviziu a pre porovnanie.

Diky za hint


Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #38 kdy: 19. 11. 2021, 10:25:36 »
Očividně jsme se nepochopili, enum v Rustu je, jak správně poznamenal Idris, součtový typ, tedy něco jako variantní typ v jiných jazycích - můžeš na základě zvolené varianty (typicky pattern matching) vzít vnitřek (např. instanci struktury X, Y nebo Z) a pracovat s ním "hezky" namísto toho řešení, které jsi měl původně. Struktura a enum se v Rustu doplňují a to dost elegantně.

Tvoje nové řešení používá enum a la C, což není samozřejmě nic špatného, ale já jsem si představoval něco jiného - muselo by se to ale celé překopat. Jinak doporučuju se mrknout na Diesel a podobná řešení DB v Rustu - ať už pro náhradu nebo inspiraci.
Nakolko v tomto pripade sa mi jedna o navrh, tak reimplementacia do Rustovskeho Enumu je taka studijna vyzva :). Pozrem co ponuka doc rustu na Enum, pattern matching a pod. Postnem to sem na reviziu a pre porovnanie.

Diky za hint
Rozhodně doporučuji naučit se pattern matching pořádně, Rust je tím prolezlý (vracení chyb, prázdných hodnot…). Chce to zvyknout si na syntax (match, if let…), jinak to žádná věda není a přispívá to k bezpečnosti kódu. Taky doporučuji nezvykat si na unwrap :)

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #39 kdy: 19. 11. 2021, 15:02:10 »
Očividně jsme se nepochopili, enum v Rustu je, jak správně poznamenal Idris, součtový typ, tedy něco jako variantní typ v jiných jazycích - můžeš na základě zvolené varianty (typicky pattern matching) vzít vnitřek (např. instanci struktury X, Y nebo Z) a pracovat s ním "hezky" namísto toho řešení, které jsi měl původně. Struktura a enum se v Rustu doplňují a to dost elegantně.

Tvoje nové řešení používá enum a la C, což není samozřejmě nic špatného, ale já jsem si představoval něco jiného - muselo by se to ale celé překopat. Jinak doporučuju se mrknout na Diesel a podobná řešení DB v Rustu - ať už pro náhradu nebo inspiraci.
Nakolko v tomto pripade sa mi jedna o navrh, tak reimplementacia do Rustovskeho Enumu je taka studijna vyzva :). Pozrem co ponuka doc rustu na Enum, pattern matching a pod. Postnem to sem na reviziu a pre porovnanie.

Diky za hint
Rozhodně doporučuji naučit se pattern matching pořádně, Rust je tím prolezlý (vracení chyb, prázdných hodnot…). Chce to zvyknout si na syntax (match, if let…), jinak to žádná věda není a přispívá to k bezpečnosti kódu. Taky doporučuji nezvykat si na unwrap :)

A raději si zvyknout na otazníky :)

Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.
« Poslední změna: 19. 11. 2021, 15:03:57 od ondra05 »

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #40 kdy: 19. 11. 2021, 15:15:53 »
Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.
Kdo by to čekal, že do tak nízkoúrovňového jazyka proniknou natolik abstraktní funkcionální konstrukty :) Nakonec ta symbióza funguje celkem hladce.

Ink

  • ****
  • 494
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #41 kdy: 19. 11. 2021, 15:38:27 »
Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.

Těmi monádami myslíš prosím co?

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #42 kdy: 20. 11. 2021, 11:45:07 »
Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.
Kdo by to čekal, že do tak nízkoúrovňového jazyka proniknou natolik abstraktní funkcionální konstrukty :) Nakonec ta symbióza funguje celkem hladce.

Zcela off-topic, Idrisi, tohle by se ti mohlo líbit: https://maybevoid.com/blog/mononym-part-1/

Idris

  • *****
  • 1 878
    • Zobrazit profil
    • E-mail
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #43 kdy: 20. 11. 2021, 12:36:08 »
Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.
Kdo by to čekal, že do tak nízkoúrovňového jazyka proniknou natolik abstraktní funkcionální konstrukty :) Nakonec ta symbióza funguje celkem hladce.
Zcela off-topic, Idrisi, tohle by se ti mohlo líbit: https://maybevoid.com/blog/mononym-part-1/
Jo, to jsem zaregistroval, akorát jsem se k tomu ještě podrobněji nedostal. Dík za odkaz a připomenutí.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #44 kdy: 20. 11. 2021, 14:15:39 »
Popravdě, od té doby co dělám v Rustu mi přijde způsob řešení takových věcí bez součtových typů, pattern matchingu a monád hrozně kostrbatý.

Těmi monádami myslíš prosím co?

Result, Option, Future, Iterator...