Vlákno názorů ke zprávičce NSA nabádá organizace, aby používaly jazyky, které bezpečně pracují s pamětí od Ink - Ten text se hodí leda jako základ pro...

On to ale vysvetlil dobre.
V článku:
Jako příklad jsou zmíněny C#, Go, Java, Ruby, Rust a Swift.
V PDF:
Some examples of memory safe languages are C#, Go, Java, RubyTM, and Swift.

Podotýkam to SOME EXAMPLES. To vás naozaj tak rozhodilo, že v príkladoch uviedli Ruby a nie Python? A prečo tam je Java? Veď to je teraz fuj fuj fuj, nie?

> Podotýkam to SOME EXAMPLES. To vás naozaj tak rozhodilo, že v príkladoch uviedli Ruby a nie Python? A prečo tam je Java? Veď to je teraz fuj fuj fuj, nie?

Nerozhodilo, jak píšu níž. A Java mi v tomto kontextu nevadí, naopak - je hodně používaná, takže je tam zařazena logicky.

To je určitě nepravda. Ale ano, pravdou je, že se rozhodně používá méně než Python. Od té doby co jak rakovina prorostl kam se dalo, byť pod šlehačkou jednoduchého jazyka se skrývá dort co pekl pejsek s kočičkou.

Shodneme se na tom, že existuje minimálně jeden člověk, který Ruby používá. Neshodneme se na tom, zda o tom, jestli je Ruby lepší než Python, rozhoduješ Ty a ne každý programátor/tým sám za sebe.

Tak napsal jsi to přesně jak jsem to myslel. Já jako programátor, kterého bohužel živí Python, za sebe a jen za sebe píši, že Ruby je lépe navržený a esteticky krásnější jazyk než Python. Navíc si nelžou do kapsy: "There should be one– and preferably only one –obvious way to do it."

Nevím, co je na tom za sebeklam, když doufají, že to je (často) možné. Zen of Python je podle mě ale právě důvod, proč si Python některé vývojáře získal:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

No skvělé, to fakt potřebujeme, copy paste kravin. Radši si přečti jak se nepoužívá Ruby: https://w3techs.com/technologies/comparison/pl-python,pl-ruby

Tak získal si ruce vývojářů to ano, ale srdcem pro něj můžeš plesat jen když nemáš na výběr (Stockholmský syndrom?).

Vědomě lžeš, jsi na flamewar dost dobrá osoba. A dobře víš, že já na výběr mám a o programovací jazyky se zajímám aktivně. To Ty se tváříš, že Python používat musíš, ale já ne!

Teď trochu jiných statistik: https://statisticstimes.com/tech/top-computer-languages.php

Vědomě lžu v čem?
- Ruby se používa.
- Python není memory safe viz odkaz.
Toť k tvému pláči nad tím, že NSA ho nezahrnula do zprávy.

"To Ty se tváříš, že Python používat musíš, ale já ne!"
Co ta věta má říkat? Já ho používat musím, ano to je pravda. Jsou to historické a pragmatické důvody. Na nové projekty bych volil jiný jazyk, alternativ je již dnes dost (Julia, Go, TypeScript a dokonce i ta Java!)

11. 11. 2022, 16:43 editováno autorem komentáře

1. Zase lžeš. Že Python NSA neuvedla namísto Ruby, mě udivilo, ale je mi to jedno. Pokud snad nad něčím "pláču", tak nad vágností daných doporučení.

2. Že je Python memory unsafe, je natolik legrační tvrzení, potvrzené absurdním projektíkem, že to ani nemá smysl komentovat. Ukaž to na nějakém normálním kódu. Jo a bacha! Python má ctypes a dokonce extension moduly psané potenciálně v C! Ale to asi fakt nebude ten důvod, proč vybrali jako příklad Ruby.

3. Dobře víš, že jsem to nemyslel tak, že Ruby nepoužívá vůbec nikdo.

No a lžeš s tím stockholmským syndromem. Ne. Zkoušel jsem Common Lisp (a jiné lispy), zkoušel jsem Scalu, zkoušel jsem Nim, zkoušel jsem Julii, zkoušel jsem OCaml, zkoušel jsem Kotlin, zkoušel jsem Haskell, něco jsem napsal v Rustu, živil jsem se C, živil jsem se C++, klidně něco napíšu v Javě PHP, JS...

Ale Ruby patří k jazykům, které jsem chvilku okukoval, něco malého napsal, přemýšlel jsem právě nad tím, že by to měl být jakože lepší Python, vymakanější, líp navržený atd. A pokaždé znovu jsem si řekl, že mi to nestojí za to, že tam není pro mě žádná přidaná hodnota (na rozdíl od některých jiných, které jsem zmiňoval a které mi obohacující přišly). Můj pohled, nikoho nepřesvědčuju.

". Že je Python memory unsafe, je natolik legrační tvrzení, potvrzené absurdním projektíkem, že to ani nemá smysl komentovat."

BTW David Buchanan není žádný ořezávátko. Že on napíše do popisu toy project neznamená, že je to TOY project.

Begun the language wars have :-)

"zkoušel jsem Julii"

