Rust 1.74.0

Byla vydána verze 1.74.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.

16.11.2023 15:44 | Ladislav Hagara | Nová verze

Komentáře

[well thats fine]

Tak jsem se jal kompilovati hello-word.rs a vysledni binarka ma 460376 bajtu. WTF? Stripnuti debug balastu to dostalo jenom na 363432 bajtu. WTF?

[little.owl]

Tak to zlepsili oproti 1.63.

:$cat hello.rs 
fn main() {
   println!("Hello World!");
}
:$ rustc  hello.rs 
:$ ls -al hello
-rwxr-x--- 1 xxx xxx 11603080 Nov 16 20:39 hello
:$rustc --version
rustc 1.63.0

[Donald Truth]

Jenže tobě to pizdí linux. Kompiluj to jak normální člověk v macOS a bude to třetina.

[little.owl]

Ne, je to primarne o verzi a zmenam ktere udelali. U 1.73 je to na stejnem stroji neco pres 450kB. Delate ze sebe normalniho osla a macOS to nezachrani.

[zhizhall@]

Nezamlouvej. Totoznost osla je tady zrejma - linuxak.

[benda]

okomentuj prosim 500 nejvýkonnějších superpočítačů

[koroptev]

ze je bastlili socky co nemaji lowe a koule to postavit na M3 a macOS

[ewew]

Veľa štastia programovať pre navykonnejšie počítače na procesore RISC.

Mac je pre ľudi, ktorím robí aj rozhodnutie problém.

[Apfelstrudel]

Nazdar ewewe ty mas ten talent ze pul roku mlcis a pak se objevis v diskuzi kde macOS dava na prdel lihnusu Cim to je?

[little.owl]

[Josef Kufner]

V prostém C to není o moc lepší. Jednoduché printf("Hello world") má při statickém linkování 745KB, stripnuté 667K. Teprve při dynamickém linkování to je 16KB, resp. 15K stripnuté.

[Erin]

Problém je v tom že Rust stdlib nakonec také bude volat funkci z libc která ten řetězec writne do stdoutu. Ale ono si to s sebou táhne nějaký runtime a inicializační kód který nějaké místo zabírá.

Například když jsem dělala takový jednoduchý bootovatelný interpretr pro x86-64ku tak to zabíralo dokonce méně.

[Erin]

Ještě k tomu, Céčko má také docela velký runtime:

erin@erin-desktop ~> ls -lh /boot/ostree/fedora-b57af0c7fbbfccce5ef8bf2aa99df8aad7d52128507c82c3f67d6b4352d6b80a/vmlinuz-6.5.11-300.fc39.x86_64 /usr/lib64/libc.so.6

-rwxr-xr-x. 1 root root 14M 13. lis 19.53 /boot/ostree/fedora-b57af0c7fbbfccce5ef8bf2aa99df8aad7d52128507c82c3f67d6b4352d6b80a/vmlinuz-6.5.11-300.fc39.x86_64*

-rwxr-xr-x. 4 root root 2,2M 1. led 1970 /usr/lib64/libc.so.6*

...a to není všechno.

[little.owl]

U cecka mate k dispozici male standardni knihovny, namatkou uClibc a pak je to nekde jinde.

[zel]

Porad je to masakr, vzdyt v ASM by to bylo do jednoho kila i s implementaci stdout.

[koroptev]

a proc to teda nepises v asm?

[zel]

Praveze vetsinou pisu

[koroptev]

proc ne ted? a nerikej, ze to je na asm moc slozity, ze bys to nedal, ze by to trvalo neumerny mnozstvi spalenyho casu a ze by pak nejaka drobna zmena zadani ustila v masivni prepis, protoze by ti chybely abstrakce.. kdyz asm, tak se vsim vsudy

[Kate]

To jsou zjevně Hello World programátoři, jejich hlavní pracovní náplň je psát optimalizované Hello World aplikace.

[zel]

Neni problem

$master≫ cat hello.asm
    global    start
    section   .text
start:
    mov       rax, 0x02000004
    mov       rdi, 1
    mov       rsi, message
    mov       rdx, 13
    syscall
    mov       rax, 0x02000001
    xor       rdi, rdi
    syscall
    section   .data
