Cel mai bun răspuns
Depinde ce înțelegeți prin „programare de sistem” și „cel mai bun”.
De exemplu, ATS (http://www.ats-lang.org/) poate îndeplini toate criteriile dvs. și multe altele – este un limbaj sigur, cu funcții de concurență la nivel înalt, suport pentru, dar nu mandatul unei funcționale stil și performanță foarte bună. Chiar dacă este una dintre cele mai bune pe hârtie, este posibil să nu fie „cea mai bună”, deoarece nu sunt destui oameni care o folosesc și pare „diferită”.
În cealaltă direcție, C este îngrozitor din mai multe motive. Gestionarea manuală a memoriei este o sursă uriașă de bug-uri și chiar mai dificil de corectat într-un cadru concomitent. Dacă rămâneți conceptual apropiat de metal, vă lasă fără capacitatea de a abstract în moduri care vă permit să produceți codul de lucru mai rapid și vă încurajează să scrieți lucruri la un nivel care este dificil de paralelizat. Pe de altă parte, poate fi cel mai bun limbaj de programare a sistemelor dacă aveți nevoie să rulați pe hardware unde alte compilatoare sunt rare, sau dacă aveți nevoie să angajați programatori de nucleu.
Deși mă doare să-l spun, deoarece nu sunt de acord în mod fundamental cu mai multe aspecte ale designului său, poate doriți să aruncați o privire la Go. Se pare că criteriile lor de proiectare se aliniază destul de bine cu cerințele dvs.
Răspuns
Se pare că ceea ce căutați este un „limbaj” care vă oferă atât abstracții, cât și să nu vă faceți griji. despre complexitățile implicate (adică nu este nevoie să construiți concurență de la zero), totuși să fiți de asemenea performanțe ridicate și economice din punct de vedere al resurselor. Și pentru că este sarcina „sistemului”, ar trebui să fie capabil să se conecteze direct la tot hardware-ul. ceva în care cea mai mare parte a greutății grele este deja sortată (fie în limbajele limbii sau bibliotecile disponibile, sau poate ambele). De asemenea, ar avea nevoie de un compilator nativ în loc de o VM.
Dacă acest lucru este cazul în care nu sunt sigur de „cel mai bun”. Există multe alternative, chiar și multe din grupul mic pe care îl cunosc. Dacă doriți „cu adevărat” să ajungeți la „cel mai bun”, trebuie să generați o listă a tuturor limbilor – fără nici o preconcepție. Apoi începeți să rafinați prin omisiune – adică parcurgeți toate cerințele și omiteți (sau cel puțin treceți mai jos în listă) cele în care limba (sau instrumentele sale) sunt mai puțin decât adecvate cerinței.
Cerințele de abstractizare ar elimina cel mai probabil C și este asemănător din listă, probabil că noile actualizări la C ++ îl păstrează totuși în funcțiune.
Toate bazate pe VM ar eșua probabil într-un aspect sau altul (rețineți nu neapărat, dar ar fi nevoie de un fel de a face / converti cel puțin porțiuni din acestea în nativ). Deci, acele Java / PVM / DotNet / etc. familia de limbi poate fi omisă, de asemenea, probabil.
Legăturile hardware pot elimina destul de multe, deși rețineți că nu este imposibil să folosiți mai multe limbi (sau familii de limbi) pentru a vă deplasa această cerință. De exemplu, este chiar imposibil să folosești C pentru întregul teanc de sarcini de sistem – cel puțin o parte din porțiunile de boot din toate sistemele sunt scrise în asamblare, iar pe lângă acestea multe sisteme sunt scrise cu un nivel mai înalt deasupra Porțiuni „C”. În majoritatea cazurilor, este o situație de a folosi doar ceea ce este deja făcut și / sau de a adăuga la acesta folosind cele mai potrivite pentru acele locuri în care se încadrează. Deci, probabil (în același sens) puteți obține o bibliotecă / „plugin” care permite oricărei limbi să afecteze în mod direct hardware-ul. Indiferent dacă acest lucru elimină lucruri precum performanța sau economia resurselor, este o chestiune diferită care ar necesita testarea și gândirea alternativă a combinației (de exemplu, faceți o rutină de acces la disc atomic în C, care se numește de la un „fir” de actor în Lisp și, eventual, suportă fiecare apel atomic își folosește propriile resurse și, eventual, performanța se pierde din cauza apelurilor CFFI).
Și apoi elefantul alb (și motivul principal pentru care C este atât de omniprezent) sunt exemple: „Este mult mai dificil să încerc ceva în alt limbaj în care eșantioanele sunt greu de găsit sau chiar inexistente. Este întotdeauna extrem de dificil să fii primul care o face mai degrabă decât să faci același lucru, doar „în felul tău”.
Dacă urmați acest traseu, probabil că veți elimina foarte repede bucăți mari din acea listă enormă de limbi. Totuși, acțiunea care consumă mult timp ar fi investigarea fiecărei limbi pentru a afla cum se măsoară față de altele pentru fiecare dintre cerințe. Acesta este motivul pentru care majoritatea nu s-ar deranja și pur și simplu rămâneți cu ceva de genul C, deși (pe termen lung) poate însemna că ar putea face ceva „mai bun” mai repede.