A jak to šlo?

Podotýkám, že už to je nějaká doba a nedělal jsem nic většího. Co si vybavuju:

1. REPL a další věci mi přišly super, syntaxe je podobná "standardním" jazykům, takže se mi s ní pracovalo celkem přirozeně. Některé věci jsou blízké Pythonu a některé zase ne, podle mě je Julia syntakticky v něčem lepší.

2. Je hodně znát, že je to jazyk zaměřený na vědeckotechnické výpočty - určitě je super, že umí např. vícerozměrná pole. Chválím volitelné typování a schopnost optimalizací.

3. Jsem rád, že ten jazyk nešel cestou OOP, líbí se mi, že umí přetěžovat operátory (funkce), umí range a spoustu jiných věcí. Určitě bych některé věci dělal trošku jinak (zkratka pro vnořené cykly mi přijde třeba zbytečná).

4. Systém modulů je v pohodě, větší aplikace se podle mě na tom stavět dají. Jak moc mají propracované knihovny pro různé oblasti, nemám představu. Když jsem se kdysi snažil importovat moduly z Pythonu, přišlo mi to dost nestabilní. Ale pokud vím, mají pro to teď nějaký nový systém, tak snad to je výrazně lepší.

Ono to typování zas tak volitelné není, používá se právě pro ten multiple dispatch (a pomáhá optimalizacím).

> Ono to typování zas tak volitelné není, používá se právě pro ten multiple dispatch (a pomáhá optimalizacím).

Jasně. Rozumím tomu, že pro některé věci to je v podstatě nutnost. Mimochodem, Python tohle už také začal používat, konkrétně třeba dataclass anotace vyžaduje.

Zeptám se teď já - umíš si představit, že bys používal Julii na nějaký větší projekt třeba typu výkonného HTTP serveru? Případně za jakých okolností?

Ne, to si nedovedu představit. Julia neumí (rozumně) překládat do statické binárky, je prostě určena k něčemu úplně jinému. A ani kdyby je uměla vytvářet, stejně mi nepřijde k tomuto účelu úplně vhodná vzhledem k tomu, jak dynamická je. V této oblasti vedou jasně Rust a Go.

"Mimochodem, Python tohle už také začal používat, konkrétně třeba dataclass anotace vyžaduje." To není pravda. Jste si jistý že ten Python znáte podrobně?

A co vy si představujete pod tím, že dataclass vyžaduje typové anotace? Já tedy něco jiného než toto:

from dataclasses import dataclass

@dataclass
class C:
    s1: "Is is nice to have"
    s2: "type hints like this!" = 2


c = C(1.2)
print(c)

C(s1=1.2, s2=2) 

13. 11. 2022, 19:01 editováno autorem komentáře

A to ani nemluvím o tom jaké zmatení dataclass přináší. Aby byla použitelná tak nejlépe označit ji frozen, jinak je mutable a tedy nebezpečná pro hash. Jo ale jak je to tedy se slots? Aha a dále teď máme vedle __init__, __post_init__, a dále default factory ... super. Není už ta Java s tím že po letech přidala po uvážení records dál, než bastl jménem Python? Podotýkám, že mi přispívá na chleba takže to není ve stylu: "Hating on Languages You Don't Use ". Go je dle mého Python done right.

13. 11. 2022, 19:12 editováno autorem komentáře

> Není už ta Java s tím že po letech přidala po uvážení records dál, než bastl jménem Python?

Ano, Java je v mnoha směrech "dál". Přesto mi nesedí. Neumí ani to základní, co od high level jazyka požaduju, tedy rozumné porovnání dvou objektů (jinými slovy něco jako přetížení operátorů).

> Podotýkám, že mi přispívá na chleba takže to není ve stylu: "Hating on Languages You Don't Use "

To já přece netvrdím. Klidně budu za rozumný peníz dělat něco v C a myslet si o tom jazyku a vhodnosti jeho použití v daném projektu svoje. To už tak je. Když si koupíš rohlík v supermarketu, nemusíš si to dávat na tričko.

> Go je dle mého Python done right.

Záleží na definici. Napiš, co je ten správný Python a pak se bavme. Ale kde je teda Ruby?

"Napiš, co je ten správný Python a pak se bavme." Go je správný Python, protože splňuje Zen of Python víc než samotný Python. Ruby je japonský Smalltalk (Zen).

> Go je správný Python, protože splňuje Zen of Python víc než samotný Python.

> Beautiful is better than ugly

Ošetření chyb v Go je jedna z nejošklivějších věcí, které se v prgramování za posledních několik desetiletí objevily. Case closed.

A víš o tom, že v Rustu se chyby ošetřují stejně? ;)

Neošetřují.

V Golangu jde typicky o dvě návratové hodnoty, kde jedna je typu error (nebo ok:bool). Ten je ovšem velice abstraktní a neumí nic, kromě testu při přetypování. Hlavičky funkcí také nijak nespecifikují jaké errory se na výstupu mohou objevit.

def funkce() (Typ, error) {
  if val, err := funkce(); err != nil {
    return nil, err
  }
}

