Rust-é a jövő?

Programozás

10-20 év alatt igen!
12% (29 szavazat)
Hype az egész, soha nem lesz több pár %-nál a részesedése
33% (78 szavazat)
No comment
47% (110 szavazat)
Egyéb, jól leírom!
7% (16 szavazat)
Összes szavazat: 233

Ezt a Redoxot egyszer láttam menni, egy Rust fan kolléga mutogatta h. mekkora királyság, OS Rustban, de VirtualBoxban nem igazán tudott mást felmutatni mint rövid boot és még rövidebb használat utáni kifagyást. Igaz ez már pár hónapja volt. Biztos akkor még túl sok minden volt "unsafe" blokkokban... :)

Én közben csendben almát majszoltam, hallgattam az égbe magasztalást, bólogattam, és bökködtem a MorphOS-t az öreg PowerBookon, az nem fagyott... Igaz az jórészt C-ben van, és nincs benne memóriavédelem se...

És ha már a lenti hozzászólás közben a Java analógiát hoztam - én még emlékszem amikor a Javaban írt OS koncepciója menő volt, és a Sun meg talán az IBM is arra tett fel mindent, legalábbis a csapból is ez folyt, a CPU független OS koncepciója. Ennek ellenére még CPU-k is készültek (ARM Jazelle, anyone?) ami a Java bytecode futtatását hivatott gyorsítani. Aztán ez némi reality check után lekerült a napirendről, és maradtak az elavult C-ben írt vackok... :P Mert ugye a C nem igazán ideális alkalmazásfejlesztésre, de ne felejtsük el, hogy az első dolog amit C-ben írtak, és amihez a C-t alapvetően kitalálták, az egy OS volt... Hát talán ezért. :)

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

( Chain-Q v | 2018. 03. 01., cs – 12:49 )

A szigorúan ellenőrző nyelvek nem egy új ötlet, lásd pl. Ada.

A Rustról meg a véleményem: jelen állapotában a toolchain rettenetesen kiforratlan, és amíg egy C++-ban írt compiler backendre (LLVM) van az egész piggybackelve, addig nem tudom komolyan venni mint programozási nyelvet, és nehezen beszélhetünk arról hogy ez a jövő. A NodeJS-szerű package kezelés számomra inkább szitokszó, mivel kb. csak arra jó, hogy egy rakás dependencyt tolj a projektedbe rohadt hamar, csak azért hogy gyorsabban elérj valami működő státuszt, de aztán meg lelassítanak mert a dependency management bármilyen hosszűtávon futó projekt elsőszámű problémája. A Docker sem megoldás erre, csak szépségtapasz, mint mikor kirámolod a macskaalmot egy zacskóba aztán bekötöd, hogy ne bűzölögjön. De attól még a szar ott marad. :)

Más: nekem van ismerősöm, aki az Embedded Rust-ot nyomatja orrvérzésig, szurkolok neki, de tavaly még ott tartottunk, hogy én magyaráztam neki Free Pascal források alapján, hogy hogy kell olyan ARM Linuxon atomic operationst csinálni, ahol a CPU-ban nincsen atomic support (ARMv5 pl.), de van kernel helper...

Ezen kívül nincs OOP sem, ami a GUI programozásnál elég nagy hátrány (bár meg lehet lenni nélküle, csak nem érdemes), a szintaxistól meg én személy szerint szemrákot kapok, de ez izlés kérdése.

A "fearless concurrency"-t meg olyasmi buzzwordnek érzem, mint anno a kilencvenes évek közepén a "Java-ban nem lehet memory leaket csinálni mert van GC" című marketing bullshitet, amivel a managed nyelveket promótálták. Cserébe az egyik első Javas melóm (részben) az volt, hogy Java-s projektben kellett memory leakeket vadászni (ki felejt el kiszedni egy objektet egy Vektorból, ugye), meg általánosságban a GC pause-kat rövidíteni és a memory pressure-t csökkenteni. Szóval ja. Semmiféle tool varázslat nem segít azon ha nem tudod mit csinálsz.

Szóval ja. Sok fiatal lelkes gyerek dolgozik rajta, vannak benne jó ötletek, szóval majd megváltják a világot. Vagy nem. :) Én bármilyen nyelven tudok Pascal programot írni, szóval nekem mindegy mi lesz... :)

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