message:
    db        "Hello, World", 10
$master≫ nasm -f macho64 hello.asm
$master≫ ld -macosx_version_min 10.7.0 -o hello hello.o
$master≫ ls -l
-rwxr-xr-x   1 kapica  staff  32904 Nov 17 21:18 hello
-rw-r--r--   1 kapica  staff    290 Nov 17 21:16 hello.asm
-rw-r--r--   1 kapica  staff    399 Nov 17 21:18 hello.o
$master≫ ./hello
Hello, World
$master≫

[Al Esh]

kapica?!!

[Petr Tomášek]

staff ???

[Lol]

master of universe?!!

[kdosi]

U mě 64B+řetězec :)

[xkucf03]

O to právě jde – C, C++, Java a další dokáží dost dobře fungovat dynamicky linkované. Ty programy pak mají třeba jen pár kilobajtů. Neříkám, že statické linkování nemá využití, někdy má, ale vnucovat to všem považuji za chybu.

[Kate]

Mara Bos co jsem koukala naposledy pracuje na lepším dynamickém linkování. Na stranu druhou, těch situací kdy to je skutečně výhodné imho zas tak moc není. Snad jen u obřích knihoven typu GUI framework.

[xkucf03]

Mara Bos co jsem koukala naposledy pracuje na lepším dynamickém linkování.

Tak to je dobrá zpráva.

těch situací kdy to je skutečně výhodné imho zas tak moc není

Výhodné z jakého důvodu? Ono nejde jen o velikost binárky, ale i o možnost napojení na jinou verzi/implementaci knihovny, ať už kvůli aktualizacím nebo hackování, zkoumání, co program dělá, nebo upravování jednotlivých funkcí přes LD_PRELOAD.

Sice můžeš říct, že si můžu upravit zdrojáky a přeložit si celou aplikaci, ale někdy ty zdrojáky nejsou (nebo třeba nejsou v té konkrétní verzi) nebo to nechci dělat, protože to trvá dlouho, zabírá to místo a musím je stahovat a často to přináší další závislosti (které pro běh nejsou potřeba)… Takže možnost podstrčit jinou verzi knihoven je pro mě jednoznačně plus. Dynamické linkování beru jako výchozí normální stav – a až pokud je k tomu dobrý důvod, mám z toho konkrétní užitek, tak použiji statické linkování.

[Kate]

Pro mě by důvod byla hlavně možnost psát aplikaci umožňující dynamické pluginy. Co tak sleduju, některé Rust aplikace tohle řeší přes WebAssemblyz ale není to úplně ideální.

Hlavní snaha je myslím vyrobit rozhraní které bude nahrazovat FFI, aby bylo možné zachovat záruky Ruatu.

Jinak pro "Dynamické linkování jako default je zbytečné" mě přesvědčil tenhle post. Ne vždy s DeVaultem souhlasím, ale tady se mi nedaří najít chybu v závěru (jen mě překvapuje že i přesto nesnáší flatpak, přijde mi že jeden z hlavních argumentů proti Flatpaku jsou právě dynamické knihovny)

[xkucf03]

Pro mě by důvod byla hlavně možnost psát aplikaci umožňující dynamické pluginy.

Ono to spolu souvisí. Knihovna je v principu totéž jako modul/plugin v modulárním systému. Např. v OSGi v Javě máš knihovny třetích stran i moduly vlastní aplikace na stejné úrovni, všechno to jsou tzv. bundly a se vším se pracuje stejným způsobem – máš tam deklarované závislosti na ostatních modulech/službách, deklarované služby, které poskytuješ ty, má to stejný diagram stavů, můžeš to dynamicky instalovat/odinstalovávat, zapínat/vypínat.

A rozhodně to není výsada Javy nebo dynamičtějších jazyků. Hezký příklad, že psát modulárně jde i ve starém dobrém Céčku, je SQLite. Tohle je obecná teorie nezávislá na jazyku. Viz Niklaus Wirth a další práce na tohle téma.

Mimochodem, dochází tu k podobnému omylu jako v případě desktopů / pracovních stanic. Někdy před 10+ lety vyšly statistiky o tom, že se prodává víc mobilů / tabletů než desktopů / notebooků / pracovních stanic. To si někteří vyložili tak, že se má vše optimalizovat pro mobily a dotykové ovládání… a následky této scestné úvahy sklízíme dodnes – spousta věcí na desktopu je rozvrtaná a polofunkční, nedotažená, i když třeba dřív fungovala.

