Rust-ra áll át C-ről és C++-ról szoftvereiben a Microsoft?
2019-07-18T07:53:26+02:00
2019-08-05T17:52:38+02:00
2022-07-20T20:03:18+02:00
  • Hol lehet arról infót találni, hogy a fejlesztői verzióban (nightly build) mit fejlesztgetnek, azaz hónapok múlva milyen feature halom közül várható pár a stable ágban?
    Mutasd a teljes hozzászólást!
  • Ebből a RUSTból nem lesz semmi. Megnéztem, hogy most mit fejleszt(get)nek rajta.

    Leginkább csak (get)nek. Ez még annyira az ötletelés fázisában van, hogy nem szabad semmit sem ráépíteni.

    Azt meg végképp nem szabad elhinni, hogy ebből a Microsoft támogatásával _stabil_ fejlesztőeszköz lesz hamarosan. Legfeljebb azok a szerencsétlenek lesznek a béta teszterek, akik elhiszik az egész halandzsát.

    Ha most ebben újraírják a WIndowst (aminek nincs esélye), akkor olyan bénázás lesz, mint a win8.0-8.1-10 vonalon a részben .NET-ben újraírt kezelő felület, (ezer béta verzióval) ahol három "Add Printer" dialog létezik még mindig, mert az új nem tudta kiváltani a régieket
    Mutasd a teljes hozzászólást!
  • Meg sokat számít szerintem a dokumentáció. Pl. a PIC adatlapok nagyon szépen, érthetően írnak le mindent. Persze találtam már nem egy hibát, de szerintem sokkal érthetőbb mint sok másik. Bár lehet azért, mert ezeket használom 
    Mutasd a teljes hozzászólást!
  • Jah... kiválasztottad az egyik legszutykosabb 32biteset a piacon, és összehasonlítottad egy erősebb 8bitessel.

    Mouser Electronics, Inc. Hungary
    Mouser Electronics, Inc. Hungary

    8bites 94ft/db-tól van 32bites 228ft-nál kezdődik.(ARM 389ft)
    Persze nem kérdés, hogy nem sok helyre elég egy ilyen szutyok proci, de ahova elég, ott jelentős az árrés...
    Mutasd a teljes hozzászólást!
  • Aliexpress árait elnézve
    a 8 bites Atmega328p 10 darabos csomagja 10 dollár körül mozog.
    a 32 bites ARM Cortex M0 mikrovezérlőből 4 dollár körül már kapsz 10 darabot: US $1.97 |5pcs/lot STM32F030K6T6 STM32F030 STM32F 32F030K6T6 IC MCU 32BIT 32KB FLASH 32LQFP In Stock


    Közben lassan lejár a 6 hét és jön az újabb Rust fordító verzió.
    Várható változások: rust-lang/rust
    Mutasd a teljes hozzászólást!
  • 32 bitesnél az assembly járhatatlan. Továbbá el kell fogadni, hogy nem látod át teljes mértékben az alattad lévő program könyvtárakat vagy op.rendszert, rosszabb esetben. 8/16 bitnél, azért legtöbbször után lehet nézni az alsó szintek működésének.
    A normálisabb C/C++ fejlesztő eszközök azonban mindenhol produkálnak assembly kimenetet. Persze az kérdés, hogy mész-e vele valamire.

    [Sikerült már olyan 8 bites C fejlesztő eszköre futnom, ahol mindent láttam, csak a startup kód kapcsolatát nem láttam az objekt modulok mappelésével (STC kontroller, Keil vs. SDCC fordítók).
    Meg is ette a fene, mert nem tudtam a kódot portolni a fordítók között. Perdig láttam az assemblyt...]

    Szóval inkább a kulcs az ismert eszközöz, az (általam) átlátható fejlesztő rendszerek és ezek közöttmegtalálni a költség hatékony megoldást.

    [Az IoT megnevezés pedig a mikrokontroller technika megcsúfolása szerintem. Készítsünk egy pici és hatékony készüléket, majd a keservesen megszerzett adatokat nagy erőfeszítéssel és költséggel küldjük fel egy átláthatatlan és mások által birtokolt felhőbe. Gratulálok!]
    Mutasd a teljes hozzászólást!
  • Feladathoz választunk eszközt. Amennyiben egy 8 bites 8 lábas processzor elég a feladathoz, akkor oda nem rakunk be egy 32 bites mini erőművet..
    Mutasd a teljes hozzászólást!
  • Az az árban olcsóbb meglehetősen nagy bullshit. A valóságban inkább a többszöröse a 32bites, a 8bitesnek.
    Mutasd a teljes hozzászólást!
  • Teljes mértékben egyetértek.
    8 bites mikrovezérlőn GPS koordináta "konverziót" csináltam, szögpercről decimális törtrészre, ami 0.6-al való osztást jelent. Na ezt úgy, hogy nincs hardveres osztó.
    És ez már lehet perverzió, de asm-ben.
    Anno asm-ben kezdtem, kipróbáltam a C-t (többféle fordítóval, sőt IDE-vel is) de rohadtul elegem lett abból, hogy pl. egy fordító frissítés után nem stimmeltek a gyári include fájlok, illetve a korábban elnevezett függvények nevei.. mindig vadászgatni kellett hogy na akkor mi az újnak a neve... stb.
    Bár ez már jópár éve volt, illetve őszintén szólva nem szántam elég időt se rá.
    De volt olyan project, ahol beláttam hogy esélytelen asm-ben felvenni a "versenyt" magasabb szinttel (pl. USB), ott egyértelmű, hogy a C-hez nyúltam (főleg mert ahhoz volt sample :D).
    Ja meg ami nagyon zavar, hogy nem látom mi történik a háttérben. Ha jól emlékszem, talán a MikroElektronika fordítója olyan, hogy a C kód alatt nem látsz semmit, csak rögtön a HEX-et. 
    Ja meg vicces, hogy sokszor gyorsabban lehet haladni asm-ben mint magasabb nyelveken. Illetve az a végtelen hivatkozás.. Van egy fv. ami bekapcsol egy kimenetet. A kimenetek definiálva vannak, hogy mittudomén LED_1. Na mire összeáll a kép, hogy tulajdonképpen mi a bánatot és hogyan is állít a függvény, 86ezer híváson kell átmenni.. Aztán hogy mennyire optimalizálja ki a fordító (gondolok itt a sok stack nyúlkáláshoz), az is jó kérdés.
    Na ez csak egy egy picike agymenés volt, a 8 bites világból, a 32 bitesbe bele se mertem igazán vágni, csak játszottam vele, ott viszont tényleg csak magas szintű nyelveken, az asm ott már erősen felejtős.
    Mutasd a teljes hozzászólást!
  • Mi szól napjainkban még a 8 bites mellett a "hagyományokon" kívül?

    Pontosítva a kérdést: 8 bit --> 8/16/24 bit/DSP egyedi architektúrával.

    Ami mellettük szól az a CÉL. Mit szeretnénk elérni? Mindegyik másra és másra való.

    Nem értek egyet azzal, hogy mindenre a legújabb, legnagyobb, """legjobb"""  (ARM) technikát kell használni. Szerintem mindenre az arra leghatékonyabbat kellene. A többi csak környezetszennyezés.

    - Így egy jól választott 8/16 bites mikrovezérlővel ellátott időjárásfigyelő eszköz elvileg végtelen idejig elmehet passzív energiagyűjtéssel (RF, solar, thermo).
    - Egy zsebámpa villogó elektronikája egyszerűbb egy 8-bites chippel, mint célhardverrel, amit meg kell tervezni.
    - A mosógép vezérléséhez elég a 8 bit, a 32 bit ARM csakis a TFT kijelző és az SSL/TCP/IP kapcsolat kiszolgálásához kell, ami pedig nettó hülyeség,

    Borzasztó vér pisilés megy a "divat mikrokontrollerek" gyártói részéről, hogy bebizonyítsák, hogy minden jobban megy 32 biten. No, eddig nem győztek meg.

    Az igazi előnye a 32-bites ARM-nek, hogy egységes fejlesztőrendszerrel lehet sokféle eszközt kezelni. Ez tény.
    Még akkor is, ha emiatt sok hozzá nem értő kezébe kerülnek az eszközök és szánalmas "DIY"-nek csúfolt próbálkozásokat lehet látni, mint pl. a 32bites Arduino környezet.
    Mutasd a teljes hozzászólást!
  • Pedig a trend az, hogy ma már a 32 bites mikrovezérlő akár 1 MB flash-sel és akár 256 kB RAM-mal nem ördögtől való. Sőt árban ma már egy belépő szintű 32 bites nem ritkán olcsóbb a "történelmi" 8 bitesnél.
    Mi szól napjainkban még a 8 bites mellett a "hagyományokon" kívül?

    @real_het:
    Arduino az nem hardver, hanem C nyelven írt függvénygyűjtemény. Ahol tudod futtatni:
     - eredetileg AVR8 mikrovezérlőre fejleszették a mikrovezérlő sikerének már a lecsengő ágában
     - látsz 32 bites mikrovezérlő gyártmányokra is portolásokat.

    Igen, a garbage collector valós akadály mikrovezérlőknél
     - C-ben nincs
     - Rust-ban sincs GC, helyette lifetime van
     - D-ben ezek szerint van GC, ami mikrovezérlőre kizáró tényező
    Mutasd a teljes hozzászólást!
  • Korrekt elemzés, teljesen egyetértek.
    Mutasd a teljes hozzászólást!
  • Szerintem azert nincs a D tamogatasa a kicsi processzorokon, mert onnantol kezdve, hogy a D-t nem úgy használod, mint a C-t, hatalmas mennyisegu template kod generalodik. Ez nagyobb alkalmazasnal fel sem tunik, viszont egy functional hello world program eseteben már el is fogyott az MCU memoriaja.

    Pl. ez itt egy rendkivul tomor, lenyegretoro kod (example a dlang.io-rol), viszont a hatterben rengeteg dolognak kell ott lennie, hogy egyaltalan ez mukodhessen.
    Kulon felhivnam a figyelmet, hogy a formatos writeln-nél a format string kiertekelese forditasi idoben tortenik, a generalt kod, már csak a annak a renderelését végzi, a dekódolást nem.

    void main() { import std.algorithm, std.stdio, std.file, std.range; enum cols = 14; // Split file into 14-byte chunks per row thisExePath.File("rb").byChunk(cols).take(20).each!(chunk => // Use range formatting to format the // hexadecimal part and align the text part writefln!"%(%02X %)%*s %s"( chunk, 3 * (cols - chunk.length), "", // Padding chunk.map!(c => // Replace non-printable c < 0x20 || c > 0x7E ? '.' : char(c)))); }

    Ha pedig a kis processzor miatti takarekossag erdekeben ezeket az extrakat nem hasznaljuk, arra akkor meg jó a C is.

    Én is örülnék, ha ugyanebbôl a nyelvbôl tudnék arduinora is forditani, de sajnos (tudomasom szerint) nem lehet.
    Mutasd a teljes hozzászólást!
  • Jó a kérdés.
    D-ben klasszikus mikrokontrollerre nemigen lehet fejleszteni, 8/16 bites támogatásról nem tudok. A 32bit pedig szerintem már nem mikrokontroller, hiába is próbálják az ARM-Cortex processzorokat annak eladni. Az ok, hogy a memória szivárgás kivédése garbage collectorral működik. Ez ki kapcsolható, de van.

    (Ja és érdemes a garbage collctoroknak utána olvasni. Ez a technika sem az ördögtől való. Nagy processzoron igenis hatékony és gyors. Meg tudja oldani a cirkuláris referenciák szivárgását, stb.)

    Minden új nyelvben, ahol a biztonságra törekszenek azonnal kérdés, hogy hogyan lehet alacsonyszinten (oprendszer/mikrokontroller) fejleszteni. Vagy ez, vagy az. A D-ben mindez kapcsolható. A RUSTban, hasonlóan a .NET-hez ez mindenféle trükkös/rusnya/zavaró attribútumozással megoldott.
    Egyébként ez a D-ben is rusnya, sőt állítom, hogy nincs olyan nyelv, ahol ezeket a meta információkat szépen tudnák elhelyezni. Ha alacsony szinthez kell hozzáférni, ott nincs szépség és nincsen biztonság. Ott felelős programozás van. "Gondolkodni kell, kérem!"
    Mutasd a teljes hozzászólást!
  • A D-t én is nézegettem. Szimpatikus, ráadásul jelentősen gyorsabban fordul (Rustnak ez valós hátránya jelenleg). Kár hogy (még) nem tolja valami nagy gyártó a szekerét.

    Rust esetén szép szárnypróbálgatások vannak már mikrovezérlők irányába is.
    D esetén a PC-s ág elég szépen fejlődik. Mennyire előrehaladott a mikrovezérlős ága?
    Mutasd a teljes hozzászólást!
  • Mostanság szerintem már hülyeség új rendszerprogramozásra szánt nyelvet csinálni. 

    Ebben van valami, de csak félig. 2000 óta követek a "D" nyelv fejlődését.

    A C/C++ kiváltására találták ki compiler fejlesztők, tehát már láttak egyet,s mást.
    Amiket problémákat felvetettetek (szerintem mindet), ők is megtalálták: memória szivárgás, null pointer, alacsonyszintű hardver kezelés, védelem a programozó ellen, szabadság a programozó számára, makró/template/generics. És nem utolsó sorban egy olyan nyelv megalkotása, amit egyértelműen fordít a fordító és könnyen olvas a programozó, tehát kevesebb emberi tévesztésre van mód. Ez a fejlesztés 2000 előtt indult. Most ott tart, hogy van V2 nyelv és compiler és egy közösség, aki használja. Nagy projekteket indítanak benne. Home - D Programming Language

    A RUST most indulgat. Sajnos nem nagyon találom (lusta vagyok), hogy mikor kezdődött a nyelv pályája. Attól félek, hogy a 20 év még hiányzik neki.

    Továbbá az sem segít az ügyön, hogy a Microsoft szakmailag már régen nem a legjobb embereket alkalmazza. Lássuk be, a szakmai nagyjai "dolgoztak" a Microsoftnál és nem "dolgoznak".
    Mutasd a teljes hozzászólást!
  • Ilyet már láttunk, mármint hogy jövőre talán.
    Volt 1991-ben egy finn egyetemista, Linus Torvalds volt a neve. Fene gondolta akkor, hogy 25 évvel később már szinte minden embert érinteni fog az alkotása.

    Aztán fene se tudja. Azt viszont hiszem, hogy a C nyelv a hardverig lenyúló rendszerprogramozás terén nem a technikatörténet vége. Ugyanakkor az sem látszik még, hogy a Rust és az általa inspirált újabb rendszerprogramozásra alkalmas, biztonságot előtérbe helyező nyelv fejlesztések hova fognak évtizedes távlatokban vezetni.
    Mutasd a teljes hozzászólást!
  • Miért érzem én azt, hogy a Redox éve is mindig jövõre lesz majd ?

    Mostanság szerintem már hülyeség új rendszerprogramozásra szánt nyelvet csinálni. Sem a windowst nem fogják erre átírni, sem a linuxot, IOS-t, Androidot, de még az SQL szervereket sem. És erősen kétlem, hogy ezen a piacon annyira sok esélye lenne egy új versenyzőnek. A Mozilla is csak küzd mint malac a jégen, Rust-tal vagy anélkül.
    Mutasd a teljes hozzászólást!
  • És a writeln nem makró, a fordító megoldja magának.

    A write/ln speciális nyelvi elem, gyakorlatilag pont, hogy makró-jellegű. Ezért is nem tudsz "mywriteln" eljárást készíteni (legalábbis standard Pascal esetén), mert nincs rá általános szintaxis.

    Egyszerűen a kontextus más, a Rust egy elég új, magasszintű programozási nyelv, amit viszont rendszerprogramozásra is szánnak - lásd az eszmecsere apropójául szolgáló cikket. A Pascal-t viszont elsősorban oktatási célokra találták ki, és azt is jóval régebben tették.
    Mutasd a teljes hozzászólást!
  • Tippet már írtam: méret/sebességkorlátos kód esetén esetleg kerülni akarod őket.
    Mutasd a teljes hozzászólást!
  • Tartok attól, hogy nem a fordítónak van szüksége valójában arra, hogy a függvényt megkülönböztessük a makrótól (felkiáltójellel), annál inkább a programozó tájékoztatására szánják.

    Esetleg valaki tudja, miért hangsúlyozzák a programozónak Rust esetén, hogy makróval van dolga?
    Mutasd a teljes hozzászólást!
  • Tehát ha a fordítási idejû kódgenerálás felesleges, akkor felesleges...

    Gondolom azért felesleges, mert olyan Pascalban nincs. 
    Mutasd a teljes hozzászólást!
  • A Delphi-ben a writeln() (már az ős Pascal-ban is így volt), változó számú argumentumot fogad el, amik ráadásul string-ek, azaz pointerek. És a writeln nem makró, a fordító megoldja magának.

    Miért nem tudja a Rust a saját println kulcsszaváról, hogy az mit csinál? Rákeresek, és ha println, akkor makró, ha más, akkor függvény! Miért kell ezt nekem, mint fejlesztőnek minden egyes alkalommal az orrom alá dörgölni?

    De mindegy is, én sohasem fogok Rust-ot használni, úgyhogy részemről finito...
    Mutasd a teljes hozzászólást!
  • Azt nem mondtam, hogy tudok Shift nélkül kódot írni, azt jeleztem, hogy ha valami felesleges, akkor felesleges...
    Mutasd a teljes hozzászólást!
  • println!() makró engem is meghökkentett elsőre, de utánagondoltam.

    A Rust-ban a makrókat megkülönböztetik a függvénytől ! jellel. Tehát nem függvényhívás lesz, hanem makró behelyettesítés. Oké, de miért makró?

    Változó argumentumot használ a println!(), a Rust viszont nem engedi a függvénynek átadni a tetszőleges változószámhoz a nyers pointert. Ezért az összes C-beli va_start(va_list ap, last_arg) megoldás csak makró lehet.
    Mutasd a teljes hozzászólást!
  • Nem tudta, de végül kiderítette, hogy ez egy f4xság, ezért "joke on you"!!!1!11egy!!1!!! 
    Mutasd a teljes hozzászólást!
  • Te nem tudtad... Amúgy sok sikert a Shift-nélküli programozáshoz, különös tekintettel a rögtön utána következő nyitó zárójelre.
    Mutasd a teljes hozzászólást!
  • Nagyon f..asza! Egy plusz karakter, amihez még a Shift is kell! És nyilván egy képernyőre írásnál iszonyatosan fontos lehet a sebesség, hogy makrót kelljen használni! Kell hozzá a CPU, a memória, a busz, a videokártya, és a képernyő. Ezt tényleg felpörgetheti egy makró! Minden "tiszteletem" a pancsereknek!
    Mutasd a teljes hozzászólást!
  • Semmiseg. 
    Mutasd a teljes hozzászólást!
  • Köszi az Rc-vel való hibára és elkerülésére való rámutatást, mindig tanul az ember.
    Mutasd a teljes hozzászólást!
abcd