Ahol nincs pck mgmt ott is kezelni kell a függőségek problémáját, csak ott kézzel. Nem látom sehol problémának a csomagkezelést, Java is kb. Mavennel kezdett el igazán használható lenni. Hogy a lehetőségek tárháza miatt gyorsan sok függőséget lehet összef*sni? Ez ne a nyelv/platform hibája legyen már.

>Más: nekem van ismerősöm, aki az Embedded Rust-ot nyomatja orrvérzésig[...]
Ez miért a platform hibája?

>Ezen kívül nincs OOP sem
https://doc.rust-lang.org/book/second-edition/ch17-00-oop.html
TL;DR: De van, csak nem a "klasszikus" C++ stílusban.

>A "fearless concurrency"-t meg olyasmi buzzwordnek érzem
Pedig ahol komolyabban konkurencia kezelés kell, aranyat ér. Mint ahogy a Java-s GC is jelentősen csökkentette a memóriakezelési hibák számát, illetve rettentő módon gyorsította a fejlesztést, hiába nem oldott meg minden problémát, meg vannak saját nyűgjei.

Friss FF-ba bekerült CSS motor fejlesztéséről olvastam, a nyelv, framework korai adaptálása okozta problémák is eltörpültek a statikus ellenőrzés hozadéka mellett:
https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Q…

Java is kb. Mavennel kezdett el igazán használható lenni.

A minap össze kellett raknom egy közepes Java projekt függőségi chainjét, kézzel, mert szeretetre méltó módon az sose jutott el hozzám csak a forrás... Leftpad deluxe, felgyújtanám, ha érted amire gondolok.

Friss FF-ba bekerült CSS motor fejlesztéséről olvastam

Az FF Quantumba pont nem akartam belefolyni. Minden wakeup utan ha felebred, akkor 10-bol 8x elfelejti frissiteni a komplett GUI-t, ha force kilovom akkor meg bentmarad egy rakas processz, ami not answering, de megeszi a CPU-t. Fearless. (OS X)

TL;DR: De van, csak nem a "klasszikus" C++ stílusban.

TL;DR: nincs - "If a language must have inheritance to be an object-oriented language, then Rust is not. There is no way to define a struct that inherits the parent struct’s fields and method implementations."

Igen, egy structba lehet metodusokat rakni, jaj de jo, C-ben is van fuggvenypointer, aminek atadom a self-et elso parameterkent. Nyilvan barmilyen nyelven lehet OOP filozofiaval kodot irni, meg assemblyben is, es meg oroklest is lehet csinalni kezzel, hiszen valahogy csak implementaljak a magas szintu nyelvek is, hiszen a CPU csak pointerekrol tud, kb... De ettol meg a nyelvet nem hivnak OOP-nek.

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

>Leftpad deluxe, felgyújtanám, ha érted amire gondolok.
Erre gondolsz: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ ?
Egyébként meg nem, nem értem. Maven nélkül miért lett volna jobb?

>Az FF Quantumba pont nem akartam belefolyni.
Statikus ellenőrzések a memória hibák elkerülésére != bugmentes szoftver. Attól még csökkentheti a bugok számát, pláne a fejlesztés költségeit.

Megjegyzem az általad írt problémáknak valószínűleg pont semmi közük sem a CSS motorhoz, sem a nyelvhez.

>Igen, egy structba lehet metodusokat rakni
Ja, meg vannak traitek (gyk.: interfészek), amiket implementálhatnak a structok, szóval van pl. polimorfizmus is.

Úgy nehéz lesz vitatkozni, ha random offtopic problémáidat dobálod be a beszélgetésbe, meg amúgy csak kb. hallomásból szerzett információid vannak a nyelvről.


... és amíg egy C++-ban írt compiler backendre (LLVM) van az egész piggybackelve, addig nem tudom komolyan venni mint programozási nyelvet, és nehezen beszélhetünk arról hogy ez a jövő.

Ezt az érvelést nehezen tudom komolyan venni, a GCC is áttért C++-ra, valószínűleg az ICC is abban van, a C# fordítója is C++, meg a GCC-t vagy az LLVM-et használja backendként jónéhány nyelv (Ada, Frotran, Go, D, Obj-C, Swift, ...).


