Majd belejön.
Nem, nem majd belejön, hanem több gázt fog használni, mint a több szakács. Ahogy a hibás CPU-k is több energiát fognak használni a hiba kijavítása után, mint előtte. Nem lesz olyan megoldás, hogy a gyors marad és ezzel egy időben megoldódik a biztonsági hiba is. Valamit-valamiért. Ha kihagyod az ellenőrzéseket, akkor gyors. Ha beleteszed az ellenőrzéseket, akkor lassabb lesz. Csodák nincsenek, csak a kis világodban.
De lehet. Sőt én azzal is bőven elégedett lennék a 30% lassulás mellett, ha ezentúl a szoftvereket 60%-kal gyorsabbra írnák, elhagyva a bloated framework-öket és a szoftverfejlesztői kényelmeskedést.
A szoftvereket gyorsabbra írják... csak még mindig abban a bűvkörben élsz, hogy egy gonosz lobbi lassú programokat ír direkt, nincsenek bloated framework-ök, csak a fejedben, egyszerűen növekszik az a problématér, amit le kell fedni, ahhoz pedig nagyobb teljesítmény kell. A CGA monitoron is lehetett dolgozni, ahhoz kellett 16 kB memória és a 25 Hz frissítéshez kellett 400 ezer memória olvasás másodpercenként. Most 1920x1080 32 bites felbontáshoz kell 7,9 MB memória és a 60 Hz frissítéshez (hogy ne rongálja az ember szemét) kell 474 millió memória olvasás és ez csak a megjelenítés. Mondhatod, hogy mindenki dolgozzon CGA monitoron, mert ha 30 éve lehetett, akkor most is lehet, de nem fog senki CGA monitoron dolgozni, aki egy kicsit is törődik az egészségével. Ez van.
Arról beszéltem, hogy a Java-ban írt desktop alkalmazások ugyanazokra a feladatokra memóriából és CPU-ból is többet zabálnak.
Beszélni bárki tud, én is tudom mondani, hogy szerintem a Java jobb. Mi lesz erre az első kérdésed? Az, hogy bizonyítsam be. Szóval ne csak beszélj, bizonyíts.