Navíc se to sešlo s dalším omylem a to, že „čím víc lidí se do vývoje softwaru zapojí, tím líp“. V praxi vídám, že je to přesně naopak – čím víc lidí se do projektu zapojí, tím hůř to dopadá. Týká se to jak uzavřených komerčních produktů, tak otevřených. Jsou tu samozřejmě světlé výjimky (např. když spousta lidí vyvíjí ovladače, každý pro něco jiného, a pak to dají na jednu hromadu – tohle škáluje celkem dobře).

Dneska tu zase máme trend mikroslužeb a různých kontejnerů (dockerů, kubernetů atd.). A opět si to někteří vykládají tak, že je možné všechno zahodit a věnovat se čistě jen tomu trendu. Že je něco zrovna v kurzu, neznamená, že se může kašlat na vše ostatní – ty další případy užití nezmizely a stále je potřeba jim věnovat náležitou pozornost. Desktopy, pracovní stanice nebo trvale instalované systémy (ne jen jednorázově nakopírované binárky spuštěné v nějakém kontejneru) tu jsou pořád a je potřeba, aby fungovaly.

[sid]

Osgi je zrovna priklad technologie kde inzinierske hladisko uplne odignorovalo bezne use cases a interoperabilitu s non osgi svetom. Prislo z telco sveta a doby app serverov ale ten typ dynamickosti co ponuka tak ci tak 99% aplikaci schova za blueprint. To co pises o loading/unloading za behu je mieco co v realite nechces. Staci pridat novu splnenu zavislost a karaf je schopny urobit refresh nejakej superzakladneho bundle a cela tvoja aplikacia ide dole lebo samozrejme refresh vyvola masivny refresh bundlov co maju zavislost na tom refreshovanom bundle. A potom pride faza 2 modlenie sa aby sa to dalo hore co neni az taka samozrejmost.

[BoneFlute]

Chápu námitku. Ale nejsem si úplně jist, zda mi dochází, jak to řešit jinak?

Modulární aplikace je o tom, že můžeš měnit moduly za běhu, a pokud je to dobře udělaný, tak se to všechno včetně dat dobře povede.

Nemodulární aplikace znamená, že musím udělat down, aktualizovat, překompilovat s novými částmi, a znovu spustit.

Očekávané chování je takové, že to zvládne zpracovat aktuální data, aktuální session, že to naběhne. Zatímco Osgi je navržené na to, aby to tyto problémy řešilo, a když to neřeší tak všichni oprávněně řvou; nemodulární aplikace neřeší vůbec nic. Je naprosto běžné a opak slávou, že si nedokáže ani načíst data z předchozí verze (natož session).

Souhlasil bych s tím, že asi není úplně nutné, aby se ta aplikace dokázala měnit za chodu. Klidně udělám restart, jde to v nulovém čase. Ale úspěšné nahrání dat či dokonce session by se mi líbilo.

[xkucf03]

Osgi je zrovna priklad technologie kde inzinierske hladisko uplne odignorovalo bezne use cases a interoperabilitu s non osgi svetom.

Ta interoperabilita je dnes už celkem dobrá, většina knihoven ty OSGi hlavičky už má nebo není problém si knihovnu do bundlu přebalit.

To co pises o loading/unloading za behu je nieco co v realite nechces.

Kvůli tomu to právě děláš. Pokud ti stačí statické moduly, tak můžeš použít JPMS (relativně novinka) nebo odjakživa: nasypat správná JARka do class path (a použít třeba ServiceLoader nebo ani to ne).

Je užitečné mít možnost nasadit nový modul k těm stávajícím a ještě víc se hodí možnost upgradovat nějaký modul nebo ho restartovat s novou konfigrací. Dají se takhle hezky dělat upgrady bez výpadku – tohle používám s Camelem – ten pozdrží příchozí požadavky/zprávy (např. HTTP) a mezi tím se otočí modul obsahující implementaci služby. Klient žádný výpadek nepozoruje, neodmítne mu to spojení, nepřeruší ho to, všimne si maximálně delší odezvy (třeba vteřina nebo spíš méně).