V Rustu jde o jednu hodnotu v enumu Result a error typ v Resultu má konkrétní známý typ:

Takto použito by to vypadalo skoro stejně:

if let Err(err) = funkce() {
  return Err(err)
}

Jenže v Rustu lze díky tomu Result typu používat mnohem komplikovanější logiku. Result má funkce jako map a také se dá použít operátor otazník (tj. při erroru zavolej return error).

fn funkce() -> Result<(), ErrTyp> {
  funkce2().map_err(|e| e.do_err_typu())?
  funkce3()?
  Ok(()) // Návratová hodnota v případě úspěchu
}

Výhoda jedné návratové hodnoty je právě v možnosti řetězení a zanoření.

V principu je rozdíl mezi těmi přístupy malý, ale v praxi ta syntaxe je v Rustu kratší a jednoznačně definované typy chyb jsou přehlednější.

Blízký ekvivalent toho otazníku z Rustu je tento návrh pro Golang, který nicméně zatím nebyl implementován: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

V Rustu to je právě zbytečně složité a genericita Resultu vzhledem k typu chybu je jedno z nejhorších rozhodnutí, co v návrhu Rustu udělali. Navíc má nesmysly jako unwrap, expect atd.

Návratový kód, který nic neříká o tom, co se stalo, chceš nadřazovat Resultu, který má prakticky všechno promyšlené do detailu? unwrap() používat můžeš a nemusíš, ale na rozdíl od přeskočené kontroly v Go je pak výsledek předvídatelný a chybu neobchází. Dtto pro expect() atd. Spousta lidí to využívá, v týmu si to klidně zakaž, není problém. Na rozdíl od dementní dvouhodnoty v Go má Rust spoustu luxusních možností, jak s chybami nakládat.

14. 11. 2022, 11:22 editováno autorem komentáře

Result ve spojení s match vede k nepřehlednému a špatně čitelnému kódu, když chci jen dostat výsledek do proměnné (a při chybě vyskočit z funkce), musí se psát debilně “Ok(file) => file”. Rust vyžaduje hodně boilerplatu, ale tohle je extrémně stupidní. Zacházení s chybami se prostě v Rustu vůbec nepovedlo (což by nevadilo, kdyby tím nebyla zasviněná celá standardní knihovna).

> chci jen dostat výsledek do proměnné (a při chybě vyskočit z funkce)

Použiju "if let" a je to. Nebo něco jiného. Fakt nevím, co řešíš. asi by to chtělo příklad.

> Zacházení s chybami se prostě v Rustu vůbec nepovedlo

To je věc názoru, nemyslím si to. Je trochu škoda, že vychytávky typu anyhow nebo thiserror nebyly řešeny v rámci standardní knihovny, ale to je vše.

Jenže “if let” je zanoření do další větve, když takhle budu mít deset volání s potenciální chybou, kód bude ještě větší hnus než s matchem. Prostě je nejčitelnější mít dvě úrovně zanoření, pro chyby a pro úspěch.

Pořád chybí příklad. Můžu používat ?, můžu používat and_then, prostředků je dost. Nevidím žádnou, ale vůbec žádnou výhodu ošetření chyb v Go.

Funkcionální (ideální) příklad viz níže.

V tom se ovšem neshodneme. V Golangu je to děsný binec, protože nikdy nevíte co Vám v tom error typu přijde.

A sekvence jako tato zrovna přehledností neoplývají.

if v, ok := err.(IOError); ok {
 ...
} else if v, ok := err.(NetworkError); ok {
 ...
}

Stejně jako nekonečné

if err = f(); err != nil {}

u každého volání. Ten otazník je jen syntaktický cukr, ale strašně to zkracuje kód (jeden řádek místo tří).

A pak je tu obecný problém Golangu, kde skoro nelze řetězit funkce, protože dvě návratové hodnoty. Opět jen textový problém, ale otravný. I Java začala být s Optional mnohem příjemnější na používání.

Golang umožňuje prakticky to samé co ostatní jazyky, ale ten neprůhledný a generický error typ nesnáším. Golang kód má tendenci se kvůli němu příliš roztahovat, což není dobré pro čitelnost (funkce se nevlezou na obrazovku a error handling zabírá většinu prostoru).

Jasně, otazník jen fajn, ale funguje jen tehdy, když se typy shodují. Což většinou neplatí (jinak by to naopak bylo záviděníhodné).

Ty příklady v Go nejsou úplně správně (kvůli wrapu), místo typové aserce by mělo být prosté “errors.Is”.

>Jasně, otazník jen fajn, ale funguje jen tehdy, když se typy shodují. Což většinou neplatí (jinak by to naopak bylo záviděníhodné).

V knihovnách není problém zapouzdřit různé chyby do custom chybového typu, v aplikacích pak jde použít třeba eyre.

Jistě, to ostatně dělám furt dokola, psát v Rustu custom typy pro chyby. A rád bych se tomu vyhnul, když to umí jiné jazyky, proč ne Rust…

>Jistě, to ostatně dělám furt dokola, psát v Rustu custom typy pro chyby. A rád bych se tomu vyhnul, když to umí jiné jazyky, proč ne Rust…

