Russinovich: Itt az ideje az új projektekhez C/C++ helyett Rust-ot használni ...

Programozás

... ahol nincs szükség Garbage Collector-os programozási nyelvre. A biztonság és megbízhatóság érdekében ezeket a nyelveket az iparágnak "deprecated"-nek kellene deklarálnia.

Egyetértek!
30% (188 szavazat)
Nem értek egyet!
42% (264 szavazat)
😲
27% (170 szavazat)
Összes szavazat: 622

( STP | 2022. 09. 28., sze – 14:58 )

Akkor a jövőben a MS-nál a (C) a C/C++-t, az (R) meg  a Rust-ot fogja jelenteni?

( Mondjuk a TM-mel q-ra vigyázniuk kell... :D )

Szerintem meg pont a MS miatt nem jön el a rustos forradalom. Tegyük fel, hogy tényleg jobb, mint a C/C++ (ezt vitatom, de legyen). A MS akkor is meg fogja vétózni, mert nyílt szabvány, opensource megoldás, a MS utálja ezeket, ők azt szeretik, ha minden a saját házuk táján van feltalálva (akkor is, ha a kereket kell újra feltalálni, lásd C#), és zárt kódos, lehetőleg fizetős megoldás, aminek minden ki van szolgáltatva. Így ha ők esetleg el is mennek Rusthoz hasonló irányba, valami saját megoldást fognak helyette erőltetni, ezt garantálom, már csak azért is.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Már megint teljesen fogalmatlan vagy.

Lásd: .NET, open-source, WinUI open source.

Az MS támogatja is a Rusttal való fejlesztést: https://learn.microsoft.com/en-us/windows/dev-environment/rust/overview

https://cloudblogs.microsoft.com/opensource/2021/02/08/microsoft-joins-…

https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-s…

 

Tényleg nem értem, hogy miért szólsz bele olyan dolgokba, amiről tényleg semmi fogalmad sincs.

Igen, tudom, hogy a .NET opensource, de mikor is lett az? Hány év kellett hozzá? Az opensource meg a MS említése egy szinten egy vicc. PR-ból megnyitnak kisebb kódokat, ezt-azt, épp, ami érdekükben áll, de ők az a cég, amik mindig is a zárt kódról fognak szólni. Ha meg az kimegy a divatból, lehúzzák a rolót.

Azzal is tisztában vagyok, hogy támogatott a Rust a MS-nál. Inkább arra céloztam, hogy ha nagyon beindulna a Rust szekere, tényleg annyira mindenki rákapna, akkor pont a MS lenne az első, aki tenne ellene valamit. Mert a Google, Oracle, Facebook még csak oké szokott lenni a FOSS-sal, mert rájöttek, hogy egy csomó jó ingyen technológia, ami helyett nem kell mindenből teljesen sajátot írni, de az Apple meg a MS mindig is teljesen más hozzáállású volt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Melyik cég nem zárt kódokból termeli a pénzét? Az Apple, a Google, a Facebook, a Microsoft, Oracle mind-mind zárt kódokból él, abból van a pénzük mind. Hatalmas tévedésben vag, hogy "Google, Oracle, Facebook még csak oké szokott lenni a FOSS-sal".

Tudsz olyan Google terméket mondani, ami nyílt forrású és abból keresi a pénzét a Google?  A Search nem nyílt. Az Adwords nem nyílt. A Mail nem nyílt. A Docs nem nyílt. A Cloud Platform nem nyílt.

Ugyanezt Apple-re, Facebookra, Oraclere is megkérdezheted magadtól.

A megnyitott kódok minden esetben érdekről szólnak, érdemes elolvasnod ezt: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

https://www.gwern.net/Complement

Ekkor majd megérted, hogy melyik cég mit és miért tesz nyílt forrásúvá.

Az Apple esetén is érdekes látni ezt, maga az OS kernel és az alaprendszer nyílt forráskódú: https://opensource.apple.com/releases/

Hasonlóan, ők irányítják a CUPS és Webkit fejlesztését is, két nyílt eszköz, amit a fél világ használ. 

Definíció kérdése. Technikailag pl. Golang hiszen a „zárt kód” jelentős részét ebben írják, tehát egy csomó „pénzkeresési részben” ott lesz.

Különösen egy programozási nyelvről szóló postban ez azért számít, oderwas?

… most people don't plan to fail - they fail to plan
---
* Origin: LifeForce WHQ (2:370/15)

Egyébként meg annyit, hogy tisztában vagyok azzal is, hogy a MS-nál is vannak jó szakemberek. Pl. ezt a Russinovichot is régóta követem, mert már 20 éve is nagyon jó és hasznos toolokat tett közzé, meg az a Dave's Garage-os kanadai fószer is nagyon szimpatikus, meg a System Crafters YouTube-csatornán is van egy MS-os fószer, aki a görög MS-nál valami vezető, az is egy ultra geek faszi, nagyon kemény feketemágiát tol GNU Guix + Emacs + exwm alatt, vim userként csak nézek szájtátva, hogy miket tud. Az a baj, hogy a MS-nál nem az ilyen szakemberek határozzák meg a trendeket, hanem öltönyös-nyakkendős idióták, meg a mostani félkegyelmű indiai vezér, addig meg érdemi hozzáállás nem fog változni és modernizálódni a cégnél.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Szerintem inkább az a baj - ha jól értem - hogy, szerinte az opensource az minőségi fogalom + az opensource magasabb rendű. Pedig nem.

Sőt még azt sem hinném, hogy az opensource mostanában teret nyerne, tekintve hogy mobilon fejlesztésben sehol nem látom megemlítve. De ez legyen az ő baja.

C nek is es C++ nak is teljesen nyilt szabvanya van, amit egy fuggetlen testulet hataroz meg, ami folott Microsoft-nak nincs iranyitasa (vannak benne emberei de az egesz testuletet nem kontrollaljak). Szoval ezen logika szerint a Microsoft a C-t es a C++-t is vetoznia kene. Ezzel szemben ezeket a nyelveket hasznaljak a Windows kernelben es meg sok mas helyen a sajat termekeikben.

:wq

A teljesen nyílt szabvány nagyon erős kifejezés. Ingyen hozzá sem lehet férni ehhez a nyílt szabványhoz.

Az oké, hogy nincs védve szabadalmakkal és bárki implementálhatja, nem fogja senki perelni (nem úgy, mint az Oracle vs Google per).

Az EU szerint amúgy nem nyílt szabvány a C:

"It mustbe permissible to all to copy, distribute and use it for no fee or at a nominal fee."

Au ISO szabványt nem oszthatod tovább.

A K&R sosem volt egy szabványban dokumentálva. Volt ugyan a könyv, de nem tért ki mindenre. Nem volt szabványos leírása, legfeljebb az általuk írt compiler volt használható de facto szabványnak való megfelelésre.

Az ANSI C esetén az ANSI oldalán már meg sem lehet venni a szabványt: https://webstore.ansi.org/Search/Find?in=1&st=progamming

Amúgy az ANSI X3.159-1989 az technikailag ugyanaz, mint az ISO/IEC 9899:1990, ugyanaz vonatkozik rá.

c# nagyon-nagyon jó minőségű (több évet dolgoztam benne, bár c++ a fő profilom).

saját tapasztalat szerint életszerű problémáknál csak kb 30%-kal lassabb kódot lehet benne írni, de 3x olyan gyorsan, és sokkal kevesebb hibával mint c++ -ban.

Ez bizony nemhogy nevetséges, de nagyon is komoly alternatívává teszi. 

Teljesítmény optimalizálásokat is folyton csinálnak rajta, szépen fejlődik.

Én is sokat dolgoztam C#-pal, ráadásul nekem ez volt az elsődleges választás.

Szerintem is jó minőségű, szerintem is relatíve gyors kódot lehet írni benne, és a folyamatos fejlesztéseket is elismerem.

Ettől még nem tartom megfelelő C-alternatívának. Értsd jól: a "C-vel jól megoldható problémák" és a "C#-pal jól megoldható problémák" halmazok metszete ha nem is nulla, de elég kicsi. :)

Tudom, hogy az én bűnöm, de nem tudtam, hogy van .net Linuxra. Megnéztem a Microsoft honlapján, és tényleg van. Hm, meg vagyok lepődve. Annyiban felizgatott a dolog, hogy van C#-ban írt céges software, amelyet néha jó volna Linuxon használni, de félek tőle, ez nem ilyen egyszerű, mert akkor a kódot is úgy kell írni. Gondolom, ha van egy C:\valami elérési út a kódban, azzal még továbbra sem tud majd mit kezdeni a Linux.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ráadásul amiről beszélek, az egy belső használatra írt software, nincs igényesen kivitelezve, bármikor tudok neki olyan adatot küldeni, hogy eception lesz belőle. Ténylegesen be vannak drótozva elérési utak, nem környezeti változóból, config file-ból, oprendszertől van kérdezve. Nem azért, mert a kollégák nem tudnak programozni, hanem nem éri meg több energiát beleölni, nem kerül kapun kívülre.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

en is lattam olyan java-s cuccot ami a belehardkodolt \ path elvalaszto miatt nem futott windozon kivul mason, pedig amugy futott volna. hexeditorral atirkalva megoldhato volt (forraskodom nem volt hozza) de azert ez igy wtf.

a .net azert nem ilyen egyszeru, eleinte sok evig tenyleg win only volt, aztan jott a mono ami igazabol egy win emulacio volt linuxra, majd par eve az MS ugy dontott multiplatformma teszi a c#-ot, es kiadtak a .net core-t linuxra es macos-re. ahogy a neve (core) is mutatja ez csak egy nagyon limitalt szuk resze az egesznek, a frameworkok nagy resze (pl. gui) nem hasznalhato benne, anelkul meg igazabol nem sok mindenre jo... talan webcucc backendje megirhato benne, db (meg mssql is van am linuxra!) kezeles talan jol mukodik meg a halozati dolgok is.  de azert azt ne felejtsuk hogy a .net eredetileg elegge a windoz szemleletmodjat es api-jait kovette es hasznalta, ezt mind kihagytak a core-bol igy viszont nem sok minden maradt :)

En csinaltam 15 eve, egy avr32 volt a soros port masik oldalan,
csak arra voltam kivancsi hogy per regiszter billengetes mit csinal, es gondoltam kozbe kiprobalom azt C# izet ;-)

Lehet hallozat volt nem soros, nem emlekszem. xml -be kimentni is lehttett megjegyzeseket.

Akkor kellemes volt hasznalni, voltak dynmikus elemek is guiban es pik/pak megvolt.
Meglepoen kevesett kellet irni,  C -hez kepest, ugy hogy meg GUI -editor is kerulve volt, mert a legtobb elem
attol fuggot mi kerult az xml -be melyik bit halmaz mit csinal. (https://www.mono-project.com/docs/gui/gtksharp/)

Ugy latom haldokolnak qt/gtk C# bindigek ;-( , pedig jo volt.

https://github.com/GtkSharp/GtkSharp/issues/166

https://gitlab.com/ddobrev/QtSharp 3 eve nem valtozott.

https://github.com/gircore/gir.core talan atveszi a szerepet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mondjuk én még Winforms-projektben sem írtam egy sor kódot sem (hál' Istennek :))

Érdekes kérdés ez egyébként. Én csak 10-11 éve kaptam először (közvetlenül) pénzt programozásért, és már akkoriban is próbált mindenki a környezetemben elmozdulni a Winforms, GTK, stb. vastagkliensektől. Nyilván van olyan use case, ahol ez nem opció. Ha így nézzük, boldogan el lehet fejlesztgetni C#-ban Winforms&co. nélkül is, életed végéig lenne elég meló így is. :)

Na jó, de te most onnan nézed a dolgot, hogy kapsz random feladatot, elvégzed, pénzt kapsz érte, azaz lesz elég meló vékonykliensen is. Én fordítva szemlélem ezt. Adva van a feladat, s kérdés, azt hogyan oldhatom meg. Nyilván lehet böngészőbe GUI-t írni, a szerver meg fizikailag piszkálja a műszer hardware-ét, de ez elég nagy munka így, lehet, jobb erre egy vastagkliens megoldás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor rád ez vonatkozott: Nyilván van olyan use case, ahol ez nem opció. :)

Egyébként a szerver-kliens architektúra nem alapvetés, láttam már gyártásban olyan GUI-t, ami egy egyszerű böngésző volt, benne a localhost:8080 weboldal, a gép túloldalán pedig a műszer soktonnás gépek gyártották a nem mondom meg, mit. Ennek az volt a hozzáadott értéke, hogy egy épülettel arrébb működött a http://big-fucking-machine:8080 oldal is, csak read-only, reporting módban.

