Melyik programozasi nyelv valo nekem?

Egyszeru kerdessel megvalaszolhato:

Tudnal C-ben par ora alatt gyorsabbat irni, mint a C++ std::unordered_map implementacioja?

A) Igen --> Neked a C valo

B) Nem, de ez eleg jo --> Neked a C++ valo

C) Nem, de nem ertem miert feltetlen baj az, ha ez nem ennyire gyors --> Neked a Python valo

D) Nem, igazabol nem is ertem mi ez meg mire jo --> Neked a JavaScript valo

A tobbi nyelvre meg igazabol mar semmi szukseg nincs. :)

( csortu v | 2022. 10. 05., sze – 14:01 )

E) Mutass statisztikát, hogy az egyik szignifikánsan gyorsabb -> Neked az R való

Csaba

( asch v | 2022. 10. 05., sze – 16:54 )

Szerkesztve: 2022. 10. 05., sze – 16:55

locsemege: Tudok, de inkább ASM-ben állok neki, mert úgy még ki tudok sajtolni néhány órajelet itt-ott.

Azok az idok mar elmultak. Emlekszem ra, hogy sorrenddel meg mas "hacking" alkalmazassal sikerult gyorsitani 10% ot, meg belement ugy 3 embernap. Nem eri meg a resource olcsobb. Vicces ezért igaz.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Nyilvan terulet- meg problemafuggo, de azert van egy olyan resz ahol meg mindig egeszen jol teljesit a nyers assembly C-hez kepest. Konkretan specialisabb bitmuveleteknel, ahol a bitshifteket feltetelekhez kotod es/vagy feltetelek mulnak rajta (ami mint terulet, elegge atfed a veges test aritmetikaval, hash fuggvenyekkel, crc-szamitassal, titkositassal, stb is). Sajat pelda, par hettel ezelottrol:

[...] uint32_t b; [...]
for ( ... )
 {      [...]
        if ( b&0x80000000 )
                        b=(b<<1)^PRIMITIVE_POLYNOMIAL;
        else
                        b=(b<<1);
 }

Ez a ciklusmag-elem ARM/thumb1 alatt egy sima "left shift" + "branch if not carry" + "xor" sorra fordithato. Eredmeny: 150%-kal gyorsabb mint a C altal generalt barmi ;) Persze a fenti bitmuvelet-trukkokon felul meg van egy kis makrositott unrolling, az ABI eroteljes kihasznalasa, naked + noinline attributumok, stb, de az marcsak a hab a tortan. Szoval barhogyis, nehanapjan lehet olyan feladat a mai napig, ami csak perc gondolkodas, cserebe rohadt nagy nyereseg. 

De egyebkent teljesen jogos amit mondasz, altalanos esetben baromi kicsi a varhato erteke a nyeresegnek. Nalam is a custom _start entry pointokat meg ilyen lowlevel dolgokat leszamitva 5-6 ev ota ez az elso eles assembly betetem amit C-kodba tettem...

( Nyosigomboc v | 2022. 10. 05., sze – 18:06 )

Volt olyan project, amihez C-t kellett hasznalnom, pedig orultem volna a C++ extra feature-einek (LinuxCNC modul). Van, hogy meg van adva, hogy mit hasznalhatsz esszeruen az adott kornyezetben. Amugy STL-hez hasonlo funkcio pont nem kellett.

C es C++ kozt inkabb ott lehet kulonbseg, hogy egyreszt hasznalhatsz-e C++-t, ill. ha libet irsz, akkor C-t mashoz konnyebb kapcsolni, emiatt erdemes megfontolni azt (polimorfizmus miatti plusz dolgok a nevben).

Ha a fejlesztesi ido fontosabb a futasinal, akkor Python.

JS meg bongeszohoz, kliensoldalra. Kevesbe eltalalt nyelv szerintem, mint az elozoek, de a webasm valoszinuleg tobb szivast hozna.

A strange game. The only winning move is not to play. How about a nice game of chess?

( uid_6201 v | 2022. 10. 05., sze – 18:26 )

Hát, lehet onnan is kezdeni, hogy legyártom az alapkomponenseket. Végül a 14. perctől szól vele a rádióvevő, szívmelengető: https://www.youtube.com/watch?v=EzyXMEpq4qw
De onnan is lehet kezdeni, hogy veszek ehhez standard IC-ket, netán egyéb egychipes cél IC-t és abból gyorsabban összerakok egy sokkal jobb paraméterű eszközt.

Ami viszont fontosabb, hogy mi a megvalósítandó feladat és milyen egyéb feltételek befolyásolnak?
Kalapács vagy villáskulcs célszerűbb hozzá? Bár az utóbbival az anya meghúzásán túl lehet püfölni is, de az előző arra mégis praktikusabb a püfölésre.
De kalapáccsal ne akarj anyát meghúzni. Viszont a villáskulcs+kalapács együtt igen hatékony lehet a berohadt anya leküzdésére.

Programozási nyelvet is jó esetben a feladathoz választunk. Viszont a feladaton kívül sok egyéb tényező is befolyásolja a döntést.
Egy ilyen példa, hogy ha nekem azt mondod, hogy itt egy néhány millió soros TXT fájl (mérési adatok), amit értékeljek ki a prezentációhoz, akkor Python, mert az összedobás+eredményhez jutás együttese itt a leggazdaságosabb. Ha pedig egy nagy terhelhetőségű reverz proxy a cél valami hálózati szolgáltatás elé, akkor meg Rust, mert gyors és biztonságos.

Miben irnal SQL servert mindegyik isolacios szint tamogatasaval, ha teljesitmeny ill HA clusterezhetoseg szamit ?

