Vlákno názorů k článku PostgreSQL 18: třicet let otevřeného vývoje databáze od Ondřej Kolín - Přečteno, potvrdil jsem si názor že dělat DB...

Přečteno, potvrdil jsem si názor že dělat DB je těžký (včetně správného používání).

Co mě zaujalo je použití mesonu. Vlastně je to poprvé co jsem na něj narazil mimo GNOME a mám z toho radost, že se prosazuje.

Dík za články!

Postgres potřeboval něco, co by šlo použít napříč všemi podporovanými systémy - a kombinace meson, ninja je rozumná volba. Letos se kvůli Postgresu portoval meson na AIX.

Pro mne, co by autora extenzí, je konfigurace buildu, relativně nezajímavá, pokud jsou hotové skripty. Pro meson bohužel hotové nebyly, takže jsem je musel napsat. Měl jsem problém s tím, že pár kroků, které bych s make udělal triviálně v mesonu nejde udělat. Meson není složitý, a je k němu relativně dobrá dokumentace. V dokumentaci mi ale chyběla kapitola nebo FAQ typu "meson pro uživatele configure/make". Nenašel jsem dokumentaci, dokument, který by odpovídal na moje otázky.

Přijde mi, že je to dost analogické se systemd (nezpochybňuji výhody systemd vůči init skriptům). U startup skriptů nebo u make se stačilo naučit pár principů a relativně jednoduchý univerzální jazyk, a člověk mohl začít něco dělat. U systemd nebo mesonu je potřeba se toho naučit na začátku mnohem víc a je mnohem víc potřeba znát a dodržovat určité konvence. V obou případech jsem ale nenašel tutorial, který by mi sedl (a dnes dohledat něco kvalitního na netu, pokud člověk není expertem na danou oblast) skoro nejde.

Ad „Co mě zaujalo je použití mesonu. Vlastně je to poprvé co jsem na něj narazil mimo GNOME a mám z toho radost, že se prosazuje.“

Když se na to podívám z perspektivy toho, že stavím systém od základů (bootstrappable build), tak to nevnímám zrovna pozitivně, protože to přidává závislost na Pythonu – a to i v případě, že chci sestavit aplikaci, která si vystačí s C nebo C++ kompilátorem tzn. typicky GCC nebo LLVM/CLang, v některých případech by dokonce stačil minimalistický kompilátor typu TinyCC.

S mesonem by neměl být až tak velký problém cross compilation.

Když se na to podívám z perspektivy toho, že stavím systém od základů (bootstrappable build), tak to nevnímám zrovna pozitivně, protože to přidává závislost na Pythonu – a to i v případě, že chci sestavit aplikaci, která si vystačí s C nebo C++ kompilátorem tzn. typicky GCC nebo LLVM/CLang, v některých případech by dokonce stačil minimalistický kompilátor typu TinyCC.

No ono je to někdy ještě mnohem horší. Kdyby to byl jen python, tak ok. Jenže ten má externí moduly někdy C/C++, někdy třeba v Rustu. Takže je pro "bootstrap" potřeba LLVM/Clang nebo GCC a také Rust. A kompilace Rustu trvá několik hodin i na Ryzen 5800. Takže zkompilovat nějaký projekt, třeba Sambu (která je sice napsaná v C/C++, ale na něco potřebuje Python), tak to znamená 8h reálného času jen kompilací dalších a dalších závislostí.

Proto já vždy u každého jazyka preferuji a vyžaduji pouze věci ze standardní knihovny. A u všech zmíněných jazyků je tak bohatá, že vůbec není potřeba knihovny jiných jazyků.

Proto v Golangu používám výhradně standardní knihovnu, kompilace mého programu je to 1s a kompilace Golangu samotného cca 15minut. Takže update na nejnovější verzi 1.24.2 je hotova do 20 minut, včetně všech mých programů.

Stejně tak make, meson, ninja apod. Proč jako? V každém moderním jazyku za posledních 15 let je k disposici taková hromada interních prográmků, že na Golang opravdu nikdy nepotřebuju psát Makefile, protože stačí jen go build, případně rovnou go install. S přechodem od Pythonu ke Golangu jsem rovnou odinstaloval všechny maketool, patchtools apod.

Předpokládám, že stejně je to i v Rustu. Cargo atd.

Takže už je nutnost použití Makefile nebo čehokoliv externího je známka toho, že by se ten projekt měl přepsat.

Ale tohle je můj minimalistický pohled na svět, PostgreSQL stále letí dopředu skvělou rychlostí a jestli mají tooling, který jim vyhovuje, je to OK.

(Zrovna kompilace PostgreSQL na FreeBSD je hotová do 3 minut.)

Ad „Proto já vždy u každého jazyka preferuji a vyžaduji pouze věci ze standardní knihovny. A u všech zmíněných jazyků je tak bohatá, že vůbec není potřeba knihovny jiných jazyků.“

Vidím to úplně stejně. Kolikrát říkám, že vyšší programovací jazyk (případně Unix resp. GNU/Linux) a jeho standardní knihovna jsou frameworkem samy o sobě, protože lidi na to dneska často zapomínají a mají tendenci automaticky, bez přemýšlení, zda je to nutné, tam nějaké další knihovny a frameworky natlačit (a staví „unixy“ a „lispy“ nad těmi existujícími a znovu-vynalézají kolo).

Kód, který závisí jen na standardní knihovně, je za mne ideální knihovnou nebo programem. Protože mi poskytuje ten svůj jedinečný přínos (svoje inovativní algoritmy, datové struktury), aniž by mi nutil nějaké tranzitivní závislosti. Spolupráce a kompozice s ostatním softwarem je možná, ale skrze abstraktní rozhraní a princip DI (dependency injection). Jednoduchý příklad: knihovna grafického filtru obsahuje jen ten svůj algoritmus práce s pixely, ale nenutí mi závislost na spoustě knihoven pro konkrétní grafické formáty. Načtení a uložení dat v těchto formátech probíhá vně toho filtru, případně jsou dostupné implementace nabídnuty filtru formou DI, ale závislost je maximálně na abstraktním rozhraní. Výsledkem je flexibilita a možnost použití té knihovny v libovolných prostředích a konstelacích softwarových komponent.

Někdy se těm tranzitivním závislostem vyhnout nejde (zejména těm, definujícím ta abstraktní rozhraní, nebo v případě zastřešujících knihoven a programů, jejichž přínos spočívá v tom, že poskládají dohromady nějaký funkční celek), ale čím méně jich je, tím lépe. Je dobré tyhle dvě funkce rozlišovat a izolovat – užitečné algoritmy dát do samostatných knihoven bez dalších závislostí, aby šly použít samostatně i bez toho zastřešujícího kódu.

19. 4. 2025, 10:02 editováno autorem komentáře