Lehet opció, meg lehet csinálni, csak ha újratervezzük az életet, az nagyon sok munka. Amúgy alacsonyszinten is van ám ilyen. Van egy mára elavult, nem a mai igényekre tervezett saját script nyelvünk, de cipeljük a koloncot, mert szögelni, szigszalagozni a régit még mindig kisebb munka, mint elölről megcsinálni szépen azt, amit már kinőttünk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem látom hogy mivel nagyobb munka, mint nem így csinálni. A műszer és a szerver között úgyis van egy protokoll, így meg le tudod választani, távolról is el tudod érni, ha egy normális API-t csinálsz, akkor még a kliens is cserélhető. Ja, hogy te assembly-ben írnál szervert? No, úgy tényleg nagy munka.

beágyazott-közeli adatgyűjtő / kiértékelő / kompresszáló / saját weboldalról szűrést és konfigurálást engedő kütyü szoftverét csináltunk .net-el Linuxra néhány hónap alatt, kérlek, mondd el, hogyan sikerült mégis :D

a valóság: nagyon jó multiplatform támogatása van.

Ne engedd, hogy elmenjen melletted a világ, és dogmák irányítsák a döntéseidet.
Konkrétabban: ahol csak lehet, pl beágyazott rendszernél is nézd meg, mennyivel egyszerűbb lesz a dolgod c++-szal (esetleg Rust-tal).

A kérdés az volt: tud-e ketyegni a gyártósoron a kütyü 3 hónap múlva, úgyhogy a főnök lássa a pillanatnyi állapotot böngészővel a mobiljáról?
Ez C-vel esélytelen lett volna, bukott volna az üzlet, mire kész lett volna, már elavul a hardver

Még egyszer mondom, a mi területünkön c#ban tipikusan csak kb 30%kal lassabb a kód, mintha full natívban lenne megírva.

> 30%kal lassabb a kód, mintha full natívban lenne megírva.

Párszor már leírtam itt, és most is tartom hogy a _legtöbb esetben_ ha egy program 10x 100x, sőt gyakran ha 1000x lassabb mint lehetne, de nincsen benne rossz skálázódás, akkor az nem csak hogy elfogadható de jónak mondható megoldás is. A 30% nem oszt nem szoroz, ha meg mégis akkor natív libbe kell tenni.

(És fordítva is, ha a program rendkívül optimális részleteiben de csak egy rossz skálázódás is van benne akkor meg fabatkát sem ér amint az input skálázódása megtörténik.)

Az attól függ. Beágyazott procis cuccoknál van olyan szempont is, hogy
  - adott a vas, már le van gyártva a spéci perifériákkal rendelkező célhardver (akár egy előző projekt kapcsán).
  - adott az aktuális feladat
  - szoftvertempó és szoftverméret az egyetlen változó, amivel az előző kettő feltételbe kell illeszkedned.
Persze van olyan is, hogy "lehetetlen", akkor a feladaton is faragtatni kell VAGY közös erővel meggyőzni a vezetést egy újabb, korszerűbb hardverre való újratervezésről, ami nem kis költségnövekedést okoz.

Véleményem szerint ahol a másfeles lassulásszorzó már problémát okoz, akkor ott valami okból igencsak alul lett méretezve a hardver. Ez azért gáz, mert egy eredetileg nem tervezett pluszfunkció, netán erőforrásigényben 20..30%-kal félrekalkulált funkció esetére sincs optimalizálási (spórolási) mozgástered. Egyszer egy ilyenbe csúnyán belefutottam én is, a célhardver skálázásra ott sem volt lehetőség és a szoftverből sem lehetett kipaszírozni már több megspórolást.
A legsarkalatosabb, amivel találkoztam egy svájci cég kapcsán történt, ahol kiemelt szempont volt a mikrovezérlőn is néhány cent megtakarítása, mert olcsó lakossági kütyü milliós példányszámban gyártandó szériájáról volt szó. Itt volt az, hogy a programban utólag byte-okat kellett megtakarítani, hogy beleférjen a legutolsó funkció is a flash-be. Egyébként éppen a flash méret az, ami nem szokott szűk keresztmetszet lenni. RAM mennyisége és a CPU számítási teljesítménye a gyakrabb korlát.

Szóval nem fekete-fehér a téma. Másik véglet, a felhős környezet, ahol megszokott, hogy sebaj, indítunk egy újabb példányt. Áramkörbe beágyazott CPU-knál ez nem járható. Az egy másik kérdés, hogy felhős megoldásoknál is érdemes (lenne) a kifejlesztett szoftver által biztosított szolgáltatás várható futamidejére egy TCO becslést csinálni és megvizsgálni, hogy nem érné-e meg több szoftverfejlesztés és kevesebb X évre fizetett futásidejű költség.

+1

Pontosan arról beszélsz, amivel napi szinten találkozom! Nálunk volt olyan, hogy költségcsökkentés és a chiphiány problémái miatt szándékosan alul lett méretezve, de csak egy futásidőben kritikus rész van, a DMA IT rutin, a többi kódrész ráérős, flash is van rogyásig, RAM már nem olyan sok, de azért nem cipőkanalas az sem. Szóval lehet funkciót bővíteni, a DMA IT rutin meg jól tesztelt, a funkcionalitása elegendő, ha változik, akkor is minimálisan. Nagyon kevés tartalék abban is van, de ott minden nanosec számít.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, ilyen is van, ez éppen a spektrum másik vége. Leginkább a desktop problémákra igaz amit én írtam.

Például vegyük a népszámlálást: van mondjuk 5 millió háztartás, ennyi bevallást kell feldolgozni. Egy bevallás kb 1kB információ, ha értelmesen tárolnánk nem volna több, és még akár tömöríthetnénk is, de nem is kell. Minden user rányom mondjuk 10-szer a mentésre és minden változatot is tárolunk. Akkor mennyi adatnál járunk? 10 x 5m x 1kB = 50GB. Tehát 50GB adatról beszélünk, ezt kell feldolgozni két hét alatt. Oké, az elején meg a végén roham van, amikor kicsit nagyobb lehet a sávszélesség az átlagosnál.

Mondjuk a vállalkozó azt mondja, hogy neki kell 5TB tárhely ahhoz, hogy megoldja a feladatot. Szerinted ha ennyivel valóban megoldja és fennakadásmentes a rendszer, az sikernek számít? Szerintem igen, sőt azt mondanám rá, hogy első osztályú kivitelezés. De meg lehetne oldani 50GB-ban is? Igen, meg lehetne. Puff, ott a 100-as szorzó és mégis jó az elképzelt megoldás.

Így értem ezt, hogy a legtöbb esetben simán belefér egy 10-100-as _lineáris_ szorzó.

Persze, de a 10000 elemet ha listázod, akkor abból valójában max 100-at kell listázni, mert több nem fér a képernyőre. Optimálisan pedig ez mondjuk volna 100mikroszekundum és akkor a 100-as szorzóval lesz 10ms ami semmi (gémerek talán látják), 1000-essel 100ms ami irodai usernek semmi.

Nyilván ha már user szinten mérhető a lassulás, akkor már nem igaz az alap felvetésem. Az alap felvetésem arra vonatkozott, hogy a legtöbb probléma esetén a gép annyival gyorsabb az igényeknél, hogy belefér akár egy ezerszeres szorzó is. Persze vannak kivételek ezen szabály alól.

Az user nem tudhatja az ID-ket minden estben, ugyhogy parhuzamisitas nem megoldhato szamara.

Az user lehet-hogy egy scipt -et futat , nem csak GUI meg web van.

Ill egy gameben siman lehat 10000+ objektum egy jelenetben ;-)

Human altlban toleral 16ms kesest, azokban az esetkenben ahol ez alatt vagy, valoban van olyan hogy 1000 lassabb dolog is ez alatt van.
Eleg elszomorito latni hogy 1000 erosebb CPU mire van hasznalva valojaban.
Kb 10000 nagysagrandnyi kulombseg van leggagyib es legerosebb CPU -kozott amivel dolgoztam,
eljutottunk a vert kell hugyozni hogy ertelemesen menjentol, a kit erdekelig ;-(

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Nyosigomboc v | 2022. 09. 28., sze – 15:08 )

Ha nem lenne ilyen gusztustalanul ronda a szintaxisa par hupra bemasolt pelda alapjan, raneznek. Ugyanakkor nem hiszem, hogy mindenutt ki tudna valtani.

Mondjuk amilyen hype van korulotte, lehet, hogy igy is beletanulok.

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

„ronda szintakszis” = mást szoktam meg.

Én a Lisp nyelvektől tudok falra mászni (jó, tudok még nem popular nyelveket említeni, de minek [forth?]), ettől még nem rossz csak szokatlan.

Ez érdekes dolog, mert amikor elkezdesz vele játszani megszokod. Amikor megnéztem a Go-t akkor ütötte a szemem a fordított type-variable sorrend, de hát pont annyira logikus mint a másik. :-) Engem pl. a C-szerű syntax idegesít néha, mert többet használok mást. Ez megszokás kérdése...

… most people don't plan to fail - they fail to plan
---
* Origin: LifeForce WHQ (2:370/15)

"ronda szintakszis" == "ronda szintakszis"

Nem fejlesztettem soha Lispben, soha nem tanultam, de megis elegansnak es egyszerunek tartom a zarojelezgeteset.
A C-nek - a nyelv korlatai ellenere - majdnem tokeletes a szintaxisa. Nem veletlenul masoltak le ennyien.
Pythont viszonylag sokat hasznaltam mostanaban, egyik kedvencem (C++ mellett), szintaktikailag is egeszen jo, de par dologra azert nyomnek egy refaktort, foleg a PEP8-ban, de a self/this es a kettospontozas kornyeken mindenkepp (miert kell : az if utan, es miert nem zarojelezik? foleg: else utan minek? miert kell kiirni a self-et metodusnal? tabot nem lett volna szabad megengedni, mert ha valaki tabot tesz a kodba, nagy kavart csinal).
JS egy agyfasz nyelv sok szempontbol, de megis muszaj hasznalni ha olyan a project. Mostanaban azt is sokat hasznaltam, megszoktam, de vannak benne nagyon ronda megoldasok.
Pascalt/Delphit is hasznaltam, megszoktam, de alapvetoen nem tetszik.
Perlt alig ismerem, de aki jol ismeri, azt is meg tudjak kavarni a write-only kodok, ez a nyelv pedig ismert rola.

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

> miert kell : az if utan

if feltetel: x=y+z
else: x=y-z

de pl. 1 sorba nem lehet ezt se irni, de igy legalabb nem 4 sor :)

> tabot nem lett volna szabad megengedni

py 2.x nagyon engedte a vegyes tab+space, mikor upgradeltem a kodjaimat 3.x-hez az volt a legnagyobb melo rendbetenni

> Miert baj, ha 4 sorban van?

tobbet kell gorgetni :)

en C-ben mexoktam hogy rengeteg dolgot beleirok 1 sorba is akar, egy if-else siman de ennel komplexebb dolgokat is. mondjuk az olvashatosagnak nem tesz jot, en en irok nem olvasok, szoval lesz...om

szerintem itt tobben rosszul lennenek ha meglatnak a kb 200 sor C kodban megirt NTFS filerendszer parserem...

C esetén mindenki olyan kinézetben kódol, ahogy szeretne. Jó esetben elolvassa a projektre előírt "CodingStyle.txt" állományt, és amit megjegyez belőle azt talán be is tartja.
Rust esetén van egy "standardizáló" tool:   cargo fmt
Itt látható például a Linux kernelben meghatározott standard Rust-ra. Jelenleg alig tér el az alapértelmezett kódformázástól.
Egységes kinézet indoka: egy forráskódot normális minőségbiztosítás esetén egyszer megírnak és több alkalommal is ellenőrzik független szemek.

" Perlt alig ismerem, de aki jol ismeri, azt is meg tudjak kavarni a write-only kodok, ez a nyelv pedig ismert rola." - Bármiben lehet olvashatatlan kódot elkövetni, nem nyelvfüggő. Nekem vannak 10+ éves Perl-ben írt dolgaim, és kifejezetten jól olvasható/érthető akkor is, ha évekig rá sem néztem - nem kell órákig gondolkozni egy egy részlet megértéséhez. Igaz, ahol "trükközés" van (mert van), ott van komment is, hogy mit és miért úgy...

s/lehessen/kell/g - és itt el is qufták a dolgot, hogy a whitespace kifejezetten releváns része a kódnak. Trehány kódgányoló pájton ban is tud ronda és nehezen emészthető kódot kreálni, a munkájára igényes programozó viszont _sehol_ nem az adott nyelv "obfuscated code contest" jellegű versenyét óhajtja megnyerni.
Gyakorlatilag a trehány kódereknek a rákényszerítése arra, hogy normálisan kinéző forráskódot adjanak ki a kezükből. (máshol ezt kódolási szabvánnyal, cross-review bevezetésével, vagy épp a commit-hook által megfuttatott kódformázóval érik el...)