masivny refresh bundlov

Modul by tohle měl v pohodě přežít. Rozhodně to není tak, že by Karaf (OSGi běhové prostředí) natvrdo sestřelil moduly v půlce práce. Např. ten Camel dokončí rozpracované úlohy a až pak se ten tvůj modul, kde ho používáš, otočí.

A potom pride faza 2 modlenie sa aby sa to dalo hore co neni az taka samozrejmost.

Pokud ti dojde paměť, místo na disku nebo se při restartu načte nová konfigurace a do té doby to běželo se starou (to záleží na tobě, jestli ji načítáš automaticky nebo jen při re/startu), tak se to samozřejmě rozbít může, ale jinak by to fungovat mělo.

Nicméně: taky jsem si s tím užil různá trápení za ty roky, co to používám – netvrdím, že je to bezchybná technologie… ale to není žádná. Ta myšlenka je ale jednoznačně správná – takhle mají systémy vypadat – a implementace je dostatečně dobrá na to, aby to šlo používat v praxi.

[sid]

Ta interoperabilita neni dobra. Coraz viac projektov odchadza prec (Camel, CXF, hibernate). Za prve mas klasicke problemy typu META-INF/service. To vies obist cez wrap alebo priamo v builde pridat hlavicky. Druhe, ze stale existuju kniznice ktore maju zmrseny import. Treti problem je, ze naprostu vacsinu projektov OSGI nepali (99.99% pouzivatelov je klasicka java). 4 ze obcas nejaka kniznica pouziva vlastne nahratie tried co v pripade classloadingu z bundle neni kompatibilne. A potom tie volania obalujes.

"Dají se takhle hezky dělat upgrady bez výpadku" - jedine ak ten servis je koncovy pouzivatel. Skus si len pre taky pokus pridat nejaku zavislost ktora je v nejakom core servise (myslim karafu) ako optional co to urobi so vsetkymi tvojimi servismi vyssie. Vtipne na tom je, ze tato optional dependency moze prist ako sucast feature nejakej tvojej malej feature ovela neskor. Ak pozeras log tak uvidis tak masivny refresh (ano aj http) ze som si celkom isty, ze cela tvoja aplikacia pojde dole.

Podla toho co pises mi pride ze si dost high level pouzivatel co o tom co sa deje na pozadi ani snad moc nevies. Tj mas Camel pridas tam novu routu a funguje. Zaver OSGI je uplne cool. Btw S diskom a pamatov to naozaj nema nic spolocne. Problem je, ze z povahy veci ten refresh je dost stochaisticky proces. Jedna moznost ako toto trocha skrotit je nastavit autoRefresh=false a druha urobit to ako static distribution (ale tam okrem dobre urobeneho class loadera stracas to co je OSGI a na otazku preco nie spring boot/quarkus/xxx tazko odpovies inac, ze samozrejme ano) . A k tomu "takhle mají systémy vypadat" - to nakoniec mozes povedat ze C je finalny jazyk. Ked "dobre napises" synchronizaciu atd atd atd tak mas plnu kontrolu nad vsetkym. Lenze realita je taka, ze napisat tieto veci spravne v pripade, ze zavisis na x knizniciach a aplikacia je dost zlozita je naozaj zlozite a preto tu mame Rust atd atd. A OSGI je presne tento pripad. Velka volnost a tym padom aj vela moznosti ako mozu veci ist zle. A nebavme sa o "to je problem implementacie". Ked urobis system kde je az moc vela stupnov volnosti tak je proste z principu zlozite ho implementovat. Specialne ak chces aby mnozina end userov nebola cislo ktore vies ukazat na prstoch oboch ruk. Riesenie pre OSGI bolo blueprint (odvodenina spring) lenze to je potom taky mackopes. Pre OSGI svet neni dost dobre (DS funguju nasobne lepsie) a pre Java svet (spring) je zase malo schopny z ich pohladu. Kazdopadne toto je viac menej akademicka debata. OSGI je mrtva vec ktora uz len doziva. Ked JB nebude mat viac casu (co zda sa ma coraz menej) tak Karaf skonci a tym padom jedine prostredie ktore sa da pouzit. Uz teraz vidiet napr na stave OSGI a jakarta namespace, ze vsetko okolo preslo a OSGI svet nie. Tym padom ako pisem na zaciatku coraz viac projektov OSGI hlavicky + dodatocne veci dava prec takze je to viac menej zacarovaneho kruhu, end user nema kniznice s OSGI a kniznice zase pouzivatelov z OSGI sveta (tj zaujem cosi robit)

