@Mechan znam to, ale obawiam się, że pamięci i taktowania by mi brakło po kilku minutach pisania. Ostatnio próbowałem z wykorzystaniem HAL spróbkować sygnał 1.25MHz prockiem o taktowaniu 96MHz, z tym że filtrowanie musiało się odbywać w locie, bez filtrowania to banalne, ale z filtrem HAL poświęcił ponad połowę mojego cennego czasu na samo wejście w ISR, bo po drodze było kilkanaście warunków, a ja walczyłem z każdą operacją binarną, żeby zaoszczędzić
Czemu w ogóle ktoś chce się "pozbywać" narzędzia które przez tyle lat działało, jest sprawdzone, stabilne i ma community? W IT jest jakaś niezdrowa tendencja do łykania po same kule wszystkiego co nowe. I teraz autor pisze, że kompilator ma za niego wybierać najwydajniejszy algorytm sortowania na daną platformę. No właśnie nie. Gdy używasz C++ w 90% przypadków piszesz kod na z góry znaną architekturę. Jeśli nie znasz architektury na którą piszesz,
@Krolik: Doceniam próbę naganiania na Rusta, ale tak się składa że robię spory projekt embedded (tysiące zaangażowanych inżynierów) bardzo blisko tych wszystkich googli, microsoftów dzięki czemu mam dostęp do ich wewnętrznej komunikacji i nie widzę tam tego Rusta. Ja wiem że to jest dowód anegdotyczny, ale jakoś bardziej ufam swoim oczom i uszom niż randomowym artykułom z Internetu. Być może jest tak jak mówisz i ta część o której piszą jest
Tak, na szybko to autor mówi, że lokalna kompilacja z użyciem wszystkich natywnych funkcji procesora daje szybszy kod niż kompilacja, która ma być wykonana na jednej maszynie i działać na wielu innych.
Trudo się z tym nie zgodzić. Rzeczywiście jak piszesz oprogramowanie serwerowe to fakt, że przez lata cały stos był tworzony, aby rozprzestrzeniać binarki, bez kodu nie sprawdza się idealnie.
Jak nie martwisz się wyciekiem kodu, to rzeczywiście dostarczanie kodu, używanie
@Izanagi013: Nie, problemem z jit jest to, że zmienia ono zachowanie kodu więc mechanizmy bezpieczeństwa, które wykrywają niepokojące wzorce, przestają być skuteczne. Po prostu zachodzi obfuskacja.
A że JavaScript jest językiem funkcyjnym, a ludzie próbują pisać w nim jak w imperatywnie/obiektowo, to jest sporo miejsca na problemy.
Temat stary świat, który język lepszejszy, teraz idziemy poziom wyżej i retoryka wojenna, Język X zabił (zabija) język Y. I cały gówno artykuł o tym jak to było źle z tamtym, a teraz mamy świętego Graala z tym. Tylko tak naprawdę to nie ma znaczenia. Można do tego podejść inaczej nie iść za popularnością jakiego języka jak stado owiec za baranem, tylko iść w unikalność i niedostępność specjalistów w danej technologii. I
@nawacho: to ile można zarobić zależy bardziej od zastosowań (czyli biznesu) a nie technologii. W Clojure i Haskellu nie zarabia się wcale więcej niż w popularnej Javie.
No cóż, każdy język jest do innych zastosowań i tyle. C/C++ jeszcze długo nie umrze, bo pisze się w nim właśnie rzeczy niskopoziomowe - chociażby jądro systemu, albo programy pod mikrokontrolery (AVR, STM32, itd). W Javie, C# czy Pythonie tego nie napiszesz ¯\(ツ)/¯ No i pewnie dla C/C++ znajdzie się jeszcze wiele specyficznych zastosowań. No i chociażby - żeby działały programy napisane w wyżej wymienionych językach potrzeba interpretera lub maszyny wirtualne które
Komentarze (267)
najlepsze
@ZasilaczKomputerowy: Połowa podatności w oprogramowaniu to dziury spowodowane zarządzaniem pamięcią w C i C++.
i zostanie juz z nim do smierci
@przecietnyczlowiek: Interpreter pythona jest jednak napisany w C.
Trudo się z tym nie zgodzić. Rzeczywiście jak piszesz oprogramowanie serwerowe to fakt, że przez lata cały stos był tworzony, aby rozprzestrzeniać binarki, bez kodu nie sprawdza się idealnie.
Jak nie martwisz się wyciekiem kodu, to rzeczywiście dostarczanie kodu, używanie
A że JavaScript jest językiem funkcyjnym, a ludzie próbują pisać w nim jak w imperatywnie/obiektowo, to jest sporo miejsca na problemy.
@lukasj: które jądro systemu będącego w powszechnym użyciu napisano w C++?
Linux: C + Rust
Windows: C + Rust
Android: C + Rust
macOS: C
Ostatni system o którym słyszałem, że był w C++ to Symbian. Niestety z dech.
?