... Semmiféle tool varázslat nem segít azon ha nem tudod mit csinálsz.

Data race esetén a program nem fordul le, ami nyilván azt jelent, hogy nincs működő program, de hibás program sincs. A fordító hibaüzenetéből meg rá lehet jönni, hogy mi a hiba (és nem a feldühödt kliens anyázásából kell rájönni).

( cherockee v | 2018. 03. 01., cs – 13:01 )

Csinálhatnátok egy nagyobb szavazást, mert a GO-ról is hallom, hogy "a tökéletes", de van aki a js-re mondja, hogy a jövő nyelve, ...

( juliusk | 2018. 03. 01., cs – 13:17 )

Hobbi projektben használtam próbából a nyelvet, sajnos van benne még pár pöcsköszörű rész, meg csomó félkész dolog (pl. makrók). De szerintem ígéretes és ami a legfőbb, rettentően jó és pörgős a közösség körülötte, egész biztos vagyok benne hogy messzire fog jutni a nyelv illetve a köré épülő platform.

sajnos van benne még pár pöcsköszörű rész, meg csomó félkész dolog (...) De (...) rettentően jó és pörgős a közösség körülötte

Gratulálunk, Ön sikeresen leírta a túlhájpolt, korai fázisban lévő, kiforratlan technológiák két jellemzőjét. Azaz még nem bizonyított semmit, de már sokan hisznek benne. Én sajnos egy ideje már nem vagyok vallásos.

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

„rettentően jó és pörgős a közösség körülötte”

Pont a mozilla alapítvány-féle SJW-k és a fanatikus fanboyok miatt totálisan ellenszenves az egész.

https://www.youtube.com/watch?v=dIageYT0Vgg

----
„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”

( denesb | 2018. 03. 01., cs – 14:26 )

Mas: korai meg megmondani, akar meg lehet is belolle valami komoly, pl. a C++ kihivoja. De az is lehet, hogy soha nem fog kilepni a lelkes hobbistak + Mozilla berkein tulra.
--
:wq

Hát, szerintem valahol a kettő között van, pl. ezen az oldalon vannak azok a cégek összegyűjtve, akik Rust-ot használnak, és ugyan jópár startup van, de van néhány ismerős név is (Dropbox, Telenor, Samsung, Canonical, Atlassian, CoreOS, ...). Elég gyakori, hogy egy magasabb szintű nyelven írt szoftvert gyorsítanak meg vele, ahelyett, hogy C-vel tették volna ugyanezt, mert a csak a magasabb nyelvet ismerőnek egyszerűbb az új koncepciókat megtanulni Rust-ban, mint debuggolással szívni C-ben.

( szemet | 2018. 03. 01., cs – 14:44 )

Használtam Rustot az elmúlt fél évben production környezetben. Olyan célra használtam ahol C (esetleg C++) lett volna az alapértelmezett választás (ergo a Rust is;): sok Linux syscall level b*szakodást csináló CLI

A legnagyobb problémák amikbe belefutottam mindig az elérhető packagek kiforratlanságai miatt voltak, de ez pont az, ami rohamosan tud fejlődni ha a közösség jó.

Úgy haladtam a projekttel mint a villám, elsősorban talán a package kezelés miatt: a core logika kb. ugyanakkora erőfeszítéssel megírható lett volna C-ben, de az, hogy az egészet professzionális alkalmazássá tegyem ott a Rust sokat gyorsított: logging, regexp, komplex CLI, extra input fájlformátumok supportja (JSON, tar)), stb... Mindegyikre volt valami már valami használható package amit 2 sor volt a buildhez adni, ráadásul a legtöbb lib a C-hez képest minimális boilerplate-tel működött. Szóval maga végső programom forrása majdnem olyan szép, tömör és high-level mint egy azonos funkciójú python vagy ruby script lenne, ami engem nagy elégedettséggel tölt el (ízlések eltérhetnek, valaki szereti a boilerplate-t (go!;), szerintem mondjuk attól hogy valami explicit (amit én is szeretek), még lehet lényegre törő (APL!;)).

Amúgy a nyelvi garanciák, meg az egységes resource management pl. részben pont a 3rd partyk integrálásánál voltak nagyon megnyugtatóak. Hiába húz be a package management a végén 20-30 packaget nem kell "segmentation fault"-tól rettegnem, ha meg mégis megtörténne (velem nem történt meg) elég csak az unsafe-re greppelni...