[kralyk z abclinuxu]

Dají se takhle hezky dělat upgrady bez výpadku – tohle používám s Camelem – ten pozdrží příchozí požadavky/zprávy (např. HTTP) a mezi tím se otočí modul obsahující implementaci služby. Klient žádný výpadek nepozoruje, neodmítne mu to spojení, nepřeruší ho to, všimne si maximálně delší odezvy (třeba vteřina nebo spíš méně).

Ten kritizovaný kubernetes tohle udělá aniž by bylo potřeba tu službu psát v jazyce X s frameworkem Y (ano, vim že osgi implementací je několik, ale tím se to moc nemění) nebo vymýšlet nějaké rovnáky na ohejbáky zavádějící dynamické linkování všeho...

[kralyk z abclinuxu]

Tohle je obecná teorie nezávislá na jazyku.

Ježišmarja, to je furt dokola...

Ukaž technické řešení, jak se má dynamicky a bez degradace aktuální kvality (výkon, bezpečnost) linkovat Iterator nebo Stream nebo AsyncWrite. Inb4 "nevím, neznám technické detaily Rustu, to po mě nechtějte" - aha, a jak teda víš, že na jazyku nezáleží?

Tvůj kód linkuje string nebo iostream nebo unordered_mapu dynamicky?

[Kate]

Tak a teď znova s

RUSTFLAGS='-C strip=symbols -C prefer-dynamic' cargo build --release

Což je blíž tomu jak kompiluje C.

[Kate]

Jinak to co to zabere navíc kvůli staticky linkované runtime už tolik neroste. Třeba teď jsem v práci dopsala service pro forward-auth na microsoft Entra. Táhne si s sebou ještě k tomu async runtime, malý web framework a pár dalších knihoven. Celková velikost výsledného OCI kontejneru 28MB, což mi nijak špatné nepřijde.

[.G]

1. co se nevejde na disketu je spatne

2. kolik ma tedy ta tvoje vysledna kompilace? Poprosime radeji vysledek z macOS, linux bude marny.

[Kate]

Kompilace relativně jednoduché serverové aplikace? 15 MB, ale bez jakýchkoliv optimalizací na velikost, protože to v tuhle chvíli považuju za ztrátu času. Binárka je malá, runtime spotřebu RAM a CPU má monitoring většinou problém rozlišit od 0. Na Macu to kompilovat nebudu, protože nám fakt servery na Macu neběží.

Kompilace hello world? To ať si každý zkusí s těmi parametry sám. Dá se to ještě zmenšit, ale popravdě, jako benchmark jazyka je to naprosto stupidní a validní jen pokud je Hello World maximum co zvládneš napsat, ale v tom případě chápu tvou starost :)

[Stru]

Trust doesn't rust.

[B]

Tak jsem se ho začal pomalu učit a začínám ho mít rád.

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[B]

Proč bych se měl nechat operovat? Rust nebyl stvořen, protože někdo měl mindráky a chtěl být in. Rust byl stvořen, protože Céčko je prasárna, které je potřeba se zbavit. Místním lemplům se to nelíbí, protože by se museli učit něco nového a hrozí nebezpečí, že by se ukázalo, že na to nemají, tak tady řvou jak je ten Rust špatný nebo urážejí ty, kteří mají na to, aby ho používali.

[RealJ]

Takze misto prasackeho Ccka tady mame prasackej Rust. Prast jako uhod. Rust je v par vecech lepsi, Ccko je v jinych vecech lepsi. No a skutecny profesional pouziva fortran nebo lisp. ;)

[koroptev]

v cem je Rust prasackej?

Cecko je spatny, protoze 1.) ma nekolik neprijemnejch design flaws, ktery ustej v tridy bugu, ktery v jinejch jazycich neexistujou 2.) ho jeste dnes idioti pouzivaji na nove veci