Masik kerdes, mi az aktualis tanacs mondjuk RCU hasznalatra rust -ban ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Először azon gondolkodnék el, hogy milyen olyan funkciót tudnék tenni bele, amitől jobb lenne mint a többi?

Például SQL helyett egy bináris protokollt csinálnék, amivel az SQL mögötti matematikai kifejezéseket lehet leírni, és csak efölött lenne egy réteg az SQL, de azt nem az adatbázis kezelné, hanem a kliens oldali lib. Ez tetszene, bár nem vagyok biztos benne, hogy van értelme.

Aztán úgy csinálnám, hogy az értelmező meg a végrehajtás-tervező az magas szintű nyelv lenne talán a Java magasságában, de maga az engine ami végrehajtja, az meg lehet, hogy C lenne úgy optimalizálva, hogy lehetőleg még dinamikus memória foglalás is minimális legyen. Legalábbis nem bizgentyűnkként, hanem a tervnek megfelelően előre foglalna. Szóval hogy gyors legyen, értitek.

Aztán a háttértár műveleteket egyből az új Linux API-val valósítanám meg, amiről itt nemrég szó volt. Ezzel talán lehetne javítani a sávszélességen a régi API-kra épülő meglévő engine-ekhez képest.

Valami ilyesmit csinálnék. Szerintem C-Java hibrid lenne. A Javát úgy csinálnám meg, hogy fusson .NET VM alatt is, hogy tudjanak versengeni a kegyeimért.

java .net -> gc pause

Raw muveletek, mint felhuzas oszefesules kozel elfogadhatoan megy a mostani adatbazisokon.
Ill van tarol eljaras is.
De a tarolt eljaras, kb python sebessegu mysql/mariadb esetben, illetve a query-ben szereplo kifejezesek is python sebessegu.
Van native tarolt eljaras is, de ezt nem szeretik adminolni, libeket toltni a DB mele, ez gyors.

eBPF ? Nem pont , de valami ami elobb utobb native kod lesz es gc pause miatt sem kell tartani, ill nem limitalt tulsagosan memoria foglalsi megszoritasokkal.

mysql protokol nem tulsagosan barati a modernebb I/O strategiakkal, ill vannak olyan adat tipusok amit kuldo/fogado oldalon koltseges eloalitani parsolni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Amint nepek olyan cikket olvasnak , hogy google atirt nehany alkalmazst go -rol rust -ra,
abbol nepszeruseg novekedes lesz.

rust nem gatolja meg hogy a teljesitmeny erzekeny reszek asm -ben vagy C -ben legyenek.
Vevo meg ha azt olvassa hogy rust -ban van termek azt gondolja biztonsagosabb, ez eleg hogy piaci elonyre tegyel szert amig hype train robog.

C++, java, C#  , pascal, D, ada ..
A fo ok hogy ezekeben kezdjen uj projectet rust helyett valaki, hogy azt hasznalta tegnap is.

rust crate rendszere olyan ami C -hez nem igazan van, de majdnem minden mas elterjedt dologhoz mar van.

python super lassu, go nagyabol azert van mert feladtak hogy valaha is olyan toolt csinalnak amivel
a python codok ertelmes sebbessegel menjenek fura problemak nelkul.
rust velhetoleg jobb eredemnyt eredmenyez ott ahol most go van.

pythonban lehet gyorsnak tunik elkezdeni valamit, de hosszu tavon legtobbszor siras a vege.
Egy C forito is megfog olyan hibakat, ami pythonban futas ideju lesz.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

pythonban lehet gyorsnak tunik elkezdeni valamit, de hosszu tavon legtobbszor siras a vege.

Azért nehéz az ilyen kijelentéseket komolyan venni. :) Valamire jó, valamire nem.

Egy C forito is megfog olyan hibakat, ami pythonban futas ideju lesz.

Static analysis azért van Pythonhoz is, ennyire nem rossz a helyzet.

"Azért nehéz az ilyen kijelentéseket komolyan venni. :) Valamire jó, valamire nem."

troll mode ;-)
Valamire tenyleg jo, de valjuk be tobb helyen van mint ahol kene.

"Static analysis azért van Pythonhoz is, ennyire nem rossz a helyzet."
Shell script-tol jobb a helyzet, invalid syntax prod elott megvan.

"module"

def food(bbb):
    "Add 23 to arg"
    return bbb.add(23)

AAAA = 42
food(AAAA)

 

Ez atment flake8 en es pylint -en.
pylint elkapta methodues nelkul, flake8 nem.

/tmp/f.py:1:0: C0104: Disallowed name "foo" (disallowed-name)
;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez a PyCharm sajátja, más lintert rá sem engedtem már. Lehet, hogy máshol továbbengedi.

abc nem lehet (amíg nincs definiálva, nyilván), mert Unresolved reference 'abc'. Ráadásul ha abc a hint, akkor a food(AAAA) sorra fogja azt mondani, hogy Type 'int' doesn't have expected attribute 'add', mivel az AAAA-nak amikor értéket adtál, akkor type hinting nélkül is rájön, hogy az egy int.

Nézd, amiről te írsz, az a kategória, hogy "hírverést csinál magának, és végtelen ideje bütyköli a saját out-of-tree branchét, ami a kutyát se érdekel igazából".

Ez viszont már nem az.

Sok ember, pl Linus is kifejezetten látja a nyelvben levő pluszt a C-hez képest. Amennyire kategorikusan elutasítóak a C++-al szemben a kernelben, annyira meglepően villámgyorsan felszálltak sokan a Rust vonatra, mert mérnökileg jobb, mint a C: tömörebb, biztonságosabb kód írható vele.