Amúgy pusztán kíváncsiságból elkezdtem pár Rustban írt Linux CLI appot is használni ha már a build környezetem ott volt, azokkal is elégedett vagyok. (ripgrep,exa,fd) Szóval ha az "amilyen a fa olyan a gyümölcse" mondást nézzük, ott sem áll rosszul egyelőre...

Jut eszembe, előtte írtam egy hobbi appot is. (FUSEos virtuális procfs: arra használtam hogy egy konténerben futó programnak mindenfélét hazudjak /proc-ban...) Azt is élveztem, de akkor még a próbáljunk ki mindent amit a nyelv nyújthat mentalitást használtam, kilométer hosszú iterator chainekkel meg hasonló... :)

Leírom akkor már h. nekem mi tetszene jobban nyelvi szinten:

Általában örülnék ha Haskell felé tolódna pár dologban, úgy mint:

1. Egyszerűen generálható streamek/iteratorok (mondjuk yield-es coroutinok) - ez mondjuk érkezik a jövőben
2. Higher Kinded Types - főleg mert olyan szinten elterjedtek a Haskellre hajazó konstrukciók (Maybe monad -> Option, Either monad -> Result, lazy list -> Iteratorok és mindennek az alapja: type classes -> traits), és ahelyett hogy generikus HKT függvények lennének hozzájuk, mindegyikre külön külön le van implementálva kb. ugyanaz
3. Több type inference: Haskellben nagyon jó, hogy automatikusan megkapom a leggenerikusabb típust és utána kézzel specializálok ha kell. (dinamikus nyelvben meg ilyen pl. a Julia) Rustban legegyszerűbb egyből specializálni és ha valami generikus kell, akkor meg lehet izzadni, hogy hogyan. A type inference nem segít. Egy egyszerű példa: filenevet akarok függvény paraméterként definiálni - ez Rustban legelterjedtebben lehet Path, PathBuf, String, &str - és a compiler mondjuk semmit sem segít, hogy ha mindezt támogatni akarom egyszerre akkor generikusan kifejezve AsRef<Path>-ot kell használjak...

( dark100 | 2018. 03. 01., cs – 16:01 )

Tuti. Az emberiseg kihalasa utan a rozsda lesz az ur.

( rpsoft v | 2018. 03. 01., cs – 17:05 )