lisp je nadherna fantazie, ktera se nikdy neuskutecnila, fortran podobne jako cobol v katatonickem stavu udrzovanej nazivu duchodcema a par mladejma bez duse, ktery to jdou delat jen kvuli penezum

[little.owl]

Lisp je v ruznych reinkarnacich stale zivy a asi bude, na poli homoikonickych jazyku jinou konkurenci nema, viz treba Clojure.

[Kate]

Z Lisp dialektů mě ještě celkem zaujal Racket, asi si ho letos vyzkouším na Advent of Code

[Erin]

Já to zkoušela minulý rok ale tradičně po 3tím dni, jelikož dělám i jiné věci tak začnu být pozadu a pak to prostě vzdám :D Ale jinak se to v tom dělalo pěkně.

[little.owl]

Racket je univerzitni klasika, stale se na tom nejlepe uci zaklady computer science.

[koroptev]

Common lisp a Scheme maji dnes +- nulovy realny pouziti vne vyuky. Zivost je asi takova, jako jsem ja zivej uvnitr svych pravnuku pote, co zemru..

[¥]

Ty asi nepouzivas Emacs ze ne?

[koroptev]

ehm, dynamic scoping

[little.owl]

To lze opet generalizovat na kazdy programovaci jazyk, cas ho semele. Lispovske jazyky tu stale jsou, stale se aktivne vyvijeji - staci se podivat do jejich git repositories, stale se vyucuji, pres 60 let, od ruznych verzi scheme - treba zminena Racket (release 8.11 pred par dny), pres elisp, po Clojure. Silnou strankou je jednoduchost, homoikonicita, snadna implementovatelnost, moznost demonstrovat vsechny fundamentalni koncepty programovani v computer science. I jen ta samotna vyuka jim zatim zduvodnuje a zajistuje existenci. Lispovske jazyky nikdy nebyly vylozene mainstream, vzdy to byla spise akademicka zalezitost. Je velmi pravdepodobne, ze casem zaniknou, ale zatim tam jeste nejsme a rozhodne to neni situace, kdyby je znali jen geronti - staci se podivat jen londynskou Clojure skupinu - LondonClojurians - je tam plno mladsich lidi a u podstatne casti je to soucast jejich prace.

[Kate]

Potvrzuju i v práci, z mladých lidí co jsem v předchozí firmě nabírala do teamu byl Lisp docela častý přinejmenším jako hobby (a pak ještě haskell). Na stranu druhou, u Rust devů bude ten bias k funkcionálním jazykům větší než běžně.

[koroptev]

hm, akorat ze treba Common lisp je ciste imperativni jazyk..

[koroptev]

ad nikdy nebyly mainstream - to asi plati, ale rozhodne to melo svuj primetime, kdy se vyrabel hw, na kterem bezel lisp rovnou na zeleze, tohle je davno za nami, nevrati se to a to, co nam tu z lispovskych jazyku zbylo, ma dnes vpodstate kazdy moderni jazyk (az na makra)

to, co rikas, neplati v te obecnosti, common lisp urcite neni jednoduchy, demonstrovat se na "normalnim" lispu vsechny koncepty programovani nedaji, nebot lisp je (ano, Racket, vim a ne..) dynamicky typovany, cili to stejne, co se da demonstrovat Haskellem se lispem demonstrovat dat nebude.. atd. atp.

krasna fantazie, ktera z 99% vychazi z te nesyntaxe, coz je koncept vysvetlitelnej behem ani ne peti minut

tez koncept, kterej vetsina jazyku nema, nebot se pravdepodobne testovanim na mase ukazalo, ze syntaxe ma smysl

geronty mi nepodsouvej, o tech jsem mluvil v souvislosti s uplne jinejma jazykama..

btw uplne stejnej pribeh jako lisp ma z myho pohledu smalltalk

[little.owl]

nam tu z lispovskych jazyku zbylo, ma dnes vpodstate kazdy moderni jazyk (az na makra)

Nemaji homoikonicitu, ktera prave umoznuje mit takovy efektivni makro system. Makra vam umoznuji transformovat jazyk jako takovy v mire co zadny jiny jazyk nezvlada, doslova vytvorit novy DSL.

