Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:
The defer keyword is almost entirely supported, with the exception of deferring some builtin functions.
Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.
Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.
GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu.
Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.
Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.
116 Odpovědí
36016 Zhlédnutí