Egyéb, leírom: miért lenne egy nyelvé a jövő? A jelen sem egy programozási nyelvé, hanem különböző célokra, különböző csoportok más-más nyelvet használnak (rendszer: C, C++, numerikus programozás: Fortran, C++, Matlab, Julia, Python, alkalmazások: C++, C#, Java, ..., szimbolikus algebra: Reduce, Mathematica, Maple, ...). Még egy célra is több van, és sokszor izlés dolga, vagy rendelkezésre álló kódbázis dönt.

( fdavid | 2018. 03. 01., cs – 17:24 )

Sok nyelv van, ami jo, de nem tud nagyobb nepszerusegre szert tenni. Rendszerprogramozasra sznat modern nyelvkent mar eleg regota ott van pl. a D nyelv, es mostmar a libraryk es a compilerek is koforrottak, sot van neheany enterprise alaklamazas is, megis elegge lassan terjed.

Talán az lehet, hogy a D-nek nem sikerült jól pozícionálnia magát, valahogy az az érzésem hogy beszorult a C++ és a Java közé, és semmit nem mutatott fel (vagy csak nem elég hangsúlyosan) amit vagy egyik vagy másik nem fedett le elég jól. A standard libraryjával is volt valami kavarás(kettő volt egyszerre, ugye?).

Ráadásul a hasonló kategóriában versenyző (fordított, GC-s) nyelvekhez képest se igazi ipari hátszele nem volt (Go), se pedig akadémiai (haskell, ocaml).

Igen, vegulis valahol mind igaz, amit irsz, talan a legnagyobb baj az ipari hatszel hianya.

A pozicionalasban talan az a hiba, hogy nem koncentraltak elegge a beagyazott fejlesztesekre. PC-s kornyezetebne nyilvan a Java meg a C# mellett nem fog nagy piaci reszt kihasitani az enyelv, ami mogott ilyen kicsi ceg all, de beagyazott teruleten egy modern C++-ra lenne kereslet.

Libraryk: Igen, most is van ket alap library a Phobos es a Tango, de ez nekem nem tunik igazan bajnak. Mostanra mindketto kiforrott, jol hasznalhato.

A D nyelvben mostanában eléggé koncentrálnak az ilyen low-level dolgokra, próbálják a GC-t minél jobban opcionálissá tenni, meg újabban a BetterC mód, amin dolgoznak, ami elvileg az, aminek hangzik, D-ben lehet gyakorlatilag C-t írni, kíváncsi leszek, milyen lesz, ha kész lesz. Amúgy szerintem a főleg a Rust, meg a modern C++ hatására kezdtek ebbe az irányba fordulni.

De ezen a területen meg a Rust is egyre nagyobb konkurencia, főleg úgy, hogy az idei útiterv egyik fő pontja éppen a beágyazott rendszerek/mikrokontrollerek.

231840 márc 3 19:51 main

Nekem ezt csinálta Ubuntu 16.04-en.
Akárhogy nézem, ez 200K + egy pici...
Neked hogy sikerült az az 5MB-os?

Ja, asszem, megvan: a -C (Codegen options) közé bekerülhetett egy lto -> Link Time Optimization. Ettől rendesen megnő a fordítási idő és a kész bináris mérete is (helloworld.rs-t fordítva)

A hello-t ARM-ra simán lefordítva és strip-elve:
132732 hello

Hekkeljünk egyet:

$ rustc -O --emit obj hello.rs # kimenete hello.o
$ gcc hello.o -o hello -s -L/usr/lib/rustlib/armv7-unknown-linux-gnueabihf/ -lstd-d102bbd22c9f79a6

5632 hello
Összehasonlítottam egy C-ből fordítottal is, utóbbi 5568 byte lett.

Vajon van-e a rustc-nek olyan kapcsolója, amivel ugyanilyen dinamikusan linkelt kicsi binárist lehet közvetlenül előállítani?

https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.ht…

Amúgy ez a cikk programozási nyelvtől függetlenül kicsit az alapprobléma állatorvosi lovának is felfogható. Hogy mindenki akar egy rakás funkcót a nyelvtől, csináljon meg mindent magától, legyen gondolatolvasó, és legyen kétszáz byte a hello world, mertkülönben.

(OFF: Nekem az FPC-vel vannak ilyen kalandjaim, pl. egy átlag exe megfelelően linkelve 25-35K alapból, platformtól függően amit generálunk, a TP7 valami 4-5K-jával szemben. Jön is rendszeresen a kritika, hogy az FPC milyenszar bloat. Igaz a TP7 nem fog neked Unicode stringeket kezelni, nincs benne kivételkezelés, LFN support meg anyámtyúkja. Ez ilyen...)

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

OFF: Mi tudjuk, az FPC embedded supportjában a runtime libet lehet konfigolni, hogy mit akarsz bele, és amit kikapcsolsz, annak a nyelvi támogatását - ha van - kikapcsolja a fordító. Minden ilyen high level vackot egyesével ki lehet kapcsolni ami nem kell, és akkor hirtelen tényleg max. párszáz byte egy alap bináris és kényelmesen fut egy akármilyen 8 bites AVR-en pl... :)

Előbb-utóbb majd Rustra is lesz valami hasonló - ha még nincs - ha tényleg a mainline-ből akarnak fedni jelentős mennyiségű embedded controllert, főleg 8, 16 és kicsi 32bites platformokat (Cortex M0, meg mittomén).

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

A fordító alapból belefordítja a binárisba a jemalloc nevű memória allokátort azokon a platformokon, ahol elérhető, ami gyorsabb futást eredményez, de kb. 400 KB-tal nagyobb lesz a bináris. Ez a stabil kiadású fordítókban nem kapcsolható ki, mert az allokátor API-n még dolgoznak, de ahogy írtam egy másik hozzászólásban, az idei útiterv egyik fő eleme a beágyazott rendszerek, és ennek a fejlesztésnek ez az API is a része, úgyhogy ez valószínűleg idén stabilizálódik. Olyan terv is van, hogy akkor visszaállnak a rendszer allokátorra, majd kiderül.

