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

[Franta Kučera]

Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)

Kdysi jsem měl číst ceník v XML, který prodejce generoval tuším v Pohodě. V záhlaví sada Windows-1250, v obsahu francouzský parfém. Výsledkem nevalidní XML. Prodejce byl bohužel přesvědčen, že má vše správně. Lepení XML bohužel pokaždé nevyjde.

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Viz např. v PHP:

Kód: [Vybrat]

<?php

$xw = xmlwriter_open_memory();
xmlwriter_set_indent($xw, 1);
$res = xmlwriter_set_indent_string($xw, "\t");

xmlwriter_start_document($xw, '1.0', 'UTF-8');

xmlwriter_start_element($xw, 'zkouška-kódování');

$text = "čeština v UTF-8";
xmlwriter_start_element($xw, 'správně');
xmlwriter_text($xw, $text);
xmlwriter_end_element($xw);

// tato data se načetla např. ze souboru nebo z databáze:
$text = "čeština v ISO-8859-2";
$text = iconv("UTF-8", "ISO-8859-2", $text);
xmlwriter_start_element($xw, 'špatně');
xmlwriter_text($xw, $text);
xmlwriter_end_element($xw);

xmlwriter_end_element($xw);

echo xmlwriter_output_memory($xw);

?>
Nebo v Javě:

Kód: [Vybrat]

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

public class BadEncodingXml {

    public static void main(String[] args) throws Exception {
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.newDocument();

        Element root = d.createElement("zkouška-kódování");
        d.appendChild(root);

        {
            String text = "čeština v UTF-8";
            Element správně = d.createElement("správně");
            správně.appendChild(d.createTextNode(text));
            root.appendChild(správně);
        }

        {
            String text = "čeština v ISO-8859-2";
            text = new String(text.getBytes("ISO-8859-2"), "UTF-8");
            // Java tam aspoň dá: � takže XML je validní, byť data jsou chybná
            Element špatně = d.createElement("špatně");
            // případně: text = "\0";
            špatně.appendChild(d.createTextNode(text));
            root.appendChild(špatně);
        }
       
        TransformerFactory tf = TransformerFactory.newInstance();
        Transformer t = tf.newTransformer();
        t.transform(new DOMSource(d), new StreamResult(System.out));
    }
}

Chyba se dá udělat i při násobení dvou čísel, ale asi to neznamená, že přestaneme násobit, že?

Tady taky narážíme na to, že vývoj softwaru není jen o technologiích, ale i o lidském chování. Pro spolupráci je kolikrát důležitější než nedělat chyby, nebýt kretén a uznat, že v programu chyba je a opravit ji.

[Reklama]

[Tomáš Crhonek]

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Knihovny v jazycích, které jsem používal, používaly zásadně unicode, takže nepořádek ve stringu by musel být už před tím. Stejně je s podivem, že se dneska ještě používá ISO nebo starší kódování. Pokud je celý program v unicode, tak se tam špatný text v podstatě zadat ani nedá, to by to tam musel někdo špatně už napsat.

[Kit]

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Tady taky narážíme na to, že vývoj softwaru není jen o technologiích, ale i o lidském chování. Pro spolupráci je kolikrát důležitější než nedělat chyby, nebýt kretén a uznat, že v programu chyba je a opravit ji.

Pokud by Pohoda to cizí písmenko zakódovala jako entitu, problém by nenastal.

[novomente]

Když vývojář dostane zadání, musí ho napřed analyzovat a vybrat pro něj vhodný jazyk, ve kterém ho je nejlépe zakódovat. Každý programovací jazyk má svá specifika (výhody i nevýhody), která se musí při oné volbě brát v úvahu.

Pokud se bavíme o komerčním vývoji, o firmách, tak tam je většinou rozhodnuto předem. Je tam obecně snaha omezovat tyhle „zoo“ programovacích jazyků a technologií a mít to jednotné, aby mohla fungovat zastupitelnost, aby jeden programátor mohl přecházet mezi různými projekty té firmy a nestávalo se ti, že máš několik volných programátorů v jazyce X, ale práci máš pro programátora v jazyce Y.

Vybírat si můžeš, pokud je to tvůj projekt nebo jsi šéf vývoje a máš za úkol stavět něco na zelené louce. I tam je ale dobré myslet na to, kde najdeš potřebné programátory a jaké budou mít požadavky ostatní projekty té firmy, abys to měl do budoucna pokud možno jednotné. Větší firmy si můžou dovolit větší pestrost (byť to není moc záměr, spíš důsledek jakési volnosti a experimentů), u menších je spíš snaha mít jeden hlavní jazyk. A i když je někde víc jazyků současně, tak typicky spíš z historických důvodů a postupně se přechází, nové projekty se začínají jen v tom aktuálním.

Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?

