Budoucnost Rust v embedded světě

[Martin Sivák]

Rust je IMHO možná náhrada za C++, nikoli za C. Jakožto embedded a low-level vývojáři mi Rust nepřináší žádné killer-features, jen mi svazuje ruce. Nemám rád jazyky, které mě chtějí školit a vodit za ručičku, svá dětská léta mám už dávno za sebou.

A proto velké firmy hlásí, že největší počet problémových chyb byl právě z oblasti správy paměti, kde C neposkytuje žádné pomůcky.

K příkladům, jež tu padly - když z jakéhokoli důvodu budu chtít znát mimo příslušný lexikální kontext absolutní adresu, na níž byla na zásobníku nějaká lokální proměnná, tak nechci, aby mi nějaký blbý překladač házel klacky pod nohy, protože mě považuje za vola. Potřebuji se soustředit na řešení svého problému, ne přemýšlet nad tím, jak přemluvit překladač, aby udělal to, co potřebuji.

Adresu si klidně získejte i v Rustu, jen nesmí opustit funkci, ve které je platná. A za vola by Vás považovaly i bezpečnostní standardy jako MISRA C.

On ten Váš problém (máte praktický příklad?) se možná dá vyřešit přímým přístupem do paměti, ale tak nějak tím riskujete celkem velkou plejádu možných chyb. Od poškození zásobníku až po přístup do náhodné paměti a záhadné pády aplikace.

Rustí borrow checker je přísný a neodhalí všechno (jak ilegální, tak legální aplikace). Proto máme i unsafe, kde je povinností programátora zdokumentovat, proč je zrovna tento trik v pořádku, aby to při code review bylo naprosto zřejmé i ostatním.

Osobně jsem stejný projekt (průměrně komplikovaný firmware a rádiový protokol pro senzorovou síť) postupně napsal v C, C++ i Rustu a i přes přísnost jazyka je ten Rust nejlépe udržovatelný.

Samozřejmě existuje třeba demo scéna nebo triky z 80. let se samopřepisujícím kódem. Některé ty výsledky byly úžasné... ale do prostředí s garantovanou bezpečností se to prostě nehodí.

[Reklama]

[Jožka Niemand]

A proto velké firmy hlásí, že největší počet problémových chyb byl právě z oblasti správy paměti, kde C neposkytuje žádné pomůcky.

Stačí, aby velké firmy angažovaly zkušené profesionály za odpovídající peníze. Vyřešilo by to i další problémy.

Adresu si klidně získejte i v Rustu, jen nesmí opustit funkci, ve které je platná. A za vola by Vás považovaly i bezpečnostní standardy jako MISRA C.

Proto jsem napsal "mimo příslušný lexikální kontext" - tedy tím chci říci, že to adresu chci právě mít mimo tu funkci. MISRA je dlouhodobě terčem různé kritiky, to není žádný argument. Jestli to dává, nebo nedává smysl, to nejlépe posoudím já sám. Že si někdo neumí představit, k čemu by to mohlo být dobré, je jeho omezení, nikoli moje. Vybavuje se mi Horníček s Werichem: "H: Postavit loď na kopci? To je ale blbost! W: No, pravda, taky se mu tenkrát všichni blbci smáli."

On ten Váš problém (máte praktický příklad?) se možná dá vyřešit přímým přístupem do paměti, ale tak nějak tím riskujete celkem velkou plejádu možných chyb. Od poškození zásobníku až po přístup do náhodné paměti a záhadné pády aplikace.

Teď zrovna mě nenapadá, k čemu bych to využil. Ale život mě za ta léta naučil, že umí nastolovat situace, jež nevymyslí ani ta nejbujnější fantazie. Víte, já si velmi dobře uvědomuji, jaké chyby to může způsobit, to mi tu nemusíte vykládat. Stejně jako si uvědomuji, co se může stát, když v autě přejedu dvojitou plnou čáru. V naprosté většině situací to činit nebudu. Ale dovedu si představit i situace, kdy bych to udělal, zatímco kdyby tam bylo svodidlo, tak mám situaci výrazně komplikovanější.

[oss]

Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).

Co sa tyka C++ tak pri malych projektoch je vdaka uniq_ptr takmer nemozne spravit chybu, ked sa clovek nesprava ako prasa.

Skor dufam, ze sa v embedet svete presadi Zig, na low-level veci, WASM a embedet ovela zuajimavejsia volba ako Rust alebo Go.

[linuxak]

Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).

Tak to jsi dělal něco špatně, půlka kódu rozhodně nemusí být unsafe ani v embedded.

Co sa tyka C++ tak pri malych projektoch je vdaka uniq_ptr takmer nemozne spravit chybu

Ehm...

Kód: [Vybrat]

auto a = std::make_unique<int>(42);
auto b = std::move(a);
std::cout << *a; // NULL pointer dereference!