>próbálják a GC-t minél jobban opcionálissá tenni
Rustban alapból nincs, a nyelv ugye megoldja a problémát GC nélkül. Referencia számláló smart pointerek a standard libben vannak, illetve GC-s referenciákra külső libbel tudtommal van is lehetőség, de igazából nem nagyon van rá szükség (funfact: kezdeti verzióban volt opcionális GC-s pointer típus a nyelvben, de kiszedték).

Ha D-ben csak most kezdenek GC-ről más megoldás felé mozdulni, szerintem kicsit el vannak késve.

>meg újabban a BetterC mód, amin dolgoznak, ami elvileg az, aminek hangzik, D-ben lehet gyakorlatilag C-t írni
Rustban is. Az unsafe mód egész konkrétan egy felturbózott C, ugyan azok az alacsony szintű memória kezelési lehetőségek megvannak, csak pár dolog jobban specifikált talán, meg van egy adag extra syntactic sugar.

Benne van a nyelvben stabilan az 1.0 óta, lassan 3 éve. Szóval ezt is megkésettnek érzem.

( Dwokfur v | 2018. 03. 01., cs – 18:04 )

Miért nem erlang, vagy haskell? ;-)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Más tradeoff.

Hogy egy példát mondjak, pl. a Rustnak nincs lényegi runtime-ja. Nulla overheaddel illesztheted C projektekhez, akár egyesével cserélve le a függvényeket (lásd firefox).

Erlang pl. nem túl alkalmas számításigényes feladatokra. Haskell GC latency nagy lehet ha sok adatod van: https://stackoverflow.com/questions/36772017/reducing-garbage-collectio…

(Az ezen segítő "compact regions" workaround csak GHC 8.2.1-ben jelent meg...)

Haskell program memóriahasználat és teljesítmény elemzése amúgy sem gyerekjáték, szóval ha PHD nélkül akarsz nagy teljesítményt egy C szerű low level nyelvvel könnyebb lehet...

( ezqgtouvszfgc | 2018. 03. 03., szo – 13:44 )

„Szerintem senki sem tagadja, hogy a hibakeresést a Rust nyelv és fejlesztő környezet könnyíti meg a legjobban, de más okokból mégsem ezt ajánlanám kezdőknek.”

-- https://qubit.hu/2018/01/08/nyelveken-beszelunk

Fedora 27

  • sudo dnf install ripgrep
  • sudo dnf install exa
  • sudo dnf install tokei

MacOS Darwin

  • brew install ripgrep
  • brew install fd
  • brew install exa
  • brew install tokei

FreeBSD

  • pkg install ripgrep
  • pkg install fd
  • pkg install exa
  • pkg install tokei

Windows

  • choco install ripgrep
  • choco install fd
  • scoop install ripgrep
  • scoop install fd

( uid_6201 v | 2018. 03. 01., cs – 23:58 )

Belekóstoltam én is a Rust nyelvbe. Sok olyan tetszik benne, ami a C és C++ nyelvek esetén nem volt kellően szigorú és a fegyelmezetlen programozó szép kis galibát tudott okozni az eddigi nyelveken. A thread safe jellege is ügyes az "ownership" témákkal.

Egyelőre sok dolgot részben rutin hiányában, részben a nyelv szigora miatt roppant nehezen tudok elérni benne. A nyelv dokumentáltsága nagyon tetszik: https://rustbyexample.com/
Mondjuk az kemény volt, amikor szabályos kódot írva bármiféle unsafe nélkül, a fordító nem rinyált (1.23) és mégis segfault lett a futtatás eredménye.


Mondjuk az kemény volt, amikor szabályos kódot írva bármiféle unsafe nélkül, a fordító nem rinyált (1.23) és mégis segfault lett a futtatás eredménye.

Erre van egy egyszerű magyarázat, vagy valami bugba futottál bele, vagy ami valószínűbb, hogy stack overflow-t kaptál, csak ezt néha segfault üzenettel jelzi.

Ha stack overflow okoz segfaultot az is egy bug. Lásd pl: https://github.com/rust-lang/rust/issues/40862
Ilyenkor normálisan panic van egyértelmű hibaüzenettel: "thread 'main' has overflowed its stack"
A bugreport példakódjára most már pl. fixált: https://play.rust-lang.org/?gist=6cccf34b5fabd442a5da8ad592fda6bf&versi…