Nem a rossz koderek kenyszeritese a fo elonye, hanem hogy nem kell duplan megadnod es karbantartanod ugyanazt az informaciot. Amikor kodolsz, alapvetoen te is a behuzast nezed a blokkokhoz, nem a kapcsoszarojeleket szamolod (horribile dictu: begin-end-et). Akkor meg miert adnad meg ugyanazt maskepp is? Eleinte nekem is kicsit szokatlan volt, de a jot eleg konnyu megszokni.

Ja, plusz ha neked pont szamit a sorok szama (mint Arpinak), akkor a {} es begin-end sem foglal feleslegesen sort.

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

Amikor kódolok, akkor jellemzően a blokk nyitása utánra rögtön berakom a záró elemet _is_, kommentben azzal, amivel a blokk indul (if, for, satöbbi - a "jót" könnyű megszokni, igen - ez is egy "jó" megszokás szerintem... ). "Véletlenül" nem lehet lezárni egy blokkot egy elrontott behúzással, ellenben bármilyen proporcionális fonttal nyomtatva is olvasható és azonosan értelmezhető lesz a kód - ellentétben azzal, ahol a whitespace "része" a kódnak.

a whitespace kifejezetten releváns része a kódnak

Pontosítsunk: nem a whitespace része a kódnak, hanem a kódblokkok behúzása. A kettő nem ugyanaz. Lásd pl.:

$ cat whitespace.py 
print("hello")
print( "hello" )

myList = [1, 2, 3, 4, 5]
yourList = [ 1,
      2,
               3, 4,
                  5 ]
print( myList == yourList      )
$ python3 whitespace.py 
hello
hello
True
$

Miért gond ez, hogy a whitespace releváns része a kódnak? Értelmes helyen van coding standard, még értelmesebb helyen már a PR-t sem tudod létrehozni, amíg nem felelsz meg neki. Ezen a whitespace-es kérdésen én is kb. addig rágódtam, amíg fogalmam sem volt a nyelvről. Nálatok nem szokás behúzni az összetartozó kódblokkokat, vagy miért beszélünk erről úgy, mintha az indentálás most valami plusz teher lenne? :)

Ez a zárójelezésre is igaz.

> De gelei, az IDE kiteszi a zárójeleket, meg ha nem is tenné ki, akkor kiteszem én, és sosem lenne hibalehetőség benne!

De van hibalehetőség, két helyen is. Egyrészt a zárójelezést ugyanúgy be lehet nézni, ráadásul ott is a (helyes!) indentálás segít, hogy a }}}} közül lásd, melyik hova tartozik. Másrészt debuggoltam én már bőven olyan kódot, ahol a nem-kötelező zárójelezés miatt csesződött el valami. (Pl. egyutasításos if-blokk bővítése, ugye, klasszikus fuck-up) Nem véletlenül tolom mindenhol, hogy (1) explicit és részletes coding standard kell, és (2) ezt tool szinten ki kell kényszeríteni

A zárójelezésnél a leggagyibb IDE/text editor is mutatja, hogy hol a párja, ha kell, oda tudok ugrani megnézni.

"a nem-kötelező zárójelezés miatt csesződött el valami" - attól, hogy nem kötelező, még szabad, és normális kódolási szabványok használata esetén kötelező használni. Ha meg valaki van olyan barom, hogy pájtonosan csinálja (mert ugye ott ha két sor ugyanúgy van behúzva, az egy blokk...) ott, ahol nem úgy kell blokkot írni, akkor az menjen el szépen kapálni, vagy maradjon a pájton mellett, és más nyelveken írt kódot readonly módon, bottal se piszkáljon.

"Nem véletlenül tolom mindenhol, hogy (1) explicit és részletes coding standard kell, és (2) ezt tool szinten ki kell kényszeríteni" - na ebben tökéletesen egyetértünk. Ha a nyelv ad hozzá mankót, az csak plusz haszon.

> A zárójelezésnél a leggagyibb IDE/text editor is mutatja, hogy hol a párja, ha kell, oda tudok ugrani megnézni.

Ha több oldalt átfog akkor nem mindegyik tudja azt, hogy ilyen peek ablakban megmutatja az elejét. Persze van erre is code standard, hogy ne legyen több oldal egy metódus, csak aztán van amikor még sincs úgy. Vagy vannak a beágyazott osztályok meg hasonló nyalánkságok is. Szóval ritkán, de volt már amikor fejtörést okozott, hogy ennek meg hol a vége vagy az eleje.

FYI: zellernek teljesen be van kattanva ez a whitespace dolog, elég felesleges erőlködés meggyőzni arról, hogy ez egyrészt elég ízlés kérdése (ti: van pro/kontra, és hogy hogyan súlyozod magadnak őket az egyszocprob), másrészt hogy ez egy teljesen marginális issue, nem ettől lesz szar a python, ha az lesz. És sajnos nem nagyon tudja ilyenkor levenni a kettőslátását, hogy máshova ér az ide support, de a pythont nem lehet papírra proporcionálissal nyomtatni, tehát szar. Ez a 77 kör, egyszerűbb elfogadni, hogy szerinte ez ettől szar, és kész.

A whitespace/identálás dolgot a kód részévé két okból tették: ezzel is különbözni a többi nyelvtől, és a trehány, igénytelen kódot kreáló barmokat rendre tanítani. Aztán jön a pájtonos kóder, és más nyelven a nem kötelezően blokkba írandó utasítás máris alkalmat ad neki az el...ásra...

A whitespace mint az adott szövegfájl értelmezésének lényegi része kifejezetten kellemesen tudja szivatni az embert, akár pájton, akár yaml... És ez utóbbinál is jött szembe nem egy nem két báááázmeg... Na ezért (is) rühellem azt, hogy nincs explicit blokknyitó és záró jelölés - illetve a sorvég plusz x darab whitespace a nyitó, és a sorvég plusz x-nél kevesebb whitespace előtt van vége...

( bodobacs | 2022. 09. 28., sze – 17:20 )

Nemrég beleolvastam a Rust bevezetőjébe. Ez a nyelv irdatlan ronda. Azt árulja már el nekem valaki, hogy feltétlenül szükséges beemelni mindenféle nyelvből megoldásokat mert a funkciókhoz kell vagy ez csak olyan variáljunk már megint, mert túl könnyű ...?

( carlcolt | 2022. 09. 28., sze – 17:25 )

Driver es OS szintu benchmarkokkal en fogom helyette alatamasztani?

( Chain-Q v | 2022. 09. 28., sze – 17:57 )

Én már átéltem azt amikor a megmondóemberek szerint "ideje Pascal helyett C-t használni", az "ideje C helyett C++ és Java-t használni" az "ideje Java helyett C#"-t használni és most az "ideje C/C++ helyett Rust-t használni"-t.

Én meg még mindig elvagyok a magam kis Pascal compilerével a saját céljaimra, és mellékesen elég jól élek abból, hogy mennyi legacy kódot hátrahagytak a tech-vizionáriusok a fent felsorolt technológiákkal, amikhez egy ifjú titánnak sincs gusztusa már hozzányúlni... Nem véletlenül a COBOL programozók az egyik legkeresettebbek... A C/C++ programozók lesznek a következők. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( icserny | 2022. 09. 28., sze – 18:21 )

Ha most a C/C++ elavult nyelvnek lesz nyilvánítva, akkor dobjunk félre minden c/C++ programkönyvtárat, amelyekbe millió emberévnyi munka lett belefektetve, s kezdjünk mindent elölről?  Tényleg ennyire gazdagok vagyunk?

Az új projekthez ugyanúgy nincs rustos lib, azt meg kell írni. A libeket meg kell írni, át kell írni.

A C++ és Java igazán nagy előnye az hogy millió lib van hozzá, meg kiforott toolok.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

A libeket meg kell írni, át kell írni.

Nem. Python alatt is tudsz hasznalni C-s libeket. Tessek pl. itt egy C-s lib amit tudsz hasznalni https://crates.io/crates/graphicsmagick

Ha nincs is meg valami, megcsinalhatod te a bindinget neki.

 akkor dobjunk félre minden c/C++ programkönyvtárat, amelyekbe millió emberévnyi munka lett belefektetve, s kezdjünk mindent elölről?

Bar egyelore nincs sok tapasztalatom a rust-al, de azt gondolom nagy baj lenne, ha nem lehetne vele tetszoleges kulso libet hasznalni. Tessek pl. itt egy openssl binding: https://docs.rs/openssl/latest/openssl/

( ggallo | 2022. 09. 28., sze – 19:31 )

Én azt nem értettem soha (a 80-as évek végén, 10 évesen, Turbo Pascal-lal kezdőként), hogy miért kellettek a GC-s környezetek egyáltalán. Kényelemből és hozzá nem értésből szerintem. Nagyon gyorsan lehetett bennük nagyon szar minőségű kódot/végeredményt írni. Az ilyen rendszerekben mindig több a végén a hiba, az erőforrás igény és kisebb a teljesítmény.

Aztán megint feltalátuk a Commodore korszakot idéző interpretált BASIC-like (PHP, JS, Python, stb.) nyelveket, amik ráadásul nem típusosak és GC-t használnak a gyengébbek kedvéért (kvázi semmire sem kell figyelni, de cserébe vagy fut vagy nem, és ha hiba van benne, vagy megtalálom, vagy nem), majd ezeket elkezdtük lefordítani futás közben valamire, mert az isten hardvere nem volt elég a normális sebességű futtatásra, meg kiegészítőket kezdtünk hozzá használni mert a kényszerített típusosság hiánya több bajt csinál mint hasznot hoz, stb, stb.

Aztán most megint visszakanyarodunk - mintha feltaláltunk volna valami újat - az erősen típusos, erősen formázott, szigorú szabályokat kényszerítő, GC nélküli és terjedelmes forrású, lefordított programokhoz, hogy jé, mennyivel kevesebb a hiba és mennyivel gyorsabban fut a mennyivel kisebb végeredmény...

Mint amikor az egyik ügyfelünknél az új japán műszakvezető a 4000 db/műszakos teljesítményt elrontotta 2600 db/műszakra hozzá nem értés okán, majd fél év alatt rájött hol hibázott, és mindenki ünnepelte - a javítás után -, hogy 2600 db/műszakról javított 4000 db/műszakra a termelékenységen, milyen hozzáértő, jó, hogy ide helyezték...

> miért kellettek a GC-s környezetek egyáltalán

mert C-ben tul sokan benak voltak a free()-t megfeleloen hasznalni (vagy nem hivtak vagy 2x is), es a mai napig talalnak 1000 eves elvileg jo minosegu kodokban is ilyen hibakat az egyre jobb kod analizatorokkal. pedig 20 eve is nezegettuk valgrind-el a memleak-eket, de ugye az is csak a futasidoben elofordulo hibakat talalta meg, a ritkan lefuto (vagy direkt hibas inputtal triggerelheto) agakat nem nagyon vette eszre.

a GC-t is lehetne jol csinalni, megfelelo referencia countinggal, ha kell forced free-vel (pythonban 'del x') eleg jol hasznalhato. az hogy a korai java-k brutalisan szar gc-t csinaltak az nem a gc hibaja hanem az implementacioe.

> Commodore korszakot idéző interpretált BASIC-like (PHP, JS, Python, stb.) nyelvek

azert tegyuk hozza, hogy a python eredetileg a perl ellen indult annal jobb sebesseget es emberibb script szintaktikat igert. es valoban shellscriptek, szovegfeldolgozas celjara kenyelmes es gyors is volt. csak aztan valaki kitalalta hogy irjunk webszervert benne :)

a js-t sem arra talaltak ki amire ma hasznaljak (node.js szerveroldalon meg sok 100 megas js programok futnak bongeszoben).

Rust -ban is van lehetoseg bizonyos dolgokat gc -z getni:
https://doc.rust-lang.org/stable/std/rc/struct.Rc.html https://doc.rust-lang.org/std/sync/struct.Arc.html

Van hogy ez lesz legjobb megoldas,
nem kell miden picsanyi teruletre ratolni es akkor nem lesz nagy az overhead.
Egy nagy fat ki lehet vagni a gyokerenel ;-)

Ill rust-ban is lehet magasabb szintu eszkozok altal hasznalt koncepciokat megirni, es aztan hasznalni:
https://github.com/Manishearth/rust-gc

 

rust alapbol runtimeless,
de go-t is lehet belole csinalni async .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nagyjából egyetértek annyi korrekcióval, hogy a GC-nek szerintem van némi értelme, de az eddigi implementációk tényleg problémásak. Egyszer foglalkoztam a kérdéssel, szerintem lehetne csinálni teljesen párhuzamosan futó GC-t teljesen megállás nélkül, ha volna ilyen, akkor nem is volna baj vele.