Když mi na typu chyby nezáleží, eyre / color_eyre to dost zjednoduší. A zbytek je triviální s thiserror.

14. 11. 2022, 15:30 editováno autorem komentáře

BTW bohatě by stačilo mít “výhybku” pro chybovou větev jako v některých funkcionálních jazycích, kde v “do” bloku lze mít něco jako “let OK x = f() | Err err => convert_err err”, což řeší problém zanoření a zároveň odlišné typy chyb (při zachování čitelnosti). Rust se k tomu pomalu blíží.

IMHO řešení v Rustu je dobré. Já bych raději výjimky. Ale Result furt lepší jak to co má Go.

Ovšem viz ty příklady výše.

Píšeš, že Result bylo nejhorší rozhodnutí. IMHO to není pravda. Lepší řešení není. Tvé námitky byly z ranku "je to hnusné a nejde to jinak".
(Leda výjimky, které by se dali udělat jako syntaktický cukr nad Result, ale to je případně otázka budoucnosti.)

Lepší řešení rozhodně je, viz ten příklad z Idrisu. V Rustu to jde s tunou boilerplatu napodobit. Furt lepší než výjimky, ale prostě mají tam ještě spoustu prostoru k vylepšování.

Tady jsem se ztratil. Ukaž prosím ten lepší způsob (bez ironie), i kdyby si se měl opakovat.

Něco jako tohle:

let Ok x = f1 “some arg(s)”
    | Err err => cast err
let Ok y = f2 x
    | Err err => cast err
Ok $ use y

Je to všechno v top-level scope, řeší to chyby různých typů a ošetření chyb je zanořené. Žádný boilerplate.

No ale přesně tohle dělá ? třeba ve spolupráci s anyhow. A jednodušeji.

use anyhow::Result;

fn get_cluster_info() -> Result<ClusterMap> {
    let config = std::fs::read_to_string("cluster.json")?;
    let map: ClusterMap = serde_json::from_str(&config)?;
    Ok(map)
}

A když chci s tou chybou nějak pracovat?

| Err err => if is_not_found err then MkErrNotFound err else MkInternalServerError err

> A když chci s tou chybou nějak pracovat?

Kde přesně? V místě volání get_cluster_info(), nebo uvnitř?

Uvnitř, místo otazníku.

Hmm, uznávám, zajímavé. Pro mě dost nezvyk (což není argument).

V Rustu je konstrukce, říkají tomu if-let-expression. Zatím je to dost oškubaný, ale mají s tím velké plány. A mohlo by se to vzdáleně podobat tomu co popisuješ. Minimálně já jsem na to narazil, když jsem chtěl nějak zkrátit a pročistit if-expression.

To už tu padlo, if-let zbytečně “indentuje” celý kód pod sebou.

Co let-else?

Jak se k té chybě dostanu v else bloku (bez matche, if-let či jiného balastu)?

No právě že ne zbytečně. Obvykle skládám tyhlety bloky pod sebou, každý blok nějaká logika... (dalším krokem je už jen funkce). Možná jsem nakažený, ale tohle zrovna mi přijde na pohodu.

Když jich je 15, tak kód vypadá “skvěle” (viz co psal Atarist, i Rust se snaží o to samé, jen mu to zatím moc dobře nejde).

Asi úplně nechápu v čem je rozdíl u té indentace.

I ten příklad nahoře přece má error blok indentovaný. Golang bude mít ten blok ifů (i s errors.Is) indentovaný taky.

Nebo jde o to, že ten match pomíchá ok a error bloky?

Podivej se z velke dalky na Go kod. Zdalky uvidis (i kdyz to nemusis ani zaostrovat), kde zacinaji funkce a dalsi globalni deklarace - na nultem sloupci (a nic jinyho se tam neplete - ani typy parametru u funkci, ktere jich maji vic).

Dale uvidis uvnitr funkci na prvni tab. zarazce "happy path" kod. Nebude to tedy horizontalne rozdeleno na nejake ty try/catch/finally, ale vlastne vertikalni deleni. A v tom kodu bude opakujici se pattern `if err != nil` (proste se to opakuje, to nikdo necte, ale rozezna ten pattern hned, ani neresi jmeno te promenne), a zpracovani chyby bude vzdycky az na dalsi tab. zarazce, nikdy ne na prvni.

Kupodivu tam ani neni moc vyjimek - semtam nejaky rozeskok, smycka (ale uz treba telo smycky je typicky refaktorovano, takze neni smycka a v ni jeste error check).

https://maelvls.dev/go-happy-line-of-sight/

(i kdyz tedy zrovna ten ukazkovy kod by refaktoring potreboval jako sul :)))

Aha, teď už chápu o co Vám jde.