( Athes v | 2018. 03. 02., p – 06:59 )

Van a C-n kívül más programozási nyelv? :-o

( lacesz v | 2018. 03. 02., p – 13:18 )

Miből gondoljátok, hogy a kismillió programnyelvből pont a rust fogja lenyomni a C-t? Meg egyáltalán, miből gondoljátok, hogy bármi is le tudja nyomni? C volt és lesz is. Első nyelv örök nyelv!

---
Amíg a test renyhe, az elme dolgozik...

Szerintem kicsit árnyaltabb a dolog, ha csak arra gondolok, hogy amikor a Java létrejött, mindenki arra számított, hogy lenyomja a C++-t, ami igazából megtörtént, meg nem is, rengeteg szerveroldali szoftver készül C++ helyett Java-ban, de maradt egy csomó olyan terület ahol a C++ erős maradt vagy növekedett, a Java nem tudta kiváltani teljesen. A Rust esetében is nem csak arról van szó, hogy mennyi C kódot írnak át Rust-ra (ami egy jól karbantartott C kódnál nem igazán fog bekövetkezni), hanem mennyi új projekt készül Rust-ban. És a Rust-nak azért van jó esélye "lenyomni" a C-t, mert nagy százalékban le tudja, vagy le fogja tudni fedni a C használati eseteit, onnantól fogva meg a programozói kultúrán múlik, hogy elfogadja-e a nagy többség, hogy a szigorú fordító valós előnyt jelenthet.

Ha a C++-t vesszük példaként, akkor láthatjuk, hogy 13 évnek kellett eltelnie az első kiadástól a sztenderdig, a Wikipedia szerint 4-5 év telt el, mire egyáltalán elkezdték a tervezését, úgyhogy ilyen szempontból a Rust nem késett el, és a hosszútávú tervek között szerepel is, de nem lesz könnyű. Pl. a memória modell, ami többek között szabályozza, hogy unsafe Rust-ban mi lehetséges, és mi nem (valamint hogy pontosan mi undefined behavior), még nincs pontosan definiálva, a fordító azt csinálja, amit amúgy a backend (LLVM) egy C kóddal csinálna, ami a gyakorlatban használható, de szabványosításhoz nem elég. Van egy kutatócsoport, ami azzal foglalkozik, hogy formális módszerekkel bizonyítják, hogy a típusrendszer szemantikailag értelmes, ami kell egy szabványos memória modell definiálásához. Volt is már néhány eset, hogy találtak a fordítóban ezzel kapcsolatos hibákat, vagy olyan eseteket, hogy egy részlet nem volt rendesen definiálva. Úgyhogy igény is van rá.

( uid_7086 | 2018. 03. 02., p – 13:44 )

Mondana valaki pár szót a Rustról?
Kinek/mikor/mire érdemes/nem érdemes használni stb.?
Csak, hogy valami magyarázat is legyen a szavazás mellé...

A hivatalos "reklám" szerint egy rendszerprogramozási nyelv, ami három fő dologra koncentrál:

  • sebesség: a cél, hogy legalább olyan gyorsan fusson, mint a C és C++, tehát GC sincsen, egy Rust program bináris szinten elég hasonlóan néz ki egy C vagy C++ programhoz.
  • memória biztonság: normális esetben nincs "undefined behavior" a nyelvben, és amúgy is úgy tervezték a nyelvet, hogy minél nehezebb legyen ilyenfajta hibákat ejteni programírás közben, ez azt is jelenti, hogy a fordító sokkal szigorúbb, de így rengeteg potenciális hiba megtalálható fejlesztés közben. Van a nyelvnek az "unsafe" kibővítése, az ilyen blokkokban gyakorlatilag bármi megengedett, ami C-ben, de így a "veszélyes részek jól elkülöníthetőek.
  • konkurencia/párhuzamosság: a helyesen írt Rust programok szálbiztosak, ezt a típusrendszer garantálja