A memória kezelés problémája egyébként nagyon kellemetlen ügy, ha van dinamikus memória foglalás akkor már lehet szivárgás is. Foglalkoztunk ilyenekkel, hogy szivárgásokat kerestünk, nagyon sokat el lehet szórakozni vele. És szerintem Java-ban sokkal egyszerűbb megtalálni, mint C-ben vagy C-szerű dolgokban például.

Java eszközökkel ha tudod reprodukálni a szivárgást, akkor van eszközöd megtalálni az okát. (teljes heap dump összehasonlítás, allokáció logok, stb)

C-ben nagyon nehéz dolgod van, mivel a heap nem tartalmaz típus információt, elvben nem felderíthető egy heap map úgy mint Java alatt. Persze ha minden típus tisztességesen van használva, akkor elvben lehetséges volna ilyet készíteni de én még nem láttam ilyet.

 

A típusossággal teljesen egyetértek: a szigorú típusosságot ki nem kényszerítő nyelvekkel szerintem szívás dolgozni már kis programnál is, egy méret felett pedig iszonyat.

C-ben is van union, meg lehet cast-olni, meg van void* pointer, szóval a típusosságot ott hágom át, ahol nem szégyellem, bár ez így van jól. Ha nem lehetne benne lényegében bármit megcsinálni, mint assembly-ben, nem szeretném.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mert a kézzel történő memória kezelésnek az imlementált üzleti funkciók szempontjából nincs hozzáadott értéke viszont felesleges hibaforrás. Az egész IT az absztrakciós szintek emeléséről szól, csak így lehet nagy, rengeteg funkcióval rendelkező megoldásokat készíteni normális határidőn belül.

Hogy ez mennyire releváns jól mutatja hogy a sebezhetőségek jó része valamilyen memóriafoglalással-memória kezeléses programozói hibára vezethető vissza. Lehet azt mondani hogy a fejlesztők a hibásak, de ha az elmúlt 50 évben nem sikerült megtanulni olyan kódot írni amiben nincs ilyen típusú hiba, akkor lehet, hogy inkább a koncepciónk rossz.

No, ebben segít a GC, és többek között ezért is váltotta a java a 2000-es évek elejétől kezdve a korábban C++-ban írt rendszereket. 

Igen, nagy felelősség van a programozón, ha nem GC-s nyelvvel dolgozik. És valóban, elég sok hiba is születik emiatt. De én úgy látom, hogy a GC "feltalálása" és elterjedése, meg az erős típusosság elengedése összességében nem segített, hanem rontott, mert ahogy haladtunk előre az időben, úgy születtek egyre rosszabb minőségű szoftverek az egyre modernebb, a fejlesztőről egyre több terhelt levevő nyelveken... Szerintem a nyelvek "fejlődésével" párhuzamosan a fejlesztők romlottak - már elnézést a kivételtől, aki nem. Ha 30 évvel ezelőtt szocializálódott fejlesztők használnák a mai modern nyelveket, akkor valószínű jó programokat írnának, könnyebben. De olyanok fejlesztenek (bootcam-ek erre ékes példa) akinek semmilyen algoritmikus vagy egyéb, programozáshoz (szerintem) elengedhetetlen gondolkodásmódja nincs, csak rutinszerűen elő tudnak állítani kódokat a kezük alá dolgozó félig automatizált "eszközzel".

Olyan ez, mint az autók vezetés támogat rendszerei, hogy nem a jó fofőröket védik még jobban a gyakorlatban, hanem az egyre alkalmatlanabb sofőrök lesznek általuk egyre bátrabbak.

A C++-al két nagy baj volt:

1) a C kiterjesztéseként tekintettek rá

2) sok idő alatt tanulták meg, hogy a nyelvet hogyan kell használni.

C-t ott érdemes használni, ahol nem vagy alig kell dinamikus memóriakezelés. C++-ban meg ott vannak a konstruktorok meg a destruktorok, amik ezt megteszik helyetted. Nyilván ha a változót objektumot a stack-en allokálod, akkor nincs több dolgod. Ha std::vector-t használsz, akkor sincs több dolgod.

Na, miután ez olyan szépen hangzik, utána jön a csapnivaló C++ standard library a C-ből származtatott típusokkal, char* stringekkel meg hasonlókkal. Onnan lesz hányadék a nyelv.

Minden feladatra a megfelelo eszkozt kel hasznalni. Rengeteg feladat van amire egy dinamikus tipusos (magyarul milyen sehogy hangzanak ezek a muszaki fogalmak), GC-s nyelv a legmegfelelobb, mert a legfontosabb szempont az, hogy milyen gyorsan irom meg azt a szkriptet amit lehet csak 1szer hasznalok. Es ez csak a vege egy skalanak ami hosszan nyulik. Az olyan nyelveknek amik arra vannak optimalizalva, hogy gyorsan lehessen irni bennuk a programot, igenis megvan a helyuk. Nem kell oket arra hasznalni, amire nem valok - komplex, fontos, nagy pontossagot vagy teljesitmenyt, stb igenylo feladatokra. Szerintem ezeknek a nyelveknek a rosz hire onnan fakad hogy sokszor megis olyasmire hasznaljak oket amire nem valok es ezert szenvednek vele az emberek.

:wq

Ezzel egyetértek természetesen, csak nem akartam az eredeti gondolatomról elterelni a figyelmet azzal, hogy elkezdek (szerintem elfogadható) "kivételeket" sorolni.

Én is nagyon szeretem pl. a Python-t, sokkal gyorsabban, szebben, átláthatóbban lehet benne egy-egy script-et írni shell script helyére, és még sokkal gyorsabb is a futása amannál. Nem kezdenék bele Pascal-ban megírni azt, amire a Python a legjobb választás.

Ahogy írod is, a legtöbben megtanulják (valamennyire) a számukra legkönnyebben emészthető (jellemzően legtöbb segédlettel rendelkező) nyelvet, és utána a klasszikus, akinek kalapácsa van, mindent szegnek néz következik. Az (én értelmezésemben igazi) fejlesztő ismer egy csomó nyelvet - mert a programozáshoz a nyelvismeret csak szükséges de nem elégséges feltétel -, és az adott feladathoz legjobban passzoló nyelvet választja. Programozni tudni szerintem nem egy programnyelv ismeretét jelenti, hanem az algoritmizáló képesség meglétét.
Ilyen kevés van, mára architect lett belőle, és igen kevés kódot ír (szerintem) - sajnos.

Igen sajnos eléggé jellemző ez a hozzáállás (kalapácsom van és minden probléma csak szeg lehet). Dolgoztam olyan cégnél ahol mivel a fő termék pythonban volt írva (pedig szerintem már ahhoz se volt alkalmas a python) és csak python fejlesztők dolgoztak a cégnél, mindent is pythonban írtak... beleértve egy asztali GUI alkalmazást amihez a QT python bindingokat használták. A vicc, hogy a célhardver ismert volt -- egy nagyon vékony vékonykliens aminél szerintem a telefonom is combosabb -- és windows futott rajta. A pythonban írt GUI app szaggatott rajta szépen. Könyörögtem a menedzsereknek, hogy hadd írjam meg legalább a bonyolultabb Widgeteket C++ ban ha az app muszály C++ legyen. De nem, minden python kellett legyen. Szóval kínlódtunk mint disznó a jégen, hogy a használhatóságot legalább megközelítsük.

:wq

oszt' az ido csak oket igazolta:

ma mar nem kapsz olyan celhardvert, ami olyan lassu lenne, hogy nem tud egy nyamvadt pythonos guit futtatni....

:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hát nem tudom. Ez olyan 8 éve volt, szóval nem olyan nagyon régen. Akkor is és most is lehet még kapni olyan Intel Pentium/Celeron/Atom processzoros gépeket amik még a Windowssal magával is megkínlódnak, nemhogy egy pythonos GUI-val. És szerintem akadnak olyan garasoskodók akik ezeket veszik kasszásgépnek valami normálisabb HW helyett. Nem mondom, hogy ez bizonyíték bármi ellen vagy mellett. Én csak amellett kardoskodok továbbra is, hogy a megfelelő eszközt kell választani a feladatra. A python GUI teljesen rendben van egy kicsi egyszerű alkalmazáshoz. Egy nagy és bonyolult alkalmazásnál viszont már eléggé fájdalmas kezd lenni a használata, amit csak fokoz az ha a célhardver gyengus.

:wq

Nem mindig lehet megfelelő hardware-t kapni. Legyn hosszú ideig támogatott, legyen a feature set olyan, amilyenre szükséged van, keveset fogyasszon, legyen kicsi, ha véletlenül elfut rajta egy Windos CE, az sem baj - mondjuk ilyet már nem igazán kapsz, és én örülök annak, hogy Linuxra migrálunk majd -, legyen olcsó. Ha ezt mind megnézed, legfeljebb két-három gép jöhet egyáltalán szóba, ami a végén egy lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> hogy a megfelelő eszközt kell választani a feladatra.

 

Jah, csak akkor a windows illo modon essen ki a feltelek kozul.

En is lattam mar betarolos polcrendszert, amiben celgep volt, ami annyit jelentett, hogy egy alulspecifikalt rugged pc volt, amin a  windows is kinlodott, de akkor meg megfejeltek egy mssql serverrel, es modbus demonnal, ami az eszkozkezeloben csucsult. Es mivel annyi baja volt a cuccnak igy kellett a gyarban tavoli asztalt biztositani a norvegoknak, hogy tavolrol tudjak piszkalni.

Napi valami 100MB database logot gyartott. Olyan 10(!) perc volt, mire bebootolt a windows.

 

Hallod egy arduino elvitte volna a feladatot. Egy szaros talcat kellett betenni a helyere. Az arduino ele tettel volna barmit, ami logolja hogy mi hol van (kb. adatbazis), es megvagy.

Nem, ezek fogtak egy windowst becsomagoltak egy horrordraga (ugyanakkor gagyi) ipari pc-ben, es ez elott kellene leborulni?

 

Szoval nem a python + Qt gui volt ott a fo problema nalad.

En irtam raspberry 3-asra weboldal guit, CSS animaciokkal, miegyebbel (fullscreen, automatan indult). Teljesen hasznalhato volt, nem volt akadas, roccenes. Es lehet kopkodni: a projekt node.js-ben volt, es hardware-t kezelt (soros port, i2c).

 

Nem, nem a python + Qt-nal kellett volna optimalizalni, erre kb. a nyakamat mernem tenni.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Látom skeieült jól elvinni a beszélgetést arra, hogy igazávól a HW-el volt a gond. Igazából egyet értek veled, de a kliens minket kész tények elé állított: ez a HW, már betáraztunk belőlle X ezret, erre kell fejleszteni. Nem mindig ésszerű, végiggondolt érvek mentén van választva a HW... Ezt tetézte a másik döntés (a mi cegünkön belül), hogy python lesz az implementációs nyelv.

:wq

Érdemes azért ezt a másik oldalról is átgondolni, mert bár műszaki szempontból teljesen igaz, hogy feladathoz az eszközt, de cég szempontból ez nem mindig járható, hiába lenne a fasza az, hogy akkor az alap python, de itt-ott, ahol kell c, azt a backendet írjuk meg javaban, mert épp ott van valami fasza stock lib hozzá, a cloud management oldalát mert goban, mert az szexi, mert ki a fene fogja ezt karbantartani. Egyrészt lesz egy csomó műszaki sallang: más buildrendszer, hogy lesz a CI, hogy lesz a teszt, hogy lesz mondjuk statikus analízis, hogy fogunk megbízhatóan csinálni 18 féle artifact repositoryt. Aztán jön a ki fogja ezt csinálni? Ok, hogy te most éppen beszélsz C++, de akkor majd innentől úgy kell csapatot karbantartani, hogy mindig legyen, aki beszéli ezt is, azt is*, ha egymással van dolguk, akkor nem árt néha, ha mindkettőt ugyanaz, azt meg, hogy mindenre legyen külön team, az nem mindenhol fér ám bele (vagy indokolt egy kisebb darabhoz), de ha van, még akkor is az van, hogy ha a több teamben kb azonos a tech stack, akkor sokkal nagyobb mozgástered van mint cég, mert tudod azt mondani, hogy akkor most oda fejlesszetek mondjuk egy 3 hónapig, mert ott fáj.

* és nézd meg azért itt az álláshirdetéseket. Kis túlzással, ha egy hirdető le mer írni egy konkrét technológiánál többet, jön a flock mantrázni, hogy ez legalább három munkakör...

Igen, a valóságban sokszor nem ilyen egyszerű a dolog.