Každý má nějaký styl, co je mu nejbližší a přirozené, k čemu se na základě svých zkušeností dopracoval. Spíš než hodnotit, co je správně a odsuzovat, co je špatně, je užitečnější se zajímat, co k tomu dotyčného vedlo, na základě jakých zkušeností k tomu došel. Na druhou stranu, pokud spolu ti lidé mají pracovat v jednom týmu na jednom projektu, tak je dobré, aby si domluvili nějaký kompromis a společné konvence, které budou dodržovat – rozumný člověk si může zachovat svůj názor, ale zároveň si je vědom toho, že dělat to „o trochu horším“ způsobem, ale jednotně, je užitečnější, než když to budou dělat všichni „lépe“ ale každý jinak.

Celkem jsem to musel čtyřikrát přepisovat prakticky od nuly, neboť jsem narazil na okamžik, kdy už jsem se v kódu sám nevyznal. Četl jsem, že dobrou věcí v programování je určit si nějaký svůj "styl" a toho se pak držet.

Programování už není zábava pro nerdy. Dneska je to business. Takže:
- kolik bude stát programátora číst existující kód?
- kolik bude stát kód napsat?
- kolik bude stát přidání nové funkcionality?
- cenu snižuje znovupoužitelnost
- kdy a kde nastanou chyby a kolik nás to bude stát?

Proto se vymýšlí nové jazyky, jinak by nám ten Assembler bohatě stačil.

Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?

Ano, a je to špatné. Protože to jde proti výše uvedenému.

Třeba mě se stalo, že jsem předělal nějakou část kódu a pak jsem se zamyslel nad tím, kolik práce s adopcí těch změn bude mít kolega. A nakonec jsem to zahodil jako neefektivní. Přínos mých změn byl menší jak nutnost kolegu přimět ho adoptovat.

Mnohokrát vám děkuji za odpověď. Byla mi velkým přínosem.

nm

[Vladimír B.]

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

Psal jsem nedavno jeden primitivni stream procesor, na stdin prijde hromada JSONu, udela to urcitou analyzu pres klouzave okno, vysype na stdout, slouzi jako plugin do jineho softu.

Prototyp v pythonu funguje ok.
Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.

Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.

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

To mi přijde velmi podezřelé.

Co se týče stdin, tak tuším, že v pythonu je ve výchozím stavu bufferovaný, v golang ne. Jinak nevím, v čem by práce se stdin mohla být jiná/více optimální.

Co se týče deserializace jsonu, tak tam můžou být rozdíly velké, i v rámci různých knihoven ve stejném jazyce. Každopádně pořád bych očekával, že optimálnějsí knihovna v golangu bude rychlejší jak optimálnější knihovna v pythonu. Samozřejmě záleží na vstupu - těžko dělat úplně obecné závěry. Nicméně rychlý test mi dává zapravdu (deserializace 1.5e6 menších jsonů):

4.297s python json
1.618s python orjson

2.620s golang json
0.721s golang easyjson

0.393s rust serde_json

Když vezmu standardní knihovny v golangu vs pythonu, je golang rychlejší. Když vezmu optimálnější knihovny třetích stran (easyjson vs orjson), je golang rychlejší. Nicméně pravda - pokud vezmu lepší python knihovnu a standardní golang knihovnu, může být python rychlejší.

Standardní json knihovna v golangu upřednostňuje správnost nad rychlostí - před deserializací a po serializaci provádí ještě zvlášť kontrolu vstupu/výstupu, jestli je validní. Tak kontrola trvá skoro stejně tak dlouho, jako vlastní serializace/deserializace. Čili jenom tím golang ztrácí cca polovinu výkonu. Proto u easyjson pozor na to, že pro nejvyšší výkon je potřeba volat přímo metodu UnmarshalJSON na dané struktuře místo standardní funkce json.Unmarshal (pozn. easyjson generuje kód přímo pro serializaci/deserializaci konkrétních typů).

Pak je ještě možnost napsat to v rustu.

[Reklama]

[Zopper]

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Knihovny v jazycích, které jsem používal, používaly zásadně unicode, takže nepořádek ve stringu by musel být už před tím. Stejně je s podivem, že se dneska ještě používá ISO nebo starší kódování. Pokud je celý program v unicode, tak se tam špatný text v podstatě zadat ani nedá, to by to tam musel někdo špatně už napsat.

No, teoreticky jo. V praxi se, obzvlášť u velkých a starých aplikací, může stát, že to někde uteče. Aplikace samotná je třeba unicode, ale nějaká komponenta někde bokem, třeba nějaká databáze, nebo mezivrstva, není správně nakonfigurovaná. Ale protože to nějak funguje pro ty běžné vstupy, tak si toho nikdo ve firmě nevšimne, a těch pár zákazníků, co to vidí, se neobtěžují to nahlásit a berou to jako fact of life, protože i třeba Adobe má ve svém error formuláři kódování (nebo font) blbě: "Došlo k chybi" místo "ě".