A nyelvet a Mozilla egyik alkalmazottja kezdte el fejleszteni és a Mozilla elkezdte szponzorálni, az volt a fő cél, hogy a Firefox motorjának egyes részeit párhuzamosítsák, ami nem ment C++-ban, mert a meglévő kódbázist nem tudták rendesen módosítani, túl bonyolult volt a kód, nem tudták a bugokat C++-ban rendesen kezelni (kétszer is próbálkoztak a párhuzamosítással). A Firefox Quantum, ami néhány hónapja jelent meg, tartalmazta az első nagyobb modult (CSS motor), amit Rust-ban párhuzamosítottak. De a nyelv nem csak böngészőmotorokhoz jó, a C és C++ egyre inkább kiváltható vele. Persze a nyelv még nincs 3 éves se, úgyhogy elég aktív fejlesztés alatt van még, meg hiányzik néhány dolog, plusz gyerekbetegségek is vannak persze. Meg lehet viszonylag magasabb szintű kódot írni benne, funkcionális nyelvekből jó néhány hasznos dolgot átvettek, úgyhogy magasabb szintű nyelvek kiváltására is alkalmas lehet.

Csak kiegészítés a részletek kedvéért:

Az "undefined behaviour" C-ben (sajnos) elég tág fogalom, nem csak memóriakezelésre vonatkozik. Azon túl, hogy általánosan nincs undefined behaviour a safe Rustban (legalábbis ez a cél), partikulárisan memóriamenedzsment területen nagyjából ezek jelentős hányadát előzi meg statikus fordításidejű ellenőrzéssel: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_errors

A nyelvet 2006-ban kezdte el fejleszteni egy Mozilla alkalmazott szabadidejében, 2009 óta munkaidőben is csinálja - avagy a Mozilla ezt támogatja - s 2015-ben jött ki az 1.0-a. Szóval már elég hosszú történelme van a nyelvnek - s nagyon sokat is változott a 10 év fejlesztés alatt. (Mind a szintaktika mind a szemantika sokat változott korábban, pl volt benne GC is annó)

( uid_7086 | 2018. 03. 03., szo – 19:49 )

Raknám fel a fordítót+doksit az ubuntumra:

The following packages have unmet dependencies:
rust-doc : Depends: fonts-open-sans but it is not installable
E: Unable to correct problems, you have held broken packages.

Ilyen csomagról nem tud az apt...

Igaz, van olyan ubuntu, amin már jó. A 17.10-re valóban felmegy. Csakhát én maradi vagyok, mióta a 17.10-re upgrade agyonvágta a működő 17.04-et és kitartok az LTS mellett. És még mindig ragaszkodnék ahol lehet, a "gyári" repokhoz. (értsd: inkább régebbi legyen, de működjön az apt-get install, ami egyre többször szarja össze magát :( )

Hm?????
Ezt honnan vetted????
Tényleg nem értem, mire gondolsz. Volt egy 17.04, működött. Release upgrad, doksi alapján, egy csomó dolog hirtelen nem működik(*). Öt perc teszt, nagy levegő, gyalu, LTS telepít.

Te linkeltél itt 17.10-es repot, én meg folyamatosan 16.04-ről és a saját repojából telepíthető/telepíthetetlen csomagokról beszéltem.

* - ne kérdezd, mi, annyira gyorsan vágtam ki az egészet, hogy nem volt időm megjegyezni. Az egyik szerverem 17.10 alatt fut, de megvárom a 18.04-t...

( uid_6201 v | 2018. 03. 04., v – 10:34 )

Hogy a Rust mennyire jövőképes, az jó kérdés.
A Debian várhatólag jövőre megjelenő következő kiadásában (testing) már most is szépen karbantartják. Raspberry-re rántottam fel.

Get:1 http://ftp.hu.debian.org/debian buster/main armhf cargo armhf 0.24.0-1 [1,560 kB]
Get:2 http://ftp.hu.debian.org/debian buster/main armhf libstd-rust-1.23 armhf 1.23.0+dfsg1-1 [23.0 MB]
Get:3 http://ftp.hu.debian.org/debian buster/main armhf rustc armhf 1.23.0+dfsg1-1 [1,382 kB]
Get:4 http://ftp.hu.debian.org/debian buster/main armhf libstd-rust-dev armhf 1.23.0+dfsg1-1 [16.7 MB]
Get:5 http://ftp.hu.debian.org/debian buster/main armhf rust-gdb all 1.23.0+dfsg1-1 [113 kB]