Jelenlegi munkaadómnál a fejlesztők nagy része (legalábbis amikor engem felvettek) C++ programozó volt. Mégis a fő terméken kívül semmit se fejlesztünk C++-ban, egyszerűen mert nem az a megfelelő eszköz a feladatra. Build automatizálás, tesztelés stb. az python-ban történik mert egyszerű és mert vagy mindenki tud már python-t, vagy ha nem akkor pár nap alatt megtanulja alap szinten. Cloud backend, menedszment szoftver, stb az golang. Ezekre fel lettek építve teljesen új csapatok (QA, cloud, manager, stb) olyan emberekkel akiket direkt erre kerestünk. Ez persze sokkal nehezebb mint pár meglévő embert áttenni egy új projektre amit csuklóból azon a nyelven fejlsztesz amiben az emberek eddig is fejlesztettek, és nem minden projekt elég jelentős, hogy ennyi erőfeszitést megérjen.

:wq

Az én véleményem hogy széles körben használható nyelv csak GC alapú lehet.

Nagyon sok időt bele kell fektetni hogy nagyon jó legyen az interpreter/xVM (direkt nem JVMet írtam), de csak kevés embernek kell ebben jónak lennie és az ő feladatuk az hogy hibamentes legyen a memória kezelés és a többi low level funkció.

Mikor webszervert írok akkor nem a memóriakezelést akarom faragni.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

( denesb | 2022. 09. 29., cs – 07:23 )

Arra szavaztam, hogy nem ertek egyet, de a kep ennel arnyaltabb. Nem ismerem a Rust nyelvet reszletekbe menoen (nem hasznaltam meg) de az alapjan amit olvastam rola tenyleg igeretes es alkalmas lehet arra, hogy egy jobb alternativat nyujtson olyan helyztekben amikor valaki a C-ert vagy C++ ert nyulna amugy.

Viszont, nem latom, hogy a C-t valaha teljesen kivaltana: a C meg mindig teljesen verhetetlen olyan helyztekben amikor nagyon fontos, hogye egy a gepi kodhoz a leheto lekozelebbi nyelvben programozzon az ember, mert minden cseppet ki kell facsarni a hardverbol. Minel magasabb szintu egy nyelv annal nehezebb latni, hogy hogy fog kinezni ez a kod amikor a processzor lefuttatja. Mar a C++ is tul magas szintu ehhez szerintem.

A C++ pedig az irdatlan tehetetlensege miatt nehezen kivalthato. Az evek soran egy akkora okoszisztema epult ki kore, ertsd: forditok, eszkozok, konyvtarak, tudas, stb. amit egyszeruen nagyon nehez lesz kivaltani, lecserelni. Nem lehetetlen, de nem fog 1-2 ev alatt megtortenni, es ha a Rust bizonyit hosszu tavon is, gyul vele a (pozitiv) tapasztalat nagy, hosszan futo projektekkel is, akar el tudom kepzelni, hogy evtizedek tavlataban kivaltsa a C++-t.

:wq

 C meg mindig teljesen verhetetlen olyan helyztekben amikor nagyon fontos, hogye egy a gepi kodhoz a leheto lekozelebbi nyelvben programozzon az ember, mert minden cseppet ki kell facsarni a hardverbol. Minel magasabb szintu egy nyelv annal nehezebb latni, hogy hogy fog kinezni ez a kod amikor a processzor lefuttatja.

C is a lie. 

A Rust részhez tudok hozzászólni: alkalmas C*.* helyett, de nyilván nem úgy, hogy valaki C-t ismer és azt gondolja, hogy átül a szomszéd autóba és már megy is.

A Rust Nagy Átverése az (szerintem), hogy csak akkor tudod jól használni ha érted, hogy hogyan működik a memóriakezelés és a pointerek (nem kell leprogramoznod, de a megértéshez szerintem elengedhetetlen, különben az egész egy végtelen küzdés a compilerrel). Bizonyos szempontból felfogható egy „rossz programozó” filternek. :-)

Nyilván a másik Nagy Rust Átverés az, hogy a memóriastabilitás nem garantálja a hibátlan algoritmust vagy hibátlan programot; legalábbis többen azzal a naív csodálattal néznek rá, hogy ebben majd nem lehet rossz programot írni, de hát hogyne lehetne, az emberi találékonyságnak nincsenek határai! ;-)

De szerintem egy szépen átgondolt, logikus nyelv, és a memóriakezelése tényleg jó (nem csak biztonságos, de erőforrásbarát is); mivel a sérülékenységek 80+%-a memóriakezelési hiba, ha semmi mást nem tud ezzel már így is megmentené a világot az azonnali pusztulástól. (Amúgy érdekesség: a Rust alapból képes „embedded” kódot gyártani, ami minimális méretű és nem tartalmazza default a rendszerkönyvtárakat, így nem kell multimegagiga méretű file-okkal dobálózni, ha valakinek erre van igénye. Mindemellett a bazi file-ok ellenére a kód iszonyú gyors, a látszólagos magasszintű absztrakciók ellenére.)

De kiváltani nem fogja a C-t (és a C++-t sem), egyszerűen azért mert egy csomóan nem akarnak megismerkedni egy teljesen új ökoszisztémával, libekkel, eljárásokkal, és persze a lovely szintaxissal. :-)

 

Sztori: kijött pár hónapja egy sérülékenység a mozillában, egy rustban írt részben. Néztem bután, megnéztem a kódot, és úgy kezdődött hogy

unsafe { ...

Ilyen ez a popszakma. (Btw nincs Rust highlighter, elavult ez a hup... :-])

… most people don't plan to fail - they fail to plan
---
* Origin: LifeForce WHQ (2:370/15)

( YleGreg | 2022. 09. 29., cs – 10:23 )

En bash nyelven programozok mindent, ugyhogy de facto a bash a vilag legjobb nyelve. :-)

( turul16 v | 2022. 09. 29., cs – 10:29 )

Szerkesztve: 2022. 09. 29., cs – 12:25

Nagyon gyoker micro vezerlot asm -ben kene, de manapsag az emberek raszoktak C++ -ra is,
nem csak a C -re.

Nem vagyok meggyozodve arrol hogy erdemes gyoker 8 bites valamikre uj forditot csinalni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( ssikiss | 2022. 09. 29., cs – 15:16 )

Most hogyha ezt az Azur főnök mondja, akkor ezzel csökkent majd (mindenki) rezsit? Biztos megbeszélte Satyával.

Stratégiát mikor akar publikálni? Egyébként tessenek forradalmat csinálni! Vezesse ki a fejlesztőeszközeiből meg az oprendszerét írja át. XD

( sinexton | 2022. 09. 29., cs – 20:26 )

131igen és 174 nem szavazat különbsége szignifikáns.

(Sub)

( uid_6201 v | 2022. 09. 29., cs – 22:47 )

Egy alaposabb háttérolvasmányt ajánlok figyelmetekbe a memóriakezelés lehetőségeiről: https://www.toptal.com/software/eliminating-garbage-collector
Rust GC folyamat futtatása nélkül tudja azt a biztonságos memóriakezelést nyújtani, amit az eddigi programozási nyelvek kizárólag az időnként lefutó GC folyamattal tudtak megvalósítani, GC nélkül pedig eddig sehogy. A GC folyamat pedig sok esetben igen hátrányos, kényszerből kellett eddig futnia. Például legegyszerűbb belátni realtime rendszereknél, ahol ha a GC folyamat véletlenszerűen futni kezd, akkor a kiszolgálási időt nem tudja a rendszer a definiált határértéken belül tartani.

Ezen kívül sok más dolgot szintén az alapjaitól gondoltak újra, ahol a cél a biztonságosság és a hatékonyság volt. Hátrány: egy rutinos C++ vagy Java programozónak sem könnyű átszoknia rá, az ownership és következménye kapásból sokakat megakaszt. Ez tehát nem olyan váltás, mint a Java --> C#.
Másik hátrány: alapból például a memóriahozzáférést teljeskörűen ellenőrizné futásidőben (= biztonság), kivéve amit igazol a fordítási időben hogy tuti nem lehet gond. Tehát ilyen esetben nem kell futásidejű határellenőrzéssel lassítani a lefordított kód futását, ellenkező esetben viszont mindig. Az ezen való elszöszölés igencsak elnyújtja a fordítási időt.
Végeredmény: memóriahozzáférési hibáktól mentes és gyors, sőt random GC folyamatfutástól is mentes assembly kód.

Nem vagyok ideológiailag elég jól képzett, de a dinamikus memóriafoglalások és felszabadítások által fragmentálódott memóriát nem lehet hardware-esen úgy lapozgatni, hogy folytonos virtuális címtartomány kerüljön egy összefüggő blokkba? Szerintem azt már feltalálták, hogy a felső címbitek bemennek egy memória címvezetékeibe, s ezen memória adatlábai adják a fizikai, RAM-hoz menő címbiteket. Az pedig a kernelen múlik, mit ír ebbe a lapozó picike RAM-ba.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Arra gondoltam, hogy fragmentálódik a címtartomány, lyukacsos, mint a sajt, foglalt és szabad területek váltogatják egymást. Ha ezt össze tudjuk gereblyézni úgy hogy a foglalt területek egymás után legyenek, utána a szabad területek szintén egy blokkban, akkor nyertünk, különösképpen, ha ehhez nem kell adatot módosítani, legfeljebb címeket a nyilvántartásban. Nem gondoltam végig, de gyanítom, memória blokkok lapozgatásával meg lehet csinálni. Persze lehet, hogy csak realloc() hívásakor van erre lehetőség, hiszen az a cél, hogy más címre kerüljön tényleges adatmozgatás nélkül az adat, csak ha erről nem tud az alkalmazás, akkor baj van. Ugye a realloc() nem garantálja, hogy ott marad az adat, ahol eddig volt, ezért érdemes offset-et, ha úgy tetszik, tömb indexet használni címzéshez pointer helyett. Vagy minden realloc() után újra kell számolni a pointereket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Arra gondoltam, hogy fragmentálódik a címtartomány, lyukacsos, mint a sajt, foglalt és szabad területek váltogatják egymást. Ha ezt össze tudjuk gereblyézni úgy hogy a foglalt területek egymás után legyenek, utána a szabad területek szintén egy blokkban, akkor nyertünk

A Java Garbage Collector implementációja pontosan ezt tudja: az objektumokat a heap elejére tudja söpörni a GC futása után. Olyan a Java memória modellje, hogy lehetőség van az ojjektumok mozgatására a program futása közben. Ez egyébként egy nagyon fontos aspektusa a rendszernek, amit szerintem a Rust nem tud lemásolni, de Rust szakértőknek kellene erre válaszolni. Ezzel a feature-rel elvben egy Java program tetszőlegesen komplex fogalások és felszabadítások után is végtelen sokáig stabilan működhet, nem "öregszik" a processz semmitől.

C vagy C++ alatt ez szerintem lehetetlen.

A memória menedzser azért nem jó erre, mert annak fix méretű blokkjai vannak, nem tud morzsákkal bánni. Arra viszont képes, hogy amit régóta nem piszkált a program - például egy teljesen használatlan lap, azt ki tudja tenni swapba. De ha a program nem nullázza ki aktívan a nem használt memória tartományokat, akkor teljesen kidobni nem tudja, csak swappelni ugye. Ha a program aktívan nullázza a lapokat, akkor a memória menedzser teljesen ki is tudja dobni ezeket.

Szerintem a memória menedzser virtuális cím-> fizikai cím leképzése nem lehet akármennyire komplex, mert az lassít dolgokat de ebben nem vagyok biztos.

No és mi lenne akkor -- csak egy gondolatkísérlet --, ha a memória menedzser programozható lenne (!), és akár az eltérő méretű memória területekkel is tudna érdemben foglalkozni?

Programozható lenne abban az értelemben, hogy adott alkalmazáshoz, vagy alkalmazási területhez lehetne hangolni, vagy esetleg ezt adaptív módon tudná.

"Share what you know. Learn what you don't."

Van Garbage Collector interfész, implementálhatsz saját GC-t bármikor.

https://openjdk.org/jeps/304

Eleve most is több GC implementáció közül választhatsz, más és más karakterisztikákkal rendelkeznek, amelyek közül kiválaszthatod, melyik illik a te programod profiljába.

Az MMU nagyon kicsi reakcióidővel kell hogy működjön, ugye minden memória művelet előtt ott van. Ráadásul áramot is fogyasztana, ha túl sokat dolgozna. Szóval szerintem ez nagyon necces lenne. Ráadásul drága is kísérletezni vele, mert a CPU-ba kell beletenni.

