Är språket Rust framtiden för inbyggda system?

[Icecap]

Det är faktisk sällan att verktygen gör en god mekaniker - men en bra mekaniker blir bättre med bra verktyg.

Att påstå att man bara ska byta språk för att lösa problemen är - i mina ögon - att inte riktigt greppa helheten.

Men var och en kan fritt välja vad som känns bäst för dom - man ska doch inte räkna med att andra har samma värdering.

Byt ut "programmeringsspråk" med "religion" och se vad du forsöker åstadkomma. Hos mig lär du ha lika mycket succes som Jehovas Vittnen (alltså nada) då du inte kommer med konkreta bevis på vilka problem Rust löser och som inte kan lösas på andra sätt.

[Findecanor]

Jag tror att det krävs ett större paradigmskifte för att C/C++/assembler/programspråk X skall gå i graven.

Erlang är på väg upp i web-världen. Det är ett funktionellt spåk, till skillnad från C, Pascal och efterföljare som är procedurella. Det utvecklades en gång i tiden för att köra på Ericssons telefonväxlar.

För tjugo år sen eller så så besökte jag en presentation på Tekniska Museet där ett litet svenskt företag jag vill minnas hette Carlsten presenterade en hårdvaruarkitektur för inbyggda system baserat på programmering i ett funktionellt språk baserat på en delmängd av Haskell. Den grundläggande datatypen var en tuple av värde och tidsstämpel. Ville man ha en fördröjning någonstans så lade man till på tidsstämpeln.

Jag tror att ersättarna för våra processorer om några decennier kommer att vara varianter av Dataflow architecture, som är massivt parallella på en lägre nivå istället för att ha diskrete kärnor. Det påminner mig lite om Carlstens idéer och också om att programmera FPGA:er att exekvera program.
För dessa så lämpar sig nog funktionella språk som Erlang mycket bättre än t.ex. C.

[Mr Andersson]

TS nämner saker som kontroll av overflow och arrayindexering.. Allt sånt kostar, det finns inget magiskt sätt att göra det gratis utan cpu-tid.

Nja, det finns processor-arkitekturer som har stöd för det olika overflow-kollar. Bl.a. MIPS har stöd för att trap:a (hårdvaru-exception) på overflow på 32-bittars och 64-bittars additioner och subtraktioner.
Jag har för mig att det ska finnas någon äldre arkitektur som har range-check på pekar/adress-operationer som skulle passa Pascal (men jag kanske har blandat ihop det med någon virtuell maskin...).

Men många processorarkitekturer har tyvärr varit designade för att köra C/C++ i första hand.
RISC-V har t.ex. inte ens något hårdvarustöd för carry-flagga (i.a.f. vanligtvis) så t.ex. bignum-aritmetik blir trögt på den plattformen.

Javisst finns det olika exceptions man kan nyttja, men man måste ju ändå skriva kod för hanteraren.
Om det dessutom ska vara inskrivet i språkstandarden så måste man antingen vara beredd på göra kontrollerna via mjukvara eller kraftigt begränsa vilka plattformar språket kan användas på.

[swesysmgr]

För tjugo år sen eller så så besökte jag en presentation på Tekniska Museet där ett litet svenskt företag jag vill minnas hette Carlsten presenterade en hårdvaruarkitektur för inbyggda system baserat på programmering i ett funktionellt språk baserat på en delmängd av Haskell. Den grundläggande datatypen var en tuple av värde och tidsstämpel. Ville man ha en fördröjning någonstans så lade man till på tidsstämpeln.

Är det Gunnar Carlstedt du tänker på?
https://dflund.se/~triad/papers/rp8601/ ... Teknik.pdf

Var nog mer än 20 år sedan.

[Krille Krokodil]

Intressant man.

– 1986 började jag med ett nytt projekt: framtidsdatorn rp8601. Det skulle vara en byggbara dator som passade allt och skulle minska många av de problem som fortfarande finns med dagens datorer.
[...]
Sedan Nicolin slutat ville Incentive inte arbeta med sådant. 1994 lades vi ned.
[...]
2015 tog jag på Ericsson begäran upp projektet igen på Chalmers och arbetar en dag i veckan sedan dess.

http://www.hn.se/livets-g%C3%A5ng/b%C3% ... -1.1776303

[Lennart Aspenryd]

Tack Krille, det var intressant läsning! Borde vara värd en Öl!
Och det kanske är runt detta som TS fråga skall behandlas Dvs i vilken miljö behövs ett bättre, snabbare, säkrare eller kompaktare språk!
Att ändra för änd ringens skull är väl inte produktivt!

[lillahuset]

Att ändra för änd ringens skull är väl inte produktivt!

Men ändå ganska vanligt.

[Findecanor]

Är det Gunnar Carlstedt du tänker på?
https://dflund.se/~triad/papers/rp8601/ ... Teknik.pdf

Var nog mer än 20 år sedan.

Jajamensann. Tack! Det var absolut någon gång i mitten av 90-talet de presenterade det. Jag har för mig att de berättade att de hade haft svårt att hitta investerare för det och att projektet var nerlagt.

[TomasL]

En gång i tiden tycte jag att OCCAM var rätt intressant, speciellt därför att Transputern hade hårdvarustöd för OCCAM.

[Lennart Aspenryd]

Trots allt, att tiden går och operativen består! Så gäller ju det som en eventuell arbetsgivare vill ha!
https://www.sydsvenskan.se/lediga-jobb/ ... -al=random
Kolla in detta och kom med kommentarer. Frågar de efter Rust eller Ada?

[TomasL]

Nej, det gör de inte, av den enkla anledningen att C och C++ funkar med alla processorer,
Man väljer alltid efter minsta gemensamma nämnaren., och C/C++ finns i princip för alla processorer, därför är alla andra språk totalt o-intressanta.

[lillahuset]

Naturligtvis inte. Men om 20-30 år kanske.
Om man tittar på vad som troligen är det viktigaste enskilda mjukvaruprojektet idag och troligen de närmaste 20 åren (eller mer) så är det skrivet i C.
Jag känner mig helt lugn med att C kommer att leva längre än jag.

[TomasL]

Eftersom man vill ha effektivt kompilerad kod i embedded-system, och helst inte vill ha en pseudokod med en runtime, så är det i princip C/C++ som gäller.
Detta då man alltid kostnadsoptimerar hårdvaran.

[lillahuset]

TomasL: Det beror naturligtvis på vilken miljö man programmerar för. Vi halvtöntar programmerar embedded och då är C oftast ett bra val.
Sedan finns det allvarliga män och kvinnor i vita rockar som hanterar system från tex IBM och där gissar jag att C klassas som något katten släpat in. Vete f-n vad de använder för språk. COBOL? APL?

[TomasL]

Jo, men embedded brukar väl vara typ, minnessvaga MIPS, PIC, ARM osv, eller långsamma 8051 varianter.
Där man måste hushålla med resurser, eller få effektiv snabb kod.