Je Rust jazyk budoucnosti?

[Králík]

Je ekvivalentne.

Není.

Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...

[Reklama]

[BoneFlute]

Je ekvivalentne.

Není.

Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...

Na technické detaily ti zvrací alík.

Liší se hlavně záruky.
V C# můžu tu validaci zapomenout. Skončí mi to výjimkou u assert v run-time. Zatímco v Idrisu mi to přinutí tu kontrolu udělat compile-time. To je ta zásadní motivace, proč se všechny ty šaškárny s typama dělají.

Idris mě přinutí tu kontrolu udělat.
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to až za běhu.

Do třetice:
V Idrisu (a Haskellu) - nalinkuju si nějakou knihovnu, použiju a pokusím se přeložit, a ono to začne řvát tady a tady a tady a tady... opravím, přeložím, běží.

V C# - nalinkuju si nějakou knihovnu, použiju, a úspěšně přeložím, spustím, a ono to začne padat tehdy, a tehdy, a tehdy, a tehdy... nejlépe u zákazníka.

[BoneFlute]

Viem, kam smerujes, ale ked sa bavime o vstupoch od pouzivatela, tak:

Kód [Vybrat] Rozbalit

new Even(input);

Je ekvivalentne.

Kód [Vybrat] Rozbalit


let Yes _ = decIsEven n | _ => putStrLn "n isn't even"


Není.
Nebo ty tam vidíš někde, že bych tu výjimku, kterou Even vyhazuje odchytával?

[Idris]

Je ekvivalentne.

Není.

Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...

Na technické detaily ti zvrací alík.

Liší se hlavně záruky.
V C# můžu tu validaci zapomenout. Skončí mi to výjimkou u assert v run-time. Zatímco v Idrisu mi to přinutí tu kontrolu udělat compile-time. To je ta zásadní motivace, proč se všechny ty šaškárny s typama dělají.

Idris mě přinutí tu kontrolu udělat.
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to až za běhu.

Do třetice:
V Idrisu (a Haskellu) - nalinkuju si nějakou knihovnu, použiju a pokusím se přeložit, a ono to začne řvát tady a tady a tady a tady... opravím, přeložím, běží.

V C# - nalinkuju si nějakou knihovnu, použiju, a úspěšně přeložím, spustím, a ono to začne padat tehdy, a tehdy, a tehdy, a tehdy... nejlépe u zákazníka.

Akorát cena za to je, že ty šikovné typy pro ověření musí někdo napsat. Pro základní věci (čísla, seznamy) je má standardní knihovna, nicméně pro méně typické věci (třeba i ta jednoduchá sudost) to musí napsat laskavý čtenář vývojář.

[Idris]

Kdybych tam cpal čísla ze vstupu, musel bych si to ověření sudosti (prfX) vyrobit sám a předat ho explicitně.

Mohl by si mi ukázat, jak by to vypadalo?

BTW až se budeš cítit na definici decIsEven, dej vědět 

[Reklama]

[BoneFlute]

Akorát cena za to je, že ty šikovné typy pro ověření musí někdo napsat.

Já tu třídu v C# taky musel napsat.

[listoper]

A abych byl hodně cynický, tak ona možná není nijak zvláštní poptávka ani po bezpečném kódu (Clojure...

triggered

[Králík]

C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to až za běhu.

Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?

[BoneFlute]

C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to až za běhu.

Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?

O to nejde.

Samozřejmě, že ten scénář musím zohlednit v runtime.

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

Částečně by toto řešil systém Checked Exception, od kterých se ale bohužel upouští. Úplně netuším proč. (C# je třeba schválně nemá.)

[Králík]

Případně ještě se zeptám obecně: Jaké jsou v Haskellu a Idrisu pravidla ohledně koherence? Dejme tomu, že ve svém programu používám knihovny libA a libB, knihovna libA definuje typeclass Tc a libB typ Foo. Můžu instanciovat Tc pro Foo?

Na toto jsem nedostal odpověď, tak jsem se zeptal na SO. TL;DR Haskell dovoluje orphan type instances vč. odvozených z dependencí. (Je Idris v tomto jiný? Asi bych to nečekal.)

@BoneFlute toto je příklad, kdy Rust musí omezovat typové abstrakce kvůli engineering constraints - nemůže dovolit orphan trait implementace na úrovni knihoven (na úrovni modulů ano), protože by to jednak způsobovalo semver hazardy a také pravděpodobně problémy s linkováním (zejména dynamickým), nejspíš by implementace traitů už nemohly být anonymní...

Zajímavé je, že Haskellu tohle nevadí, efektivně přidání jakékoli zvenku viditelné instance v knihovně je semver-incompatible změna...

[Idris]

C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to až za běhu.

Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?

O to nejde.

Samozřejmě, že ten scénář musím zohlednit v runtime.

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

Částečně by toto řešil systém Checked Exception, od kterých se ale bohužel upouští. Úplně netuším proč. (C# je třeba schválně nemá.)

BTW v Idrisu jde garantovat i vlastnosti návratových hodnot, nejen vstupních parametrů.

[Králík]

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...

[BoneFlute]

Akorát cena za to je,

Imho statické typy mají jiné problémy.
Namátkou:
- jsou náročné na čas výpočtu
- jsou náročné na vývoj jazyka
- jsou náročné na skill uživatele
- lidé nechápou co to je statické typování

[Idris]

Případně ještě se zeptám obecně: Jaké jsou v Haskellu a Idrisu pravidla ohledně koherence? Dejme tomu, že ve svém programu používám knihovny libA a libB, knihovna libA definuje typeclass Tc a libB typ Foo. Můžu instanciovat Tc pro Foo?

Na toto jsem nedostal odpověď, tak jsem se zeptal na SO. TL;DR Haskell dovoluje orphan type instances vč. odvozených z dependencí. (Je Idris v tomto jiný? Asi bych to nečekal.)

Idris to má stejně.

[BoneFlute]

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...

Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?