common lisp urcite neni jednoduchy,

Neni, common/ANSI lisp je stejny clusterfuck jako C++, pokusili se vyhovet vsem a do standardu integrovali pomalu i kuchynsky drez.

Cetl jsem ANSI Common Lisp od Paul Graham, znam i C++ standard a vetsinu Stroustrupovych knih, C++ mi prijde jako vice nekonzistentni bazmek.

Jadro lispovskych jazyku je jednoduche, implementace interpreteru byva(l) bezny semestralni ukol. Ostatne i vetsinu implementace standardu CL lze resit jako set maker nad relativne jednoduchym jadrem.

[deda.jabko]

Fun fact: Jeden z nejrozsirenejsich (nikoliv nejlepsich) jazyku soucasnosti vychazi na Schemu. (A je to ta jeho lepsi cast.)

[deda.jabko]

*ze Schemu

[Kate]

Předpokládám že jde o Javascript? :)

[koroptev]

jj, JS je asi takovy Scheme jako Python..

[..... Izak .....]

COBOL je specificky tim, ze se nevyviji, je jednoduchy a nema v sobe zadny bug - pouziva se hlavne amrade a na kriticke veci - idelni jazyk na duchod, anuci se jej kazdy, presto jej nikdo neumi, takze prtace na se se dlouho hleda, ale kdyz se najde, tak je to asi uz nafurt

Fortran - zivy jazyk, neni nic lepsiho na matematiku, ti co jej neumi se snazi pouzivat jeho prepis do C++ ala knihovna B++ - presto, pokud by se na mat. veci pouzival F90 - ubylo by vyrazne chyb s tim, ze neni problem mit neco v C++/Rust a prilinkovat k tomu objekt z F90

Fortran je odladeny, nedela chyby, umi paralelizmy, od F90 je dela sam asi ma v sobe mpich - ale hlavne sam paralizuje vypoicty co jdou.

Fyzici F90 pouzivaji casto misto matlabau/mapple - cili genialni jazyk ale jen na vypocty, nic jineho v nem relne nema cenu delat, proto ty runtime knihovny slinkovane k necemu universalnimu.

Jaky by byly vyhody: rychlost, presnost, nulova chybovost zpusobene kompilaci

[Na zdravi]

Apky v C nebo Rust dnes uz moc valny smysl nemaji, ledaze jde o operacni system nebo neco low level. Normalni vyvoj ma dnes v rukou pevne Swift, pak jeste chvili tady budou prudit upadajici Java/.NET. Ale climber dekady je jednoznacne JavaScript(a spol) a ten to vsechno semele do roka a do dna, ehm do dne

[little.owl]

Jazyk C je tu pres 50 let a stale je to relevantni jazyk ve kterem je napsana podstatna cas veci okolo nas a kdy mohu vzit desitky let stary program a prelozit ho. Realne je to uspesny jazyk a ne bez duvodu. Uvidime jak na tom bude Rust treba za tricet let, ale po prvnich deseti letech sve existence nema zdaleka takovou pozici jako melo C po deseti letech. Ohledne uceni Rustu, jste komik, kazdy kdo zvladne C na rozumnejsi urovni, pripadne komplexnejsi moderni C++ se vsemi jejich niancemi, zvladne Rust, realne je to jednoduzsi jazyk.

[koroptev]

kdy muzes vzit desitky let stary program a najit v nem trivialni buffer overflow chybu.. atd. atp.

pohrbit to, je to jazyk z ery, ktera je za nami, svoji niku to (stejne jako C++) ma, vsude jinde je to blbost

[little.owl]

Chyby lze udelat v kazdem jazyce a programu. Svoji niku bude mit i Rust.

[koroptev]

to jo, akorat ze na linuxu se v C pisou i normalni GUI aplikace..

[xkucf03]

Ano, to je taková podivná móda nebo zvyk. Céčko byl skvělý jazyk ve srovnání s assemblerem. Dodnes ho lze brát jako jazyk pro systém a rozhraní mezi jazyky (i když to skřípe, použitelné to je). Ale psát v něm aplikace nebo i většinu utilit je dost nerozumné – zvlášť když tu je spousta vysokoúrovňových a bezpečných jazyků jako D, C++, Java, na které lze z C relativně plynule přejít a není to celé jinak (jako u Lispů, Haskellů, Rustů…).