Szerintem a fejlődés ésszerű iránya az volna, ha minden szoftver valamilyen "virtualizált nyelven" íródna, ami alatt azt értem, hogy a nyelv önmagában garantálja a memória biztonságot, lásd: Java, Rust, stb, és az ilyen nyelven írt programok esetén a memória menedzser oprendszer szinten szoftveressé válhatna, és kikerülhetne a CPU-ból.

Valahogy a tapasztalat ellentmondani látszik ennek. Vegyük például ezt a java virtual machine-ben futó Microchip Mplab-X IDE nevű szörnyűséget. Fedora 36-on működött, néha az induláskor volt olyan folyamat, ami beragadt, ekkor egy jól irányzott SIGTERM majd újra futtatás megoldotta. De ha már ment, nem döglött meg.

Frissítettem Fedora 37-re tegnap. Elindul az Mplab-X IDE, majd néhány perc elteltével olyan szinten fagy szét, hogy kurzor nem villog, az ablakok fölött mindenhol text kurzora van az egérnek, ablakot bezárni nem lehet, semmire sem reagál. Közben a gép teljesen stabil, zenét hallgatok, minden működik, küldöm is a SIGTERM-et, így be tudom zárni. Mindezt úgy, hogy a Microchip épp a problémák elkerülése végett saját java runtime environment-et szállít, tehát az nem cserélődött le.

Mindeközben újratelepítettem az Mplab-ot, természetesen nem segített. Töröltem a saját adatkönyvtárát, ha úgy tetszik, default profilt hozott létre, a jelenség ugyanaz.

Mert java. Ez ilyen. Nincs kontroll csoport, de egy C-ben megírt és lefordított program jellemzően működne. Vagy hát de, van. Az egész oprendszer az alkalmazásaival vígan megy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sajnos neked hiába magyarázzuk, hogy ennek nem a Java az oka, hanem az hogy maga a program szar. De itt nem is konkrétan a Java-ról van szó, hanem arról hogy a menedzselt memória alapelv működőképes-e, és igen, az. Valóban lehet olyan programot írni vele, ami random foglal és felszabadít memóriát és ahelyett, hogy öregedne a heap és egyre töredezettebb lenne, minden GC után friss üde és fiatalos és a processz korát csak a teljesítmény-számlálói mondják meg.

De nem kell feltétlenül Java szintű dologra gondolni, például ismereteim szerint a WASM (WebAssembly vagy mi a neve) olyan, hogy C-ben írt programokat is tud futtatni, mégis memória biztos a futtatása. Sajnos pontosan nem tudom hogy hogyan működik belül, de egy projektemet már portoltam rá poénból, és tök jól működik.

Az elv tehát, hogy hardver helyett a szoftver vigyáz a memória határok betartására, az működőképes, és véleményem szerint egyáltalán nem elvetendő mint kísérleti irány a jövőre nézve.

Ez egy hasonló elv volna, mint amit az Itanium-mal csináltak. Ott azt tervezték, hogy az utasítások párhuzamosítását nem dinamikusan a CPU oldja meg, hanem a fordító explicit végrehajtási tervet csinál. Így a végrehajtó processzor sokkal egyszerűbb, de mégis van párhuzamosítás. (Nagyjából címszavakban ismerem csak ezt a projektet, de az elv tetszik.) Ehhez hasonló volna, hogy az MMU-t kiegyszerűsítjük úgy, hogy az oprendszer csinálja meg ezt a feladatot és csupa olyan szoftvert futtat, ami képes inherensen betartani a memóriabiztonságot. Az is lehet, hogy hülye ötlet, de kísérletképpen érdemes volna elgondolkodni rajta, mert ami funkció a processzorban az fogyaszt is meg lassít is.

Pedig én úgy értelmeztem, hogy azért kardoskodtok itt néhányan a Java, C# és egyéb borzalmak mellett, mert ezekben jó programokat lehet írni. Ha sikerült olyan dolgot írni, ami spontán meg tud fagyni attól, hogy alatta minimálisan megváltozott az oprendszer, akkor szerintem ott baj van. És nem a C-vel és nem is az assembly-vel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem az kell, hogy az Mplab-X működjön. De már megvagyok vele.

  1. Adva van egy Fedora 37 host 32 GiB RAM-mal, 8 magos CPU-val
  2. Felhúztam rá QEMU/KVM-be egy Fedora 36 guest-et, adtam neki 70 GB SSD-t, 16 GiB RAM-ot, 6 CPU magot
  3. Megcsiáltam, hogy a guest felcsatolja a host /home/locsemege alkönyvtárát virtiofs segítségével automatikusan
  4. Feltelepítettem az MplabX-IDE környezetet, az XC8, XC16 és XC32 compiler-eket, ez utóbbiból kettőt is, ennek oka van
  5. Csináltam symlinket a virtiofs csatolási pontjára, semmi kedvem rakás alkönyvtáron átvergődnöm mindig
  6. Megnyitottam a releváns projectjeimet, beállítottam a fontokat olyanra, hogy ne essen ki a szemem
  7. Csináltam egy build-et, hiba nélkül történt mindez

Örülök, és nem érdekel, hogy ez java-s, netbeans-es xar miért nem működik a frissebb oprendszer alatt. Virtuális gépben fogom használni, a file-ok viszont on the fly a host-on kerülnek módosításra. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tegyük fel, kidebugolom. És akkor? Jó, tudom, írhatnék valami könyörgést a fejlesztőknek. Nem ér nekem annyit, rövid az élet, s most úgy tűnik, igen könnyen nagyon rövid is lehet. Maradok a virtuális géppel megoldott, hibátlanul működő workaround-nál. Használni szeretném, nem mások munkáját elvégezni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy ismerosomnel valamilyen Windowson az volt a baja, hogy a Java GUI-ja es a videokartya driver akadt ossze. Mindig amikor a tooltipet megjelenitette (mert egy gomb fole vitte az egeret), elszallt. Az a baj, hogy a Microchipnel meg annyira sem tudnak programozni, mint a masik, hirhedtebb Micro-val kezdodo cegnel (uzletileg viszont sikeresek, kar, hogy ok vettek meg az Atmelt, es nem forditva).

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

Fedora legújabb verziói mindig is alfa verziók voltak. Érthető, mert user-ekkel tesztelnek és ez a RH homokozója. A csomagok pedig gyorsabban ugranak verziót és így az esély nagy az eltörésre.

Nem lehet hogy neked inkább stabil OS verzió ág kellene, ha ennyire fontos az időd? Értem hogy friss verziókat szeretnél stabilitás mellett, de ez a kettő nem megy együtt, ezt be kell látnia mindenkinek.

A szoftverek minden új verziójánál logaritmikusan kezd el növekedni a stabilitás. Minden új kiadásnál. Minden egyes csomag esetén. Vagy fordítva nézve, az időben megtalálható bug-ok száma egy hiperbola görbe alapján csökken, ami gyorsan belassul erősen, ezért elképesztő gyorsan megnő a szükséges idő a következő bug megtalálásához. Most ezt képzeld el az összes szoftver komponens esetén. Ráadásul azoknál is újra indulhat a hiperbolikus görbe, amelyek nem ugrottak verziót, mert a hozzájuk kapcsolódó új verzió mégis módosíthat környezetet és működést.

Nem így látom, a Fedora kódja jó minőségű, stabil a rendszer. Ez a third party vacak és a legújabb Fedora inkompatibilisek egymással, eltört az egész. Ezen az sem fog segíteni, ha fél évvel később frissítettem volna Fedora 37-re, amikor már akár Fedora 38-ra frissíthetnék. Tehát mindaddig kénytelen leszek virtuális gépben futó Fedora 36-on futtatni az Mplab X IDE v6.00-t, amíg ez utóbbiból nem jön újabb verzió, és akkor is kérdés, hogy az új változat stabilan fut-e majd az éppen aktuális Fedorán, meg majd az annál frissebbeken.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nyilván nem, mert a Fedora 37 csak október vége felé fog megjelenni, azaz hivatalosan még nem is létezik. Ezen felül hivatalosan Ubuntu 18.04-re mondják, hogy azon megy, továbbá

MPLAB X IDE may run on the various other Linux distributions.

Külön izgalmas ez a mondat:

MPLAB X IDE does not support Virtual Machines.

Egyrészt, honnan tudná, hacsak nem tesznek szándékosan ellene, másrészt a workaround-om éppen virtuális gépben való futtatása, csak olyan virtualizált oprendszer legyen alatta, amelyen bizonyítottan jól megy.

Nem küldtem bugreportot, inkább csináltam workaround-ot. Most megy jól virtuális gépben. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tehát _nem_ támogatott a környezet, illetve a "may run"pontos értelmezésével is gond van nálad... Az, hogy VM-en való futtatás nem támogatott, az lehet technológiai vagy "üzleti" jellegű döntés következménye, nem biztos, hogy lehet, illetve kell tudni. (jellemzően ahol hardverhez közeli dolgokra van szükség, ott a virtuál izélt gépeket inkább nem támogatják hivatalosan, mert lehetnek olyan problémák, amiket nem vagy csak extra nehézségek árán lehet megoldani adott virtualizáció esetén.)

Még szép, hogy nem küldtél bugreportot, hiszen nem támogatott környezetben hasalt el a motyó...

Jaj, a hardware vezérlés eszembe sem jutott, jó, hogy mondod! Van QEMU/KVM-re elvileg transzparens USB bridge, de ki tudja, menne-e. Erre a műszerre írtam boot loader-t, illetve USB-n firmware letöltő eszközt, viszont abban igazad van, hogy ha módosítani szeretnék a boot loader-en, akkor a programozó hardware-nek is működnie kell, azt meg nem teszteltem. Továbbá frissen gyártott, de még prototípus nyákoknak is le kell valahogy tölteni a boot loader-t. Utána már nem gond, a boot loader-t használva USB-n kód letöltésre írtam C-ben klienst Linuxra, kollégám C#-ban Windowsra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"may run"pontos értelmezésével is gond van nálad

Nem hinném. Az azt jelenti, nem tesztelték, vagy megy, vagy nem, ha szerencsém van, akár még menni is fog. Mondom, Fedora 36-on megy, Fedora 37-en megdöglik, miközben minden egyéb software beton stabil Fedora 37-en. Ne mentegessük már, ez továbbra is csak egy java-s sz.r, mint amilyenek a nem natívan írt programok többsége.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valószínűleg túl új valami, amire nem készültek fel a fejlesztők, mert nem tudták, hogy fel kell rá készülniük. Nem láttak a jövőbe. Ugyanakkor szerintem ha valamit szépen kódolnak, ebből nem lesz baj.

Azért használom, mert munkaeszköz, nincs más. Van áramkör és nyáktervező, néha szidom, mint a bokrot, de nyilván jobb, mint papíron ceruzával csinálni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na, néztem ezt az átkot. Jelenleg az a sejtésem, hogy a problémát az okozza, hogy a Fedora 36-ban 4.0.0-s, míg a Fedora 37-ben 5.2.0-s a harfbuzz nevű valami, s úgy tűnik, ez a csoda a régivel kompatibilis. Fene tudja, hogy maga a jre, vagy az afölé írt förmedvény.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a jóképességű MPLAB, ami akárhogy is nézzük, egy text editor némi syntax highlighttal, meg benne fordító és linker, szóval amikor csak úgy megdöglik induláskor, akkor laza 38.8 GB virtuális memóriát foglalt. Közben a program alig néhány tízezer kódsor, legfeljebb százezres nagyságrend, alig több a forrás 5 MB-nál. Szerintem az egészet le lehetne tudni alig pár megabyte-ból tokkal-vonóval, még a 100 MB közelébe se kellene menni memóriafoglalásban akkor sem, ha az egész forráskód összes file-ját berántja RAM-ba.

Nyilván valami csinos memory leak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az MMU nagyon kicsi reakcióidővel kell hogy működjön, ugye minden memória művelet előtt ott van.

Azert ez nem teljesen igy van - vagyis pontosan igy van, attol fugg honnan nezzuk :) Azaz: ha van egy cimzesed, es feloldhato a fizikai cim, akkor nem lesz semmivel sem lassabb mint egy MMU nelkuli rendszer. Ha pedig nem oldhato fel, akkor a CPU/MMU general egy kivetelt. Ezt az oprendszer elkapja es megprobalja lerendezni a dolgot (pl alalapoz fizikai memoriat, visszaolvassa a swap-bol, barmi). Ha sikerul, akkor jo, ha nem, akkor meg jon a segmentation fault. Nyilvan ez csak egy egyszerusitett kep, mert van meg DMA is meg egyeb hasonlo nyalanksag (de az tisztan oprendszer oldalon van), plusz a memoria-eleresnek is tobb modja lehet (read, write, execute), de az alapelv az ez: a cimbuszra kimegy a request (address + alignment + access mode) , az MMU-n atfolyik, par ciklussal kesobb pedig visszajon amit kert (addig meg ugye wait cycle-t kap vissza a CPU). Vagy megy a megszakitas a CPU-nak. 