[Martin Sivák]

Stačí, aby velké firmy angažovaly zkušené profesionály za odpovídající peníze. Vyřešilo by to i další problémy.

Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.

I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...

https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu

A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.

MISRA je dlouhodobě terčem různé kritiky, to není žádný argument. Jestli to dává, nebo nedává smysl, to nejlépe posoudím já sám.

To si klidně posuzujte. U Vašich vlastních projektů.

Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.

MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.

Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.

Teď zrovna mě nenapadá, k čemu bych to využil. Ale život mě za ta léta naučil, že umí nastolovat situace, jež nevymyslí ani ta nejbujnější fantazie. Víte, já si velmi dobře uvědomuji, jaké chyby to může způsobit, to mi tu nemusíte vykládat. Stejně jako si uvědomuji, co se může stát, když v autě přejedu dvojitou plnou čáru. V naprosté většině situací to činit nebudu. Ale dovedu si představit i situace, kdy bych to udělal, zatímco kdyby tam bylo svodidlo, tak mám situaci výrazně komplikovanější.

A proto právě máme unsafe, které to svodidlo odmontuje (v místech prokázané propasti teda nadává i tak) a dá tam jen dopravní značku. Velkou, oranžovou a s vykřičníkem.

Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.

Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).

Nebude. Pokud nepíšete vnitřnosti nějakého RTOS, tak se unsafe dá celkem pohodlně vyhnout ked sa clovek nesprava ako prasa.

Skor dufam, ze sa v embedet svete presadi Zig, na low-level veci, WASM a embedet ovela zuajimavejsia volba ako Rust alebo Go.

Zig se neprosadí, nemá prakticky žádnou komerční nebo komunitní podporu ani publicitu.

A to Go jste do té skupiny asi zařadil omylem.. ten jazyk má úplně jiné cíle a vlastnosti.

[Reklama]

[Jožka Niemand]

Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.

I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...

https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu

A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.

Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.

To si klidně posuzujte. U Vašich vlastních projektů.

Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.

MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.

Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.

Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.

Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.

Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.

[anonacct]

Dělám v C++ přes 20 let, mám toho za sebou hodně, a i teď se mi poraří udělat chybu, kterou odhalím až v testech, a kterou bych v Rustu nemohl udělat. Říkat, že něco nic nepřináší je prostě blbost - kdyby C++ mělo borrow checker, hned ho budu používat.

Podle mě mít safe kód v C++ není o zkušenostech, ale spíš o důkladném testování, a to je něco, na co hodně lidí zapomíná.

Nechci tím říct, že v rustu se nedají udělat chyby, ale spíš ty logické než nějaké safety chyby.

[nohous]

Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.

I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...

https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu

A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.

Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.

To si klidně posuzujte. U Vašich vlastních projektů.

Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.

MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.

Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.

Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.

Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.

Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.

S tebou bych chtel delat...

[kate]

S tebou bych chtel delat...

Jo, no. Říkám si že možná nepotkává kvalitní programátory, protože se mu raději obloukem vyhnou.

[Wavelet]

Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.

I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...

https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu

A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.

Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.

To si klidně posuzujte. U Vašich vlastních projektů.

Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.

MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.

Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.

Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.

Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.

Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.

> A zároveň má i odpovídající formální vzdělání.

Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.

Ten příklad se zubařem mne také pobavil protože:

Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:

"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."

Takže klidně zůstanu jako self-taught programmer

[Jožka Niemand]

Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.

Ten příklad se zubařem mne také pobavil protože:

Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:

"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."

Takže klidně zůstanu jako self-taught programmer

Jedno to rozhodně není. Stejně jako to není jedno v jiných oborech. Jako zubař-samouk si klidně vrtejte do vlastních zubů. Ale kdybyste si otevřel zubní ordinaci, asi by to bylo kvalifikováno jako pokus o ublížení na zdraví. Můj obor je průmysl a když vídám výtvory programátorů-samouků, dalo by se to často kvalifikovat úplně stejně.
Abych to upřesnil, dovedu si představit, že si doktor všeobecné medicíny udělá atestaci na zubaře, stejně jako že si matematik nebo elektrotechnik doplní relevantní znalosti z oboru vývoje SW. Ale elektrotechnikovi, který si po večerech na internetu prohlížel texty a videa o zubařině, načež si pořídil křeslo a vrtačku, bych svůj chrup rozhodně nesvěřil. Zprasený, za určitých okolností by se dalo říci i životu nebezpečný software od nedostudovaných samouků, už jsem bohužel potkal mnohokrát. Ne, že by neplatilo úsloví, že i mistr tesař se utne, ale u těch tesařů-samouků je to téměř jistota.

[r223]

Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.

[Wavelet]

Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.

Ten příklad se zubařem mne také pobavil protože:

Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:

"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."

Takže klidně zůstanu jako self-taught programmer

Jedno to rozhodně není. Stejně jako to není jedno v jiných oborech. Jako zubař-samouk si klidně vrtejte do vlastních zubů. Ale kdybyste si otevřel zubní ordinaci, asi by to bylo kvalifikováno jako pokus o ublížení na zdraví. Můj obor je průmysl a když vídám výtvory programátorů-samouků, dalo by se to často kvalifikovat úplně stejně.
Abych to upřesnil, dovedu si představit, že si doktor všeobecné medicíny udělá atestaci na zubaře, stejně jako že si matematik nebo elektrotechnik doplní relevantní znalosti z oboru vývoje SW. Ale elektrotechnikovi, který si po večerech na internetu prohlížel texty a videa o zubařině, načež si pořídil křeslo a vrtačku, bych svůj chrup rozhodně nesvěřil. Zprasený, za určitých okolností by se dalo říci i životu nebezpečný software od nedostudovaných samouků, už jsem bohužel potkal mnohokrát. Ne, že by neplatilo úsloví, že i mistr tesař se utne, ale u těch tesařů-samouků je to téměř jistota.

Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices.  Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo Univerzitu na to abys pohledal.

[nohous]

Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices.  Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo Univerzitu na to abys pohledal.

Pedantický konzervativní fachidiot je hrozně komický archetyp :-) Teda dokud ho můžeš jen na dálku pozorovat.

[Jožka Niemand]

Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.

To bude dost náročné testovat, protože tím si dovnitř zanesete obrovské množství kódu, o němž ani přesně nevíte, co dělá, z 90 % je to pro danou aplikaci nepotřebné a představuje to jen potenciální zdroj chyb a cest pro různé exploity. Je to zbytečný nárůst komplexity. Aplikací vyžadujících bezpečnost je spousta, pokud se člověk pohybuje třeba v tom průmyslu. A není-li to přímo bezpečnost, tak riziko finanční škody. Dost velkou motivací pro dodavatele SW do průmyslu by bylo, kdyby ve smlouvách standardně bylo ujednání, že když vinou chyby v SW dojde ke vzniku škod, tak to dodavatel komplet nahradí.

Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices.  Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo Univerzitu na to abys pohledal.

Zatím jsme se tu nijak odborně nebavili, jen tak obecně. Museli bychom se bavit o konkrétní věci. Žádnou vaši práci jsem neviděl, nejspíš jsem s vámi neměl tu čest v praxi se setkat. V čem píšete je celkem nicneříkající informace. Univerzitu na co? Pokud potřebujete univerzitu, aby vás tam naučili pracovat s vámi zmiňovanými jazyky, pak je něco špatně - to je přesně to, o čem jsem mluvil. Stačí znát obecné principy a postupy, které se více-méně od 60. let minulého století nemění. Snad všechno už tu od té doby v nějaké podobě bylo. S touto obecnou, vámi neuznávanou průpravou, zvládnete práci s nějakým konkrétním jazykem vcelku snadno. Pokud bychom oprášili ten zubařský příměr, tak je to jako práce s konkrétním materiálem nebo konkrétním nástrojem. Jenže ta podstata znalostí spočívá ve schopnosti posoudit vhodnost určitého materiálu, nástroje či postupu, umět správně diagnostikovat problém a v každém konkrétním případě umět stanovit vhodný další postup. Ne, protože jiný neznám, protože je s tím nejméně práce, nebo protože je to momentálně hype, ale protože je v daném případě optimální.
Opět z praxe - jestliže vás firma odbývá s tím, že na daném HW není možné určitou věc implementovat kvůli nedostatku paměti, a vy při nahlédnutí do programu zjistíte, že používají vnořená volání, místo aby to vyřešili pomocí stavového automatu, takže by stačila jedna stavová proměnná, jedno volání a hromada paměti by ještě zbyla, tak je asi něco špatně. Totéž jiný ekšpert - "nelze, pro daný úkol nedostatečný HW". Problém byl v tom, že místo aby kalibrační křivku implementoval pomocí interpolační tabulky a FXP aritmetiky, snažil se to realizovat přesně podle údajů z katalogu, tj. potřeboval FP knihovnu, aby mohl do programu prostě tupě opsat kalibrační vzorec. Nebo jiný "neřešitelný problém", tentokrát v assembleru - měřidlo dodává údaj ve formátu double, systém to potřebuje jako single... (btw - pomohlo by nějak dotyčným s řešením těchto problémů, kdyby používali Rust?)
A ne, řešením opravdu není použít silnější HW. Jednak to často nejde, průmyslový HW se nedá měnit jak ponožky, to jsou systémy, které mají spolehlivě a kontinuálně pracovat i desítky let a stojí to desítky, stovky milionů, a jednak neschopný vývojář vždycky dříve či později narazí na problém, na který mu daný HW nestačí, ale stačil by mu, kdyby nebyl neschopný.