Část toho je vlastně Return early styl (třeba tady https://medium.com/swlh/return-early-pattern-3d18a41bba8).

A dál je to rozšířené na to, aby to bylo vizuálně jednotné a ve sloupcích. To by v Rustu šlo (tuply vracet umí), ale asi ne s pomocí Result.

Asi už chápu i jednu Calculonovu poznámku ohledně bolerplate, protože předpokládám, že myslel něco jako:

let happy = match func() {
  Err(IOError(e)) => { ... }
  Err(NetworkError(e)) => { ... }
  Ok(v) => v // boilerplate
}

happy.do_something_happy()

Ale možná že ekvivalentem v Rustu je něco jako:

let f = fce().or_else(|err| match err {
  IOError(e) => { Ok(fallback_value) }
  NetworkError(e) => { Err(FatalError(e)) }
})?

// otazník umožní skončit na fatální chybě
// nebo pokračovat s fallbackem

happy(f)

Takový kód dodrží pravidla pro odsazení errorů, neodsazení happy path a je tam minimum boilerplate. Místo if f, err = ...;err != nil { je .or_else(|err| )? což není moc rozdíl.

Ještě by to bylo lepší bez anonymních funkcí, v zájmu čitelnosti a jednoduchosti. Podle mě k tomu dospěje ten nový let-else, stačí přidat pattern matching i do té druhé větve.

Sranda je, že Go toho ideálu dosahuje bez rádobysofisti­kovaných konceptů (součtové typy, pattern matching) :)

Nedosahuje. Golang v klasickém if něco; err != nil patternu neumožňuje místo erroru vrátit placeholder hodnotu. A naopak v tom mém Rust příkladu by nebyl match nutný. Ify by to šlo taky.

A na anonymních funkcích není nic špatného, on if s přiřazením a ještě podmínkou také není zrovna syntaktický zázrak.

Takže ano, pokud Váš argument je, chci aby to vypadalo jako Golang, tak to žádný jiný jazyk nesplní.

Golang zase nemá borrow checker a NPE tam není nic neobvyklého, protože ten nil je všude (stačí prázdné pole...). Java 8 zavedla Optional a pár dalších funkcionálních vzorů a úplně to změnilo best practices (skoro přes noc).

Možnost pracovat s nil se dnes také považuje za antipattern a zdroj chyb: https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/

Nevím, co je “placeholder hodnota”. Anonymní funkce jsou v tomto kontextu zlo, nejde udělat return z vnější funkce (to umí akorát Smalltalk a je to výjimka). Navíc jsou mnohem méně čitelné. A o čitelnost tu jde. Tady zatím vede Go, C++, Zig, Julia… Uvidíme, co Carbon, až bude nějaký překladač. Nicméně Rust to jistě rychle dožene, mění se dost živelně.

Dobře si ten můj příklad prohlédněte. On totiž pro jeden typ chyby dělá return z vnější funkce. Sice nepřímo, díky Err a otazníku, ale dělá.

Placeholder je hodnota, která se použije v případě chyby. Například, když něco neexistuje. Zkuste to v Golangu, uvidíte, že ten kód začne vypadat o dost hůře.

Žádný zásadní problém s čitelností zrovna v tomto případě nevidím, je tam blok se syntaxí, kterou mnozí znají třeba z Ruby. On ani ten otazník není nový, viděl jsem ho už v JS a Swiftu (Optional chaining). V Golangu je zase neobvyklý středník uprostřed ifu, i když logiku i historii má (C a syntaxe for).

Go někdy možná mírně vede v čitelnosti (ale i to je hodně subjektivní), ale jen díky tomu, že nemá některé z pokročilých vlastností těch ostatních jazyků. Vím, že to byl úmysl, ale i ta generika nakonec přidali. Trošku mi to historicky připomíná situaci ohledně Java 1.4 vs. Java 5 (= poněkud nešťastně udělané generické kolekce).

Zig syntaxi osobně považuji za ještě méně čitelnou než Rust, ale je to spíš zvykem, protože jsem Zig přeskočil. C++ a čitelnost (obzvláště v přítomnosti meta šablon) také nejsou slova, která bych použil v jedné větě.

Na druhou stranu je C++ možná lepší pro DSL styl programování, protože v něm funguje přetěžování operátorů (a Python tady září). V Rustu to jde přes generické funkce, ale to už jsou znaky navíc.

Je velice snadné vybrat si jeden konkrétní příklad a pak na něm ukazovat, že kdokoliv to zapisuje jinak je nějak méněcenný. Najít protipříklad by nebylo těžké.

Jinak si jsou některé koncepty z Golangu, Rustu a dalších už hodně podobné, všichni sledují ten samý pokrok v oblasti programovacích jazyků. Jen tomu občas říkají jinými jmény.

To právě vidím, že nepřímo. A ten placeholder naopak nevidím, ve srovnání s jinými jazyky tu Rust v ničem nevede.

Ok, nazval jsem to tam fallback_value.

Nevede, ale ani neprohrává. Ony ostatní jazyky taky nespí a dobré nápady se nakonec různě rozšíří všude.

Tedy prazdne pole jsem v praxi nevidel, neni to nejakej idiom prevzatej z jinych jazyku? Protoze co s prazdnym polem (a vubec s polem) v Go? To je vetsinou strasne neelegantni struktura.

nil je proste null value, zrovna tento koncept (nulovych hodnot) je v Go pekny. Co pravda neni pekne, je mit moznost mit promennou typu rez a mapa s nilem.

U řezu to asi moc nevadí, ale u map si člověk občas nabije čumák :)