[Ondrej Nemecek]

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

(...)

Prototyp v pythonu funguje ok. Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.

Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.

To mi přijde velmi podezřelé. Co se týče deserializace jsonu, tak tam můžou být rozdíly velké, i v rámci různých knihoven ve stejném jazyce.

(...)

Rychlost JSON serializace není moc validní kritérium pro výběr jazyka. Pro libovolný jazyk totiž vyberu dostatečně rychlou knihovnu anebo použiju binding na C, pokud je rychlost serializace skutečné úzké hrdlo. Validní kritéria jsou úplně jinde (vyspělost a vlastnosti jazyka a jeho runtime, rozšířenost, podpora, přenositelnost, kompatibilita, ekosystém, dostupnost vývojářů, ...).

[Ondřej Janovský]

Zdravim.

Měl bych dotaz. Bylo by dobré přejít z JAVA na RUST? Už někdo z vás přešel z jiného jazyka a začal se věnovat výhradně RUSTu?

nm

Přešel jsem z Javy do Rustu. Před tím jsem přešel z Basicu do Assembleru, pak do Pascalu, pak do C, pak do Delphi( zase Pascal), užil si PC-FAND, Mumps, naskočil do Javy, Javascriptu, zkusil GoLang a teď dělám v Rustu.

Za těch 44 let co programuji jsem zjistil jednu pro mě zásadní věc. Hlavní není jazyk, ale schopnost analyzovat zadání, rozložit do dílčích řešení, promyslet souvislosti s okolním světem ... a pak použít konkrétní jazyk - stavebnici (Lego, Merkur, Mechano, ...).
Každý z jazyků mě naučil nové věci, nové pohledy. Takže doporučuji jich vyzkoušet co hrdlo ráčí.

Dnes se zabývám Rustem, líbí se mi jeho otravnost, buzerace. Příslib bezpečného kódu, zabránění mnoha chybám už při překladu. A velikost a rychlost výsledného kódu. Čas co jsem ztratil na kódováni, než to šlo přeložit, se mi vrátil na menším počtu chyb. A že se umím střelit do vlastní nohy mnoha roztodivnými způsoby

[Jin Rys]

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

(...)

Prototyp v pythonu funguje ok. Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.

Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.

To mi přijde velmi podezřelé. Co se týče deserializace jsonu, tak tam můžou být rozdíly velké, i v rámci různých knihoven ve stejném jazyce.

(...)

Rychlost JSON serializace není moc validní kritérium pro výběr jazyka. Pro libovolný jazyk totiž vyberu dostatečně rychlou knihovnu anebo použiju binding na C, pokud je rychlost serializace skutečné úzké hrdlo. Validní kritéria jsou úplně jinde (vyspělost a vlastnosti jazyka a jeho runtime, rozšířenost, podpora, přenositelnost, kompatibilita, ekosystém, dostupnost vývojářů, ...).

Standardní knihovna pro JSON byla v GO velmi pomalá - na možnosti jazyka. Verze 2 zrychlila práci cca 2,5x.
Srov. https://medium.com/@kevalsabhani123/gos-new-json-v2-api-is-it-really-faster-a-benchmark-showdown-%EF%B8%8F-44df8bf20fd5

[Standa Blábol]

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

Psal jsem nedavno jeden primitivni stream procesor, na stdin prijde hromada JSONu, udela to urcitou analyzu pres klouzave okno, vysype na stdout, slouzi jako plugin do jineho softu.

Prototyp v pythonu funguje ok.
Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.

Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.

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

To mi přijde velmi podezřelé.

Co se týče stdin, tak tuším, že v pythonu je ve výchozím stavu bufferovaný, v golang ne. Jinak nevím, v čem by práce se stdin mohla být jiná/více optimální.

No, to je prosta realita. JSON processing pomaly jaxvina a co se tyce stdio, golang furt na neco cekal, veru nevim na co. Ted uz nemam vystup profileru, ale tusim, ze se tam potloukal GO oblibeny pthread_cond_wait, pricemz neslo o nic jinyho, nez vzit stdio nasekany podle newline a strkat do nekolika channelu, kde si to prebiraly gorutiny. Pokusel jsem se tam pozapinat nejake lepsi nez default cachovani, ale to pomohlo tak 20% vykonu nahoru.

A popravde GO samo sebe nijak nepropaguje jako realtime jazyk, proto me prekvapuje, ze se chova v defaultu tak debilne.
A veru me sejri, ze i takovou trivialitu musim resit a ladit, v pythonu pro pojidace kolacu jede vse na lusknuti prstu...