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 "ě".