Jedno jestli tomu říkáte pole, list nebo slice. Každopádně nil je ekvivalentní prázdnému slice:

https://medium.com/@habibridho/golang-nil-vs-empty-slice-87fd51c0a4d

Pole je něco úplně jiného než řez. I v Rustu BTW.

Je, ale pro účely této diskuze to je jedno. Golang je prostě plný kontrol na nil. U řezů, errorů i dalších struktur.

Pád na nil hodnotě v Golangu jsem viděl mockrát, protože optional hodnoty v json se musí reprezentovat pointerem. A stačí mít složitější json strukturu a člověk si začne přát, aby do Golangu ten Optional chaining někdo rychle naimplementoval.

Protože místo root?.leaf?.le­af2?.hodnota najednou píšete 10 a více řádků kontrol na nil.

A absence abstrakce v této oblasti mě zrovna překvapila dost, protože Golang jako jazyk na "malé" webové služby zrovna parsování divných json dat řeší dost často.

Ved Rust ma na to "map_err".

Ja sa prikladanm k nazoru, ze v Go je to riesne neskutocne zle, tolko kodu a balastu okolo, hlavne je to otravne a mechanicke... zlate vynimky.

No ale na druhou stranu, ty if err delaji krasne rozpoznatelnou happy path. To je na Go zase dobry - vertikalne/ho­rizontalni struktura uz zdalky ukazuje zpracovani, ani se to nemusi cist.

Právě o tom tu celou dobu píšu (zanořování o jednu úroveň). Mít k tomu pattern matching jako v Idrisu by bylo akademicky pěkné, ale na to v Go kašlou, tam jde v první řadě o praktičnost a čitelnost (což se povedlo).

"No ale na druhou stranu, ty if err delaji krasne rozpoznatelnou happy path" - prave nopak, je to miesanie aplikacnej logiky a hapy path s infrastrukturnym kodom a osetrovanim chyb. To sa potom super cita, ked kazdy druhy riadok je "if err bla bla".

chybu takto osetris ASAP, na tom samym miste kodu, kde byla vracena. Lokalita...

(btw pokud je funkce i s osetrenim chyb delsi nez obrazovka dnesnich obrovskych monitoru, neni to chyba jazyka...)

A tady je právě problém Rustu, těžko se garantuje zároveň lokalita, odsazení kódu pro ošetření chyb a eliminace boilerplatu. Přitom taková trivialita. Hezká ukázka overengineeringu :)

Nesuhlasim, je to miesanie logiky a osetrovania chyb.

Pre to mam rad vynimky - ocakvane chyby sa osetria uz na vstupe, alebo zvolim metody, ktore vracaju alternativu resultu/metody Try...

A vynimky riesim globalne vdaka polymorfizmu.

Popravde vim, ze v nasem produkcnim kodu je *nekolik* mist, kde by se hodilo nechat probublavat vyjimky. Ale v 9x% je proste okamzita reakce na chybu v nasem pripade nejlepsi reseni; pochopitelne i nejlepe pochopitelne pro devely (protoze lokalita). Musi se to ale psat idiomaticky stylem "happy path je shora dolu", nikdy ne ve stylu if ok {}.

Potom je ten kod skutecne citelny naprosto bez problemu - rikam citelny, ale on se kod ve skutecnosti prakticky nikdy necte, rozpoznavaji se vzory, tj. vyznam maji vetsi celky, nez jen lexemy nebo dokonce jednotlive znaky.

Ano, ono i to Go má ve standardní knihovně několik míst, kde nechává probublávat výjimky místo vracení chyby. Někde výše se pak výjimka zachytí a zpracuje/zahodí. Například HTTP server to tak má. Ale je to opravdu jen pro výjimečné případy. Toto by se Rustu hodilo taky.

A presne pre to povazujem Go za zly jazyk propaguje nieco comu sa vo vsetkych vysleych jazykoch snazia vyhnut a komunita okolo Go si to este chvali. Proste ako jazyk s praveku.

Unwrap a expect jsou naprosto v pohodě třeba v testech, v těle maker a při prototypování. Jinak je třeba v našem kódu zakazujem linterem. Je to prostě jen nástroj, který se dá použít dobře i špatně.

Unwrap a expect považuji za ekvivalent LogicException. Tedy chyba, která nemá vůbec nikdy nastat, protože prostě ne. Ideální by bylo, aby to bylo možné odchytit během kompilace, což ale ne vždycky jde, a tak to alespoň odladíme co nejbrutálněji (rozuměj odskáčou to zákazníci, ale alespoň to bude rychle).

No, a proto je povolujeme jen v makrech a testech, tam to zákazník fakt nepotká.

Si asi nerozumíme. Chyba, která nemá nastat. Jak ji řešíte?

Záleží na situaci - pokud to jde, ošetřuju ji compile time, tam mi expect() nevadí (makra, const fn). Ve spoustě případů není nijak komplikované poslat ji výš (zvlášť v aplikacích kde používáme eyre / anyhow).

