Je Rust jazyk budoucnosti?

[Idris]

jak v Idrisu handluješ chybu alokace paměti. V Rustu to jde.

Rust v tomto případě dělá abort (ani ne panic).

[Reklama]

[Králík]

Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...

Tak jistě, když se ti počítač vznítí a ty na něj chrstneš kýbl vody, tak to asi Idris nezachrání. Ale donutí tě náležitě ošetřit všechny logické chyby v kódu (typu dělení nulou, že se nevolá head na prázdný seznam apod.).

Pro nějakou definici "chyby" a pro nějakou definici "ošetří" tě Idris donutí ošetřit chyby...

jak v Idrisu handluješ chybu alokace paměti. V Rustu to jde.

Rust v tomto případě dělá abort (ani ne panic).

Takové je výchozí chování a popravdě třeba na Linuxu ani nemá smysl ho měnit, protože alokační chybu stejně nedostaneš. Ale lze změnit jak výchozí chování, tak i používat fallible konstruktory u Boxů, Veců apod. a bez toho by Rust nemohl být použit třeba v linux kernelu apod.

[BoneFlute]

Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...

Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.

Ten problém není ve výjimkách.

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.

[Idris]

Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...

Tak jistě, když se ti počítač vznítí a ty na něj chrstneš kýbl vody, tak to asi Idris nezachrání. Ale donutí tě náležitě ošetřit všechny logické chyby v kódu (typu dělení nulou, že se nevolá head na prázdný seznam apod.).

Pro nějakou definici "chyby" a pro nějakou definici "ošetří" tě Idris donutí ošetřit chyby...

Jo, ty definice sdílí se SPARKem (a jinými superbezpečnými jazyky pro bezpečnostně kritické aplikace).

[Idris]

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.

Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné

[Reklama]

[Králík]

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.

Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné

Ježiš, už mezi prvníma dvěma budou rozdíly... Java ani nemá hodnotvé typy, Either by musel být objekt, takže alokace, plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C# to AFAIK může být hodnotový typ. Taky má AFAIK už nějaký pattern matching...

[Idris]

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.

Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné

Java ani nemá hodnotvé typy

No a co? Ty ovlivňují výkon, ale nijak nesouvisí s bezpečností kódu.

[BoneFlute]

plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#

No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.

Taky má AFAIK už nějaký pattern matching...

Ano. Nějaký.

[BoneFlute]

plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#

No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.

Tak tady přiznávám svou neznalost. Když místo class použiju struct, což by mělo být podle docky hodnotový typ, tak to skutečně nelze vytvořit null. A je to i v naší staré code base. S tím si budu hrát.

Díky Králík!

[Králík]

NP, já jinak vůbec csharpista nejsem, asi to budeš umět využít lépe než já, jenom mam tohle taknějak v paměti co jsem si o tom před časem někde četl + si vágně pamatuju, že to i generika nad těmahle hodnotama monomorfizuje v době načtání bytecode, ale to ber s rezervou, možná si to pamatuju blbě...

[listoper]

Ježiš, už mezi prvníma dvěma budou rozdíly... Java ani nemá hodnotvé typy, Either by musel být objekt, takže alokace, plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C# to AFAIK může být hodnotový typ. Taky má AFAIK už nějaký pattern matching...

Jen pro info... java ma pattern matching... a value objects (primitive classes) jsou na ceste... JEP 401

[Králík]

Jen pro info... java ma pattern matching...

Měl jsem dojem, že umí matchovat jenom typ objektu...

a value objects (primitive classes) jsou na ceste... JEP 401

To je zajímavé, je fajn, že se něco děje po tom, co vallhala nedopadla... Nicméně v tomhle případě by nám to nepomohlo, protože jestli to dobře chápu, ty typy nebudou moct být generické...

[listoper]

Jen pro info... java ma pattern matching...

Měl jsem dojem, že umí matchovat jenom typ objektu...

Ma Guarded patterns a destructuring (aspon ve switch):

Kód: [Vybrat]


    record Person(String firstname, String surname) {}
    record Couple(Person p1, Person p2) {}

    public static void main(String[] args) {
        Person daddy = new Person("John", "Doe");
        Person mommy = new Person("Jane", "Doe");
        Person uncle = new Person("John", "Apples");


        var objects = Arrays.asList(
                new Couple(daddy, mommy),
                new Couple(mommy, daddy),
                new Couple(uncle, daddy),
                10,
                "Random string");

        objects.stream()
                .map(i -> switch (i) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> (Supplier<String>) () -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> (Supplier<String>) () -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> (Supplier<String>) () -> "Mommy is paying";
                    case Integer ignored                              -> (Supplier<String>) () -> "What are you doing here Integer";
                    case Object ignored                               -> (Supplier<String>) () -> "Runners... call 911";
                })
                .forEach(i -> System.out.println(i.get()));
    }


a value objects (primitive classes) jsou na ceste... JEP 401

To je zajímavé, je fajn, že se něco děje po tom, co vallhala nedopadla... Nicméně v tomhle případě by nám to nepomohlo, protože jestli to dobře chápu, ty typy nebudou moct být generické...

Myslim, ze je to porad valhalla... A nevim jestli budou moct byt genericke... spis ne

[Idris]

Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...

Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.

Ten problém není ve výjimkách.

A v čem?

[snugar_i]

Ma Guarded patterns a destructuring (aspon ve switch):

Kód: [Vybrat]


    record Person(String firstname, String surname) {}
    record Couple(Person p1, Person p2) {}

    public static void main(String[] args) {
        Person daddy = new Person("John", "Doe");
        Person mommy = new Person("Jane", "Doe");
        Person uncle = new Person("John", "Apples");


        var objects = Arrays.asList(
                new Couple(daddy, mommy),
                new Couple(mommy, daddy),
                new Couple(uncle, daddy),
                10,
                "Random string");

        objects.stream()
                .map(i -> switch (i) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> (Supplier<String>) () -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> (Supplier<String>) () -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> (Supplier<String>) () -> "Mommy is paying";
                    case Integer ignored                              -> (Supplier<String>) () -> "What are you doing here Integer";
                    case Object ignored                               -> (Supplier<String>) () -> "Runners... call 911";
                })
                .forEach(i -> System.out.println(i.get()));
    }


No.. slušelo by se říct, že je to "preview feature" v nejnovější JDK 19 (tj. běžně se to zatím použít nedá a možná to nakonec ani nebude vypadat takhle) a funguje to jenom na recordy a jen ve switchi (což jsi teda napsal) - ve srovnání s tím, co umí třeba jenom Scala, je to stále úsměvný. Btw vůbec nechápu, proč je tam ten Supplier, zbytečně to ten příklad komplikuje, proč to neni jenom

Kód: [Vybrat]

objects.stream()
                .map(it -> switch (it) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> "Mommy is paying";
                    case Integer ignored                              -> "What are you doing here Integer";
                    case Object ignored                               -> "Runners... call 911";
                })
                .forEach(it -> System.out.println(it));