[koroptev]

btw o C++ uz se tez testovanim na mase zjistilo, ze to neni general purpose jazyk..

[Kate]

Řekla bych že v tomhle se situace Rustu a C nedá úplně srovnat, C mělo imho výhodu v době kdy bylo vytvořené. Na stranu druhou, když srovnám adopci Rustu firmama a projektama s jinými jazyky s podobnou ambicí, vede si celkem slušně. Cokoliv jiného co poslední dobou nějak prorazilo byly jazyky silně tlačené firmama (Swift - Apple, Go - Google, .net - MS)

[little.owl]

Ja nemam problem s Rustem, je to pekny jazyk a resi spoustu problemu, ktere jsou inherentni C/C++, od UB po memory model.

Ja se spise vymezuji vuci zbytecne demonizaci C-ka. To v dobe vzniku resilo portabilitu unixoveho kernelu na ruzne platformy a jednalo se realne o nahradu do te doby bezneho neportovatelneho psani OS v assembleru. Jeho navrh si tedy nekladl za cil prinaset nejakou abstrakci a prevzal i memory model tak je implementovan na HW, v podstate se jedna o portovatelny assemler. Tak je na to nutne koukat a to plnilo C desitky let velmi dobre.

To ze jsme se dnes posunuly a mame jine naroky a pozadavky, programuje kdejake lemro, je jina vec.

Rust je v soucasnosti take tlacen velkymi firmami - Microsoft, Google, Amazon a dalsi - byt zacatky byly jine.

[prt]

Souhlas, C je spíš zastaralý jazyk než špatný. IMHO je to i tím, že se v podstatě vůbec nevyvíjí. A to nemluvím o UB nebo o abstrakcích, ale spíš syntaxi jazyka. Stále tam nejsou ani v 2023 základní věci jako třeba namespace. Chápu, že když to potřebovali kompilovat s použitím max. kilobajtů paměti, k to tam dát nemohli, ale dneska už se to omluvit ničím nedá.

[little.owl]

Tak slouzi stale ke stejnemu ucelu. Namespacy vam vetsinou vedou k name mangling a to vam komplikuje interpretaci debug symbolu.

Puvodni kompilator z 1e UNIXu na PDP-11 je treba tady, v adresari src/c. Museli ho mit opravdu trivialni, nebot dispozici meli skutecne jen par kilobajtu. Je videt, ze kompilator vicemene pracoval na urovni rutin/funkci a ze to psali lide, kteri do nedavna psali v dominantne assembleru, treba:

jumpc(tree, lbl, cond)
int tree[]; {
	extern jump, cctab[], rcexpr, isn, label, branch, cbranch;
	int l1, l2;

	if (tree==0)
		return;
	switch(*tree) {

	/* & */
	case 47:
		if (cond) {
			cbranch(tree[3], l1=isn++, 0, 0);
			cbranch(tree[4], l1, 0, 0);
			jump(lbl);
			label(l1);
		} else {
			cbranch(tree[3], l1=isn++, 0, 0);
			cbranch(tree[4], l2=isn++, 1, 0);
			label(l1);
			jump(lbl);
			label(l2);
		}
		return;

	/* | */
	case 48:
		if (cond) {
			cbranch(tree[3], l1=isn++, 1, 0);
			cbranch(tree[4], l2=isn++, 0, 0);
			label(l1);
			jump(lbl);
			label(l2);
		} else {
			cbranch(tree[3], l1=isn++, 1, 0);
			cbranch(tree[4], l1, 1, 0);
			jump(lbl);
			label(l1);
		}
		return;

	/* ! */
	case 34:
		jumpc(tree[3], lbl, !cond);
		return;
	}
	rcexpr(tree, cctab, 0);
	branch(l1=isn++, *tree, cond);
	jump(lbl);
	label(l1);
	return;
}

[Kate]

Obávám se že transplantace mozku se zatím nikomu nepodařila, budeš se muset naučit žít s tím co máš a doufat :(

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[Erin]

Alespoň já to nikomu netvrdila. Líbi se mi holky, promiň, u mě nemáš šanci, ale hodně štěstí s hledáním :)