Jsou i ojedinĕlé případy kdy to necháme přes review projít i v produkčním kódu, tam to ale musí mít dobrý důvod a jeho dokumentaci. Z té kategorie mě teď z našeho kódu napadá jen situace, kdy potřebuju mime type, který nezná mime crate od hyperia. Bohužel má jen parsovací funkci, která není const. Na stranu druhou, dokud někdo v kódu nerozbije konstantu s mime stringem, nemá to jak selhat :)

Větev kódu, kam se výpočet nikdy nedostane :) Na to má Idris zabudovanou funkci “absurd”, tak se dá již v době překladu zajistit, že se tam program opravdu nikdy nedostane. Geniální věc.

Viz můj předpříspěvek. Teď se bavíme o praxi v Rustu.

Zrovna tohle by v Rustu mohlo jít podobně.

Odhaduji, že tak silný typový systém nemá.

Má poměrně slabý typový systém, ale něco jde pomocí Void a unreachable.

Ještě se hodí Never type

Tebe dříve zajímaly sofistikované typy v Haskellu. Malá ukázka v Rustu:

fn my_unwrap<T>(r: Result<T, Void>) -> T {
    match r {
        Ok(x) => x,
        Err(e) => absurd(e),
    }
}

V teorii typů klasika :) Když tohle projde překladačem, je na věky věkův zaručeno, že unwrap nikdy neselže.

Jinak je hodně škoda, že v případě hodnot má Rust jen const generics, kdybychom mohli mít za běhu něco jako Vector<T, n:usize>, člověk by si vůbec ušetřil spoustu ošetřování chyb, neb by mu to ověřil už překladač v rámci typové kontroly.

Něco jako heapless::Vec?

https://docs.rs/heapless/latest/heapless/struct.Vec.html

Ne, protože velikost je určena už v době překladu, ne až za běhu.

Hezké :) Go ten Zen fakt splňuje, stejně jako Julia a mnohé funkcionální jazyky. Rust je bohužel na druhém pólu, ale pár výhod má také. Nicméně fajn postřeh :)

Go zen zial zlyhava hned v prvom bode.

Aha, tak to je zajímavé:

Invalid type comment or annotation mypy(error)

"Aha, tak to je zajímavé." To není zajímavé, to je k pláči, že Python něco takového vůbec pobere
Tvoje tvrzení, že _dataclass musí být anotovaná_ je nepravdivé. MyPy je nástroj vytvořený právě na odhalování takového nesmyslného designu Pythonu. Navíc má sám dost much.

13. 11. 2022, 21:46 editováno autorem komentáře

> MyPy je nástroj vytvořený právě na odhalování takového nesmyslného designu Pythonu. Navíc má sám dost much.

MyPy je nástroj, který kontroluje shodu typových anotací s reálem. Pokud víš o nějakých mouchách, klidně je nareportuj. Ale hledání v reálné praxi bezvýznamných mušek ve snaze shodit Python je legrační. A teď k tomu, proč není Ruby, tj.japonský Smalltalk (tím pádem prý tedy zen), v praxi příliš oblíbený: Protože (skoro) nikdo nemá zájem programovat ve Smalltalku, natož japonském. Tolik realita.

Ruby propáslo svoji šanci. V dobách největšího rozmachu Ruby on rails (ruby 1.8?) bylo ukrutně pomalé. Bytekód a další optimalizace přišly příliš pozdě.

Jako jazyk to bylo celkem příjemné na psaní a možnost snadno rozšířit existující typy se hodila.

Nicméně problémy taky byly. Rychlost už jsem zmínil a další co si pamatuju byl Unicode.

Nicméně souhlasím s tím, že Python trošku bobtná.

Smalltalk je náhodou fajn, akorát bych Ruby neoznačoval jako "japonský Smalltalk".

Proč ne Ruby:
- je pomalý
- monkey patching

Proč ne Python:
- je pomalý
- duck typing
.)

Však já taky Python nemusím. Lua udělá tu samo práci a je rychlejší (je stejně beztypová jako Python, takže stejná banda).

Monkey patching je naopak super, NASA takto opravovala bugy na sondách stamiliony kilometrů daleko (v Lispu).

Zrovna tak jako je super duct tape, pokud není k dispozici nic lepšího. Otázka ale zní, zda je v pořádku tohle používat v normálním kódu. IMO není, je to čistá zvrhlost.

Je to pro speciální případy. Hodí se to nejen u sondy někde u Pluta, stačí mít na superpočítacím klustru výpočet na měsíc, v jehož průběhu fixnu třeba po týdnu například race condition. Zrovna v Julii se to dělá dost často.

14. 11. 2022, 13:57 editováno autorem komentáře

Ale na to přece nepotřebuju žádný monkey patch, dá se reloadnout modul nebo něco takového.

Dost dobře nedá, když v něm běží výpočet.

> Dost dobře nedá, když v něm běží výpočet.

To je pak otázka, jak dobře je ta struktura navržená. Zaměnit jednu funkci samozřejmě jde i v Pythonu, ale obecně se to moc nepropaguje.

Je to standard například v Juliahubu. Vědci tak píšou.

To je poněkud nešťastný argument, že "vědci tak píšou". Je samozřejmě v pořádku, že to zákazník zužitkuje, o tom žádná. Ale nepovažuji za šťastné, kdy jazyk umožňuje, troufám si tvrdit zbytečné, konstrukce, které komplikují dlouhodobou udržitelnost.

Pro pořádek: na monkey patchingu není špatné to, že můžeš změnit chování nějaké funkce; ale to, že se ta změna nekontrolovatelně šíří do kódu, který s tím nepočítá. Pokud dokážeš něco takového nějak ohlídat, pak to může být, věřím, skvělý nástroj. V Ruby to prostě jenom naimplementovali a děj se vůle BilaGatese.

Tak o to jde, že se ta změna nasazuje kontrolovaně. Zajímavé je zejména to, že se dynamicky patchuje v jazyce překládaném do nativního kódu.

Jak ta kontrola vypadá?

Controller to přes nějaké interní RPC (nebo spíše messaging) pošle na všechny mašiny, kde to scheduler zařadí k překladu a patchi. V podstatě se přepíše tabulka pro dispatch. Je to takový Openstack na aplikační úrovni.

Jak vypadá ta kontrola. Na tom patchnutí není nic zajímavého :-)

Pokud bych si měl vybrat mezi monkey patching a save-restore state, tak raději to druhé. Je to sice těžší, ale přijde mi to takové bezpečnější.

Save/restore state na clusteru, co má třeba 1000 mašin? To je výzva :)

Toho si jsem vědom. Proto se nedivím, že se monkey patching používá - na naimplementování je to trivka a za všechno pak můžou zákazníci, že to zle používaj.

Jasně, každý nesouhlas s mainstreamem je hned flamewar.
Co posíláš viz "Teď trochu jiných statistik: https://statisticstimes.com/tech/top-computer-languages.php" je právě holý nesmysl. Všichni víme jak se tyhle statistiky získávají. Že nemalá část webu běží na Ruby je mnohem zajímavější informace než že všichni začali do Googlu psát otázky jak se v Pythonu udělá X...

To má mnoho důvodů: hodně škol přešlo na Python kvůli jednoduché syntaxi. Půlka vědeckého světa lepí nativní kód v Pythonu, což z něho dělá duck-tape. Pár šílenců v něm je schopno udržet pořádek na větších projektech za cenu neuvěřitelné sebedisciplíny a let dřiny.

Podívej se na github, jaká je kvalita Python kódu. Půlka z nich ani neumí vytvořit balíček. Taky se div když tu je setup.py, setup.cfg, pyproject.toml...
Nevím proč se tak rozčiluješ. Já se jen podivoval nad tím sentimentem, že snad Python byl vynechán. Jo a ten toy projektík jen ukazuje jak shodit Python bez použití C/FFI... to je jak je Python memory safe.

11. 11. 2022, 17:03 editováno autorem komentáře

Ne vzdy to dodrzuji sami tvurci Pythonu ne?

https://github.com/DavidBuchanan314/unsafe-python

Například Kibana a Enterprisesearch z Elasticsearch používají Ruby

Zrovna se dívám na logstash. Tak ten také používá Ruby

"Skoro nikdo nepoužívá"? To fakt těžko.

Zalezi v jakem prostredi se pohybujete. Treba ja u zadneho ze svych zakazniku Rust nevidim a to bastli fakt ruzna reseni.

Až konečně někdo vymyslí, jak na embedded platformách rozchodit v Rustu zároveň přerušení s nízkou/determi­nistickou latencí a zároveň sdílení proměnných mezi přerušeními a hlavní smyčkou, tak to možná začne být zajímavý.

A “static mut” nestačí? Ve spojení s cortex_m::inte­rrupt::free nebo něčím podobným?

Něco jako tohle při používání std::sync::Mutex:

static promenna: Mutex<Data>

Nebo tohle v nostd?

static FOO: Mutex<RefCell<i32>> = Mutex::new(RefCell::new(42));

(z dokumentace k https://docs.rs/critical-section/latest/critical_section/struct.Mutex.html)

Bez zámku je to buď nebezpečné nebo jsou potřeba atomické typy. Se zámkem je to nebezpečné taky, pokud interrupt nastane a zámek je zamčený.

Ten druhý příklad tím netrpí, protože critical_secti­on::Mutex zakazuje interrupty. Ta RefCell je tam jen kvůli některým speciálním případům (zanoření a klony critical section tokenů).

Pokud víte, že tohle dostatečně řeší logika aplikace, UnsafeCell to umožní. Jen to nepohlídá kompilátor za Vás. Což v C / C++ taky nedělá.

Máš pravdu, že takový údaj v životopisu nic moc neznamená. Ale ty lepší personálky se skutečně snaží s těmi lidmi mluvit a něco zjistit. Ochota dělat v Rustu znamená, že to ten člověk možná opravdu dělat bude a nemá řeči typu "Rust je nanic, stačí psát pořádně v C". A pokud ten člověk skutečně něco dělal v podobném jazyce (ideálně v C++) a je obecně použitelný, tak se prostě do projektu v Rustu zapojit dá.

Doufám že někdy nějakou lepší personálku potkám...