Szerintem a fejlődés ésszerű iránya az volna, ha minden szoftver valamilyen "virtualizált nyelven" íródna

Na, viszont a fentiek tukreben pont ez lesz baromira lassu ;) Ha minden i/o access elott meg egy komplett MMU lookupot is le kellene szimulalnod szoftverbol, es nincs hozza offload hardvered. Es ezek tipikusan olyan dolgok amiket cel-hardverbol sokkal gyorsabban lehet tolni mint szoftverbol (lasd pl bitmuveletes dolgok meg popcount meg finite field muveletek meg hasonlo operaciok, nem veletlenul jelentek meg instruction set tamogatassal a crypto utasitasok is eleg hamar).

> ha van egy cimzesed, es feloldhato a fizikai cim, akkor nem lesz semmivel sem lassabb mint egy MMU nelkuli rendszer.

Azért a feloldást csak megcsinálja valami. Az pedig idő kell legyen, illetve áramot kell hogy fogyasszon. Lehet, hogy nem okoz beszúródó plusz órajelet, de az órajelnek több idő kell miatta. Nehéz elképzelnem, hogy MMU nélkül ne lehetne gyorsabb a rendszer. Esetleg úgy állhat ilyen elő, ha más kötelező funkció is van, ami miatt úgyis szükség van az időre.

Ha belegondolsz, ha menedzselt lenne minden program úgy, hogy kizárt lenne az illegális címzés, akkor a program és az oprendszer közötti határvonalat is el lehetne vékonyítani. Amiről tudvalévő, hogy rendkívül költséges. Szóval több féle oka is lehetne annak, hogy egy ilyen fajta rendszerrel kísérletezzünk.

> Ha minden i/o access elott meg egy komplett MMU lookupot is le kellene szimulalnod szoftverbol, es nincs hozza offload hardvered.

De nem is volna szükség MMU lookupra, ha minden adat úgy volna tárolva mint egy Java heap, amit lehet menet közben tömören tartani, és ráadásul az egész oprendszer és minden ami rajta fut egyetlen egy nagy heap lenne. Nem azt mondom, hogy meg kellene valósítani szoftveresen, hanem azt, hogy az egész feleslegessé válna.

> Es ezek tipikusan olyan dolgok amiket cel-hardverbol sokkal gyorsabban lehet tolni mint szoftverbol

Persze, és ha kiderül, hogy a felvázolt utam járható, de speciális utasításokat igényelne, akkor azt meg lehet valósítani hozzá. Persze ha a végén a speciális utasításkészlet pont egy MMU-t ad ki, akkor az egésznek nem volt semmi értelme :-) (Régen gondolkodtam ilyesmin, de éppen arra jutottam, hogy ezen az úton a GC-hez, illetve az objektumok mozgatásához kellene nagyon egyszerű HW támogatást csinálni, ami lehetővé tenné, hogy leállás és performance penalty nélkül lehessem az ojjektumokat mozgatni.)

Memoria allokacio nagyon oszettett, igen is meg nem is ;-)
Nagyon kicsi memori reszeket maskep kezeljuk mint, a nagyokat.
A kicsikbol kb felebol lehet nem hasznalhato lyuk.
A nagyobakat ugy foglaljuk, hogy az OS -el szedetunk ossze megfeleo meretu memoriat, szoval ott kb ugy megy ahogy leirtad.

Kicsikhez terulet brk(2) val foglalodik,
nem szokas vissza adni teruletet az OS -nek.
Tipukusan 2 hatvanyai blobkokra lesz felosztva.
Nagyokan mmap(<anon>) -al foglaljuk, felszabadaitaskor visza lehet adni az OS -nek.

A memoria foglalas tipikusan ~4 algo oszegyurasabol van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Itt egy elég hosszú cikk a témában:

https://www.softwareverify.com/blog/memory-fragmentation-your-worst-nig…

Firefox kapcsolódó téma:

https://www.computerworld.com/article/2539992/fix-firefox-s-memory-prob…

Custom memory allocator amire a firefox is váltott:

https://jemalloc.net/

Ilyenkor én azért elgondolkodok, hogy egy Firefox esetében, ahol száz milliós felhasználóbázis, és 700+ fejlesztő van, mennyi időbe tellett megoldani vagy valamilyen szinten kezelni a memória fragmentációt, akkor miért gondoljuk, hogy ezt egy átlag cég jól meg tudja oldani.

Nem tudok róla, hogy a Linux kernel csinál-e ilyen trükköt és milyen esetben. Szerintem ha igen, akkor is csak nagyobb összefüggő területen lehet csak érdekes (mekkora mérettől?). Néhány 4k méretű lapért jobban megéri a RAM-RAM DMA másolás, mintsem az MMU továbbtöredezése. Ugyanis az MMU véges fragmentálhatósága is ott van, mint kernelbeli probléma. Ezt pedig éppen a RAM-RAM DMA-zós töredezettség mentesítő háttérfolyamattal orvosolják, ami pont az ellentéte a felvetésben foglaltnak. Lásd:
     https://www.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-1/
     https://www.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-2/

És hogy a Rust allokátoráról is írjak: hibrid allokátorral dolgozik. Van a kerneltől RAM kuncsorgás, de a processzen belül is megy a mit melyik rész használ és mit adott vissza belső adminisztráció.
Ami érdekes, hogy a vektor mérete ha kevés a feladatra, akkor alapértelmezetten duplázó allokálással dolgozik (példa) és az inicializáló allokációméretet ha akarod, akkor megadhatod.

Már elnézés, de az operációs rendszernek nem az erőforrások (pl. hw) optimális elosztása, illetve kezelése az egyik feladata?

Ebben nem tartozik bele az alkalmazások által igényelt erőforrások kezelése?

Vagy csak én tudom rosszul, hogy mi is lenne az operációs rendszer feladata?

(Tanítsatok mesterek, tanulni szeretnék!)

"Share what you know. Learn what you don't."

Jelenleg úgy működik, hogy az alkalmazás kér egy címtartományt, ami alá a használat során felsorakozik a fizikai RAM. Az oprendszer kiteheti Swapba a lapokat saját belátása szerint, illetve ha egy lap csupa nulla, akkor talán törölheti a RAM mappinget. Kb ennyi az interakció.

Hogy locsemege pontosan mit szeretne, az számomra nem teljesen világos. Szerintem azt szeretné, ha a töredezett heap-et tudná az oprendszer tömöríteni, de ez fából vaskarika, mert a heapen belül a malloc osztja a memóriát, ami nem az oprendszer, hanem az alkalmazás része, ráadásul a legtöbb futtatási környezet nem engedi meg a lefoglalt változók címének megváltoztatását (ahogy írtam a Java például meg tudja csinálni ezt), tehát a címtartományt semmiképpen sem lehet tömöríteni. A legtöbb amit lehetne, hogy ha egy teljes lap kijön amin egyetlen változó sincsen használva, akkor azt kitehetné a RAM-ból az oprendszer. Ehhez ez kellene, hogy ami felszabadul az ki lenne nullázva. Swapra anélkül is kikerülhet, és ez meg is történik a lap-használati számlálók alapján.

Nemrégiben futottunk bele c++ alatt egy csúnya heap poisoning problémába: Microsoft+Windows implementáció alatt egy nagyobb szoftvernél olyan helyzet alakult ki, hogy annyira töredezett lett a memória, hogy minden azutáni malloc kb 2-5 ször annyi időt kezdett igénybe venni, mint korábban. 

Ezt akkor is csinált, ha garantáltan fel lett szabadítva minden korábbi memória.

Egyetlen megoldás maradt: csináltunk egy másik heap-et, amiben a sokat allokáló számoló függvény garázdálkodhatott, a szokásos heap-et meg használta a program többi része.

Na egy ilyen nyomozás és javítás c++ -ban kb 2 emberhónap volt - ezért szeressük ;) ja nem.

A másik kedvenc megoldásom az alrendszerek külön processzbe költöztetése és szükség szerinti újraindítása úgy, hogy a főprogram közben meg se rezzenjen. Nice.

Hogy lehet egyébként heapet váltani egy könyvtárhoz? Csinálsz egy előtét malloc-ot amit preloaddal betöltesz és teszel rá egy mechanizmust, hogy kapcsolgatni lehessen honnan foglaljon, és minden átjáráskor a lib és a főprogram között váltasz?

ha megvan a c++ forrásod, akkor tudsz kényelmesen ilyet csinálni: az STL alapű konténerek saját allokátort engednek megadni.

Saját allokátort kb triviális megírni, ami mondjuk az oprendszertől kér egy új OS heap területet, majd allokátor hívás -> OS heap hívás mappet csinál.

A fő probléma a probléma kidebuggolása volt.

Nemrégiben találkoztunk a Visual Studioba beépülő ingyenes Microsoft-os Concurrency Visualizer-el, az nagyon jó lett volna ehhez, szuper kis tool.

A gondot az is okozta, hogy régi motoros kollegák gondolták, hogy "itt van 300 számolás, indítok rá 300 threadet" WOT? és tényleg megtörtént.

Ha mondjuk egy sima thread poolt használtak volna (vagy cpptaskflow libet), ez se lett volna.

nézd, ezt kérem leimplementálni C-ben:

std::unordered_map<std::string, std::shared_ptr<Data>> cache;

void AddToCache(std::string dataId, std::shared_ptr<Data> data)
{
  cache[dataId] = data;
}

std::shared_ptr<Data> GetFromCache(std::string dataId)
{
  auto it = cache.find(dataId);
  return it == cache.end() ? {} : it->second;
}

void ClearCache()
{
  cache.clear();
}

Ez ugye egy tetszőleges hosszúságú string kulccsal címezhető O(1) keresési idejű cache implementáció, ami gondosan ügyel a belerakott objektumok élettartamára is (kizárt a memory leak vagy a use after free még akkor is, ha a cache-t kitörlik, miközben valaki használja az ojjektumot).

Nahát ezért használunk magas szintű nyelveket, hogy ne kelljen a triviálissal foglalkozni, hanem a lényegi algoritmusra koncentrálni.
Vagy itt van a következő, ami párhuzamosan lefuttat 4 számolást 4 thread-en.

tf::Executor exec;
tf::Taskflow tasks;

tasks.emplace(
    [] { compute1(); },
    [] { compute2(); },
    [] { compute3(); },
    [] { compute4(); },
  );                                  
                                      
exec.run(tasks).wait();

Ez pontosan ennyi, semmi további kódra nincs szükség, teljesítmény veszteség < 1ms a legnatívabb kézi megoldáshoz képest.

Mivel dolgoztam beágy környezetben is, sokat szenvedtem a régi motorosok szemléletétől, akik ragaszkodtak a C-hez, de minek? A legtöbb helyen eljárt felette az idő.

ugye megvan, hogy ez thread (hideg)indításról szólt, ami rendkívül drága, nem pedig egyszerű számolásról?

// tipikusan azt szoktam látni beágy embereknél, hogy a C bonyolultsága miatt pl. maradnak az adatokban a lineáris keresésnél, így olyan lassú kódjuk lesz, mint a tetű, de cserébe büszkék lesznek rá.

Én is írtam assemblyben sokmindent, űreszközben is járt kódom, nem erről van szó, hanem hogy alacsony szintű nyelvben nagy projektek fenntarthatatlanok, iszonyatos pénzpocsékolás.

A példád a bináris keresés volt, ami O(log2N), szemben azzal amit mutattam, de a lényeg: nem kell újra és újra megírni, pl saját C-s adattípusra customizálni minden egyes feladatnál, hanem csak c++-ban használod a template-t, és a fordító pontosan a kurrens adattípushoz igazítva választja ki az optimális gépi kódot, nem neked kell vele napokat szöszmötölni.

A termék teljes életciklusára vetítve is vagy 2 nagyságrenddel olcsóbb.

űreszközben is járt kódom

Ha nem titok, miben? :)

A példád a bináris keresés volt, ami O(log2N), szemben azzal amit mutattam

őőő... van O(1)-es keresés is? A hash az vegulis lehetne az, ha valahogy garantalod hogy a hash az egyedi. De ha nem es/vagy kicsi es/vagy nem akarjuk hogy az egye meg a memoriat, akkor az mar nem lesz (annyira) jo. 
 

A hasht úgy keresed, hogy az valójában a cím :) szóval a hashmapben a lookup egészen addig, amíg nincs ütközés O(1) (meg az insert és a delete is egyébként). A worst case scenario általában O(m) (ugye ha gyak minden érték hashe ütközik, és gyakorlatilag linárisan végig kell keresni az összes kulcsot). Olyan nyelveken, amik adnak ilyesmi adatstruktúrát maguktól, a hashfüggvény és az implementáció úgy van megválasztva, hogy az esetek jelentős részében az ütközések száma elhanyagolható a gyakorlatban. Ha erre valóban szükség van, akkor vannak módszerek arra, hogy a worst case is O(1) legyen, pl cookoo hashing. Természetesen ezek egyébként azzal járnak, hogy ugyan minden O(1), de a konkrét költség drágább, mint az best case O(1) a "sima" esetekben. Illetve ha jól rémlik, ezeknek a tárolási költsége is magasabb, szóval ilyesmit akkor van értelme csinálni, ha tényleg szükség van arra, hogy mindenképp konstans time legyen a lookup.

Az elmélet az, hogy ha a hash jó minőségű, akkor egyenletesen szétszórja az ojjektumokat az adatszerkezetben. A hash mérete fix, az ezzel való címzés konstans idejű műveletnek tekinthető, innen jön az O(1) keresési idő. Ha minden stimmel, akkor valóban igaz lehet.

 

Szerk.: valójában az ordó arról szól, hogy a problémaméret növelésével hogyan skálázódik a megoldás végrehajtási ideje (lépésszáma). Mivel nagyobb problémamérethez egy idő után nagyobb hash is kell, végül logn lesz a skálázódása az algoritmusnak, és még akkor is meg marad az elvi lehetőség, hogy az ütközések elrontják. Mégis praktukusan O(1)-nek szokás számolni praktikus méretű rendszerekben, mert olyan mintha az lenne.

Igen, igazad van. A fentebbi topichoz: lényeg, hogy nem lehet konstans lépésű keresés, ez belátható azzal, hogy változó számú elemről beszélünk egy általános keresési problémánál. Ott pedig nem elégséges a konstans lépés soha, mert mindig növelhető az elemek száma annyira, hogy a lépés szám ne lehessen elég.

Igazából de, ha a világ összes memóriája a rendelkezésedre áll, akkor de, csak kell egy konstans lépésszámú 1->1 adat -> cím összerendelés*. Ez nyilván nem lesz igaz, de egyébként ebből az is következik, hogy nem tudod az elemszámot sem a végtelenségig növelni, szóval lesznek a függvényednek valamilyen praktikus értéktartományai.

* és persze ha az adat méretének sincs felső korlátja, akkor megérkezünk a diszkrét matematika csodálatos tájaira

Meg is válaszoltad, hogy miért nem igazán jó amit mondasz, mert gyakorlatban nincs végtelen.

De ha megengedjük, akkor sem áll, azért amit feljebb írtam. Konstans lépésszámról beszéltél, ami azt jelenti, hogy nem változik, független az adat mennyiségétől. Te ezt az "összerendeléssel" oldanád meg, mely gyakorlatilag egy előre beindexelés. Tehát sorba rendezett adatról beszélünk végtelen memória mellett, ahol maga a kereső szó eleve a keresett adat indexére mutat.

De ezt az összeállítást már el kellett valakinek végezni, ami meg nincs konstans lépésszámból.

Tehát el kell dönteni, hogy olyanról vitatkozzunk-e, ahol először megengedünk konstans lépésszámnál nagyobbat, hogy aztán csak konstans lépés kelljen, vagy ez nem megengedett.

Biztos jó ez az intellektuális önkielégítés, csak a gyakorlatban semmi értelme, mert a felhasználások nagyon nagy részében elég lesz az az O(1), amit annak mond az adott adattípus, funkció készítője. Ha mer ilyet mondani, akkor nagy valószínűséggel ilyenre is tervezte azt a dolgot. :)

Extrém esetekben lehet sajátot vagy optimalizált megoldást keresni, meg lehet próbálkozni a gperf-el és hasonló eszközökkel is.

Nem haragudj, de nem érted.

1. Mivel a gyakorlatban nincs végtelen, ezért az általad felvetett változó számú input sem tud a végtelenségig növekedni, tehát lesznek keretei a megoldás skálázódásának, és a konkrét mérnöki gyakorlatban arra használjuk az ordót, hogy ezeken belül tudjuk belátni egy megoldás erőforrás skálázódását. Ha nem ezt tesszük, hanem maradunk az elméleti síknál matekozva, akkor bizony belefér, hogy végtelen elemszámnál is O(1), végtelen mennyiségű memóriaigénnyel (vagy végtelen*végtelen méretűvel, ha az elemméret is végtelen). Ez ilyen, nincs itt semmi látnivaló, belefér, tudjuk, hogyan kell végteleneket egymással hasonlítani.

2. Nincs gyakorlatilag előre beindexelés. Egy olyan függvényre van szükség, ami képes 1->1 összerendelést csinálni adat, és cím között, vagyis a minden konkrét adathoz pontosan egy cím tartozzon, és viszont. Ezt pedig a konkrét adattal a konkrét művelet elvégzésekor kell futtatni, nem előre.

Egy olyan függvényre van szükség, ami képes 1->1 összerendelést csinálni adat, és cím között, vagyis a minden konkrét adathoz pontosan egy cím tartozzon, és viszont

Hat, a jo hash fuggvenynek pont az a tulajdonsaga hogy ezt nehez, vagyis nem lehet vele megcsinalni. Tegyuk fel hogy van ~250 adatod amit le akarsz tarolni. Raeresztesz minden adatra egy 8-bites hash fuggvenyt. Szerinted hany egyedi lesz kozte es hany ismetoldo? :) Avagy ha meg ezt az 1<->1 megfeleltest is megkovetelned, akkor a birthday paradoxon miatt meg az egyebkent se tul optimalis memory footprintje a cuccnak megrosszabb lesz - azaz O(N^2)-tel mar kb jok vagyunk, de meg ott is lesz am utkozes! (Most igy kiprobaltam, 250 random adatra 16 bites hash-eket raengedve is kb 50% a valoszinusege hogy egy utkozes! Es ha valakinek azt mondod hogy ~250 adat jo beindexelesehez neked ~65536 meretu memoria kell, akkor korberohognek).

Annyira cukik vagytok, mikor teljesen hülyének néztek :) Persze, hogy ebben az esetben minden más katasztrofálisan fos lesz, minél több a "szabad gyök", annál inkább. Az a függvény azt jelenti, hogy az valójában nem is hash, hanem csak egy értékkészlet mappelés adat és memória cím között. Practice teljesen értelmetlen, mindössze arra a felvetésre reagáltam, hogy a változó mennyiségű adatot nem lehet O(1) számítási költség skálázódással elővenni elméletben ("nem lehet konstans lépésű keresés, ez belátható azzal, hogy változó számú elemről beszélünk egy általános keresési problémánál."). De, lehet. Nyilván mindenhol máshol ára van, és a fene se csinál ilyet a gyakorlatban.

Ajánlott olvasmány az érdeklődőknek:
https://preshing.com/20110504/hash-collision-probabilities/

Ajánlott általános, szuper egyszerűen használható lib: khash, róla cikk:
https://attractivechaos.wordpress.com/2018/01/13/revisiting-hash-table-…

Szerintem a khash-nek megvan a pure C változata is, hallod, locsemege?
http://attractivechaos.github.io/klib/#Khash%3A%20generic%20hash%20table

( hajbazer v | 2022. 09. 30., p – 14:35 )

Szerkesztve: 2022. 09. 30., p – 14:41

Kellett nagyon az a 😲, mint egy falat kenyér, nehogy véletlenül magasan vezethessen a "Nem értek egyet!".

Ami szomorúbb, hogy az egész világ újraírása Rustban, még az új nyelv képességeit figyelembe véve is silányabb végeredményhez fog vezetni, mert a 20-30 éve jól bevált C/C++ libeket még programozók írták és az idő próbáját is kiállták. Az új™ Rust-osított világot pedig koffein-kód konverziós babzsákfejlesztők fogják.

Emellett felkészülhetünk lassan a programnyelvek ellen indított FUD-propagandahadjáratokra, amik mögé majd felsorakoznak szépen azok a tech-óriások, akik az újraírkálás nyertesei lesznek, mert lesz jópár hardver, amihez, akármilyen menő™ is a Rust, nem lesz driver írva és azt bizony újra kell vásárolni. Majd amikor már csak abban lehet drivert írni, és ha valaki C-ben szeretne "elment az eszed? jönnek a hekkerek és..." FUD FUD FUD FUD FUD... Eljutunk majd oda is, amikor már a C-ben írt alkalmazások nem kapnak digitális aláírást, amivel futtatni lehet őket. Persze, először, csak felvillan 25x a nagy piros felirat, hogy "nem biztonságos". Valamennyi évtizedek óta jól működő megoldás alternatíva nélkül marad.

Ezek már amolyan csepp a tengerbe. Most ott tartunk, hogy nem csak soft eszközökkel, hanem akár erőszakkal is elveszik a szabadságunk. Eddig ajánlott volt az igazodás, hamarosan viszont agyonverik azt, aki nem igazodik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miért kellene mindent újraírni? A történelem során volt, amikor az igazi programozó Fortranban dolgozott. Ma, sok-sok évtizeddel később is rengeteg matematikai szimuláció motorja még mindig Fortranból fordul hozzá a ma használt modern nyelvhez.

Rust is szépen egybefordítható más nyelven írt kódbázissal. Eleve a Firefox, amely első teszt terepe volt a Rust-nak, szintén hibrid nyelven van és egy közös bináris lesz a végeredmény. Linux kernel szintén C-Rust hibrid lesz.

rust mar parban van C++ -el teljesitmenyben, C-t meg nem verte meg.
FORTAN-t C sem igazan verte meg a teruleten, elvileg sok fordito specifikus hintel meg tudna.
rust memoria kezelese elvileg segithat abban hogy megverje FORTANT hintek nelkul is,
de kerdes nem-e adott hoza valami mas problemat.
10 ev mulva megtudjuk ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

C-nél NEM lesz gyorsabb a Rust. Miért?
Eleve azért nem lehet, mert amíg a C-ben azt mondod, hogy "á ezt felesleges ellenőrizni, mert úgysem nyúlok túl" (aztán egy későbbi átfejlesztéskor mégis sikerül --> kész a biztonsági rés), addig a Rust kivétel nélkül minden memóriahozzáférést ellenőriz. Amit tud fordításidőben igazolni, hogy nem lehet probléma, azt ott teszi. Amit pedig nem tud igazolni, azt pedig futásidőben ellenőrzi. Ez utóbbi lassulást eredményez.

Gyakorlatban a Rust valahol 5% .. 20% lassulást fog eddigi méréseim alapján jelenteni egy ellenőrzés-szegény C programhoz képest. Ellenben garantál memóriakezelés-biztonságot, továbbá több más biztonságos programozást elősegítő dolgot.

10 ev mulva megtudjuk ;-)

Teljesen így igaz. Ahogy jönnek a komolyabb projektek, úgy fog felszínre jönni az esetleges korlátja is. Aztán kialakul az, hogy milyen esetben érdemes Rust-ban gondolkozni és hova célszerű más programozási nyelvet alkalmazni.
Egyébként a Microsoft 5 év intenzív munka után úgy néz ki, dobta a Checked-C projektet és Rust trükkjeit alapul véve elkezdett egy új nyelvet:
    https://en.wikipedia.org/wiki/Project_Verona
    Family: Rust-like

Kelleni persze nem kell mindent újraírni, de biztos, hogy lesz legalább egy ,,ifjú -- tesztoszterontól átitatott -- titán'', aki szerint -- bár tökéletesen működik valami --, újra kell írni, mert a korábbi verzió pl. C-ben/Pascal-ban/...(-ban/-ben) készült, és ez a helyzet egyszerűen tarthatatlan...

Időnként felmerülnek újabb programozási nyelvek és megoldások, módszertanok, amelyekre úgy tekintenek, hogy ez majd minden korábbi problémát megold.

Aztán pedig az idő bizonyítja az ellenkezőjét, többnyire....

"Share what you know. Learn what you don't."

( kruska v | 2022. 10. 12., sze – 20:06 )

Ritkaság, de van olyan célfeladat, amikor a Go gyorsabb a Rust-nál (legalábbis az adott implementáció esetében):

https://www.scylladb.com/2022/10/12/a-new-scylladb-go-driver-faster-tha…

Kb. 3 évvel ezelőtt saját célra elkezdtem építgetni egy saját REST API backendet egy célfeladatra, és mivel a Pascal/Delphi tudásom is legalább annyira megkopott az utóbbi 20 évben, hogy szinte nulláról kellett volna kezdenem, kerestem egy modernebb nyelvet. Sok minden kiesett, végül Go és Rust maradt, a Go-t választottam. Nem bántam meg, nagyon megszerettem. Hobbista programozó vagyok, pont nekem való.