Pojem "real time" je příliš široký. Na jedné straně jsou to věci, kde je potřeba rozumná odezva k tomu, aby to fungovalo. Pokud odezva nebude dobrá, ztratí se spojení apod. Na opačné straně jsou věci, kde je nezbytně nutné aby došlo ke zpracování události v definovaném časovém limitu. Pokud se to nestihne, tak někdo umře nebo dojde ke škodě na majetku.
Příkladem toho prvního jsou routery, mobily, zabezpečovací technika apod. Je to "taky realtime", ale nejde o život. Tam se klidně použije i JVM. A běžně se i používá.
Příkladem toho druhého je autopilot, senzory v letadle, řídící jednotka CNC stroje. To je "opravdový realtime", tam jde o život - autopilot nedokáže reagovat včas a místo stabilizace letadla ho rozhoupe; zpoždění mezi jednotlivými senzory může dát chybný údaj o stavu letadla; pokud řídící jednotka CNC stroje nedokáže včas poslat příkaz krokovému motoru, pak setrvačnost může motor "protočit" a třebas posunout nástroj "do materiálu", což takovou frézu poměrně často urazí a ta se proletí vzduchem. V případě strojů se servem je to ještě větší legrace, tam to umí švihnout portálem tak, že je stroj na odpis. Sem se hodí spíše C nebo assembler. Viděl jsem i interpretované jazyky, ale vždy to bylo imperativní. U těhle systémů je jedním ze stěžejních prvků "accountability". Dokážete zjistit, kolik času zabere provedení každé z operací. Interpretery v tomhle nekladou žádné překážky (pokud samotný interpreter je "accountable", pak ani jím interpretovaný program nemusí mít problém), ale kupříkladu použití OOP už problém byl. Ono některé vlastnosti OOP jdou přímo proti "accountability" (polymorfismus je prostě konečná). Když nedokážete říci, kolik maximálně času, bez ohledu na situaci, uplyne od přijetí signálu A do reakce B, tak vás s tím do letadla nepustí.
Ve chvíli, kdy víte, jestli chcete dělat "taky real time" nebo "opravdový real time", si musíte položit další otázku - jak to má být rychlé? Většina real time systémů kupodivu nevyžaduje nijak zvlášť rychlou reakci (nezaměňovat rychle a včas) nebo náročný výpočet. Tady více než kde jinde platí KISS. Proto se běžně využívají vyšší programovací jazyky. Pro RT úlohy zde jsou speciálně překladače (nebo přepínače v překladačích), které nejen že generují "RT friendly" kód, ale i umí spočítat výslednou reakční dobu. Jen za tím "vyšší programovací jazyky" nehledejte OOP nebo komplikované funkcionální programy plné closures. U "taky real time" se dnes často hraje na "když to dělám obvykle hodně rychle, tak to obvykle taky dělám včas", takže tam se používá vše co znáte a jen se nějak ošetří "chronicky známé neznámé" typu garbage collector. Pak se to jen spustí s profilerem a pro iterace, kdy "to nestihl" se hledá příčina a ta se řeší. Jakmile spadne procento iterací, kdy "to nestihl" pod nějakou mez, tak se to prohlásí za hotové.