mikrocontroller.net

Forum: PC-Programmierung Rust - ist das hier um zu bleiben?


Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich lese mir gerade das Rust Tutorial durch:
https://doc.rust-lang.org/rust-by-example/index.html

Das ganze hört sich ganz nett an, und ich überlege mir, ob ich von C 
nach Rust wechseln soll.

Was mich aber noch etwas zurück hält:

Wenn ich ein c99 oder c11 konformes Programm schreibe, dann weiss ich, 
dass es in 10 Jahren immer noch zahlreiche freie Compiler geben wird, 
die das problemlos übersetzen können, und das immer noch alles wichtige 
in C geschrieben ist, und das die Sprache inzwischen nicht gros verhunzt 
wurde.

Aber in Rust gibt es momentan nur den einen Compiler und es ist noch 
nicht sauber spezifiziert. Die menge an Rust Anwendungen hält sich auch 
noch in grenzen.

Was meint ihr, ist es sicher, auf Rust zu setzen? Ist Rust in 10 Jahren 
immer noch da? Oder wird es sogar mehr Compiler geben? Werden heutige 
Programme dann immernoch unverändert gehen? Und wird die Sprache nicht 
mit allem möglichem unnötigem kram vollgepackt werden, wie es bei C++ 
passierte?

Und wird es für das ding vielleicht auch endlich bald mal ein stabiles 
ABI geben?

Autor: Vancouver (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Was soll man darauf antworten? Es kann niemand in die Zukunft schauen.

Dass Python nach vielen Jahren sein Mauerblümchendasein verlässt und 
einen solchen Erfolg hat, konnte auch niemand vorhersehen. Andere 
Sprachen sind wieder in der Versenkung verschwunden, wie z.B. das 
unsägliche Oberon in den 90ern, obwohl es damals wie verrückt gehypt 
wurde.

Sagen wir mal so: Jetzt komplett von C nach Rust zu wechseln ist sicher 
keine gute Idee. Aber das eine oder andere Projekt mal mit Rust zu 
versuchen kann sicher nicht schaden.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das Problem: "Entscheidung für eine Programmiersprache" in 
Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig).

ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder 
neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige 
andere zu kennen.
Ohnehin sind sich Sprachen eines Paradigmas (etwa imperative etcpp.) 
jeweils untereinander syntaktisch sehr ähnlich.
Das Problem der Verfügbarkeit tritt dann (fast) gar nicht auf.
Dadurch aktiviert und übt man aber auch verschiedene Denkweisen.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Moin,

Bisher hab' ich zwar nix selber in rust programmiert, aber schon genug 
Malheur im Rahmen von BLFS/ Bau von firefox gehabt. Mein Eindruck ist, 
dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code 
ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang, 
rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt, 
klemmts ganz arg.
Ich find's schon ein Unding, dass das bei C++ so ein Rumgefuhrwerke ist, 
alten Code mit neueren Compilern bauen zu koennen, aber da gehts um 
Jahre und nicht wie bei rust um Monate, wo das Zeugs sich schon nicht 
mehr bauen laesst.

Gruss
WK

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Ich find's schon ein Unding, dass das bei C++ so ein Rumgefuhrwerke ist,
> alten Code mit neueren Compilern bauen zu koennen, aber da gehts um
> Jahre und nicht wie bei rust um Monate, wo das Zeugs sich schon nicht
> mehr bauen laesst.

Ja, skandalös dass neuere Compiler-Versionen besser darin werden 
Programmierfehler zu finden und einen am Debuggen hindern...

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Ich würde das Problem: "Entscheidung für eine Programmiersprache" in
> Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig).

Ich will schon, dass die Programme die ich schreibe und veröffentliche, 
auch in Zukunft noch jemandem nützen konnten.

> ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder
> neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige
> andere zu kennen.

Ich kann und kenne schon einige. Das ist natürlich wahr, es ist nie 
falsch, eine Sprache zu Lernen.

Dergute W. schrieb:
> Mein Eindruck ist,
> dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code
> ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang,
> rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt,
> klemmts ganz arg.

Oh, das wusste ich nicht. Ich hatte gehofft, nach 8 Jahren währe man da 
etwas weiter. Dann beobachte ich das vielleicht doch lieber noch zuerst 
ein par Jährchen.

Autor: Silvano C. (silch12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Dergute W. schrieb:
>> Mein Eindruck ist,
>> dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code
>> ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang,
>> rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt,
>> klemmts ganz arg.
>
> Oh, das wusste ich nicht. Ich hatte gehofft, nach 8 Jahren währe man da
> etwas weiter. Dann beobachte ich das vielleicht doch lieber noch zuerst
> ein par Jährchen.

Da bin ich anderer Meinung.
Durch den Paketmanager Cargo weiss der Compiler genau, welche 
Bibliotheken sicher laufen, welche Updates der Bibliotheken zu der 
aktuellen kompatibel usw. sind.
Der Rust Code an sich ist rückwärtskompatibel, d.h. Code in einerer 
früheren Version (ab 1.0, davor war beta) wird garantiert von neuen 
Compiler auch "verstanden".

: Bearbeitet durch User
Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Silvano C. schrieb:
> Da bin ich anderer Meinung.
> Durch den Paketmanager Cargo weiss der Compiler genau, welche
> Bibliotheken sicher laufen, welche Updates der Bibliotheken zu der
> aktuellen kompatibel usw. sind.
> Der Rust Code an sich ist rückwärtskompatibel, d.h. Code in einerer
> früheren Version (ab 1.0, davor war beta) wird garantiert von neuen
> Compiler auch "verstanden".

Ich glaube es ging eher darum, das der Compiler selbst sehr Problem 
anfällig bezüglich seiner eigenen Kompilierung sei, und nicht darum, wie 
anfällig die Rust Programme währen, wenn man den Compiler mal hat. Wenn 
man den Compiler mal irgendwann nicht mehr bauen können sollte, nützt es 
einem nichts, wenn das Programm noch liefe, wenn man den Compiler um 
dieses zu bauen denn noch bauen könnte.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Ich würde das Problem: "Entscheidung für eine Programmiersprache" in
> Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig).

Das sehe ich etwas anders. Als ich mich damals(tm) im Jahr 2004 
selbstständig machte, war ein guter Freund von mir gerade ein großer 
Smalltalk-Fan und -Verfechter. Er versuchte fast täglich, mich dazu zu 
überreden, auch exklusiv mit Smalltalk zu entwickeln und alle alten 
Zöpfe abzuschneiden. Auf meine Nachfrage, für welche Microcontroller es 
denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen 
Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für 
einige ARM-Prozessoren zu unterstützen. Super.

Und entgegen seiner damaligen Prophezeiungen ist Smalltalk immer noch 
nicht aus seiner Nische herausgekommen.

Es ist generell ein falscher Weg, nur noch auf ein einzelnes Pferd zu 
setzen, insbesondere wenn dessen Mutter noch gar nicht richtig schwanger 
ist.

> ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder
> neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige
> andere zu kennen.

Ja, so etwas ist sehr wichtig. Leider erlebe ich es auch bei manchen 
Kunden immer wieder, dass ausgerechnet die Leute mit den größten 
Scheuklappen diejenigen sind, die Architekturen mit seit zwanzig Jahren 
schwächelnden Konzepten entwerfen. :-/ Ein kleiner Blick auf andere 
Programmiersprachen und deren Konzepte würde völlig ausreichen, um zu 
erkennen, dass gigantisch verschnörkelte C-Präprozessor-Makros nicht 
mehr zeitgemäß sind, um damit halbwegs zukunftssichere APIs zu 
definieren.

Autor: Silvano C. (silch12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Auf meine Nachfrage, für welche Microcontroller es
> denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen
> Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für
> einige ARM-Prozessoren zu unterstützen. Super

Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend 
setzt

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silvano C. schrieb:
> Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend
> setzt

Auch schon im Jahr 2004?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moin,

Silvano C. schrieb:
> Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend
> setzt

Naja, mal gucken: Fuer ein C Programm brauchst du z.b. einen 
gcc+binutils. gcc ist abhaengig von (Kernel und einer) libc.
Um einen llvm zu bauen,brauchste python, cmake und einen gcc. Also 
mindestens schon einen c++ compiler, sonst wirds nix mit cmake 
(wahrscheinlich auch fuer Python). Python hat die angenehme Eigenschaft, 
in Geschmacksrichtung (2 und 3) herzukommen; im Zweifelsfall brauchts 
dann auch immer beide.

Um rust zu bauen brauchste llvm und einen riesenhaufen Zeugs, der so 
riesig und komplex ist, dass das automatisch irgendwie von irgendwoher 
runtergeladen werden muss. Und dann noch diversen anderen, nicht so 
exotischen Kram wie auch wieder Python und libssh.

Jetzt kann man sich natuerlich als z.B. Ubuntu-Aeffchen auf den 
Standpunkt stellen: Ist mir alles wurscht. Ich hab's voll drauf, denn so 
wie Windowsprofis auf jede setup.exe klicken koennen, kann ich ja 
einfach "sudo apt-get gedoens" tippern und alles wird immer gut!einself!

Aber wenn man dann und wann auch mal Software fuer nicht-mainstream 
Platformen haben will, kann's schonmal beliebig bloed werden mit dem 
Herbeizaubern einer (ggf. cross-)toolchain und was man sonst noch an 
Umgebung braucht. Und da bin ich persoenlich echt froh, wenn's nicht so 
irrsinnig ausufert, nur weil unbedingt irgendwer irgendwelchen heissen 
Scheiss ausprobieren musste.
Aber das ist nur meine kleine, beschraenkte Meinung, Profi-Informatiker 
sehen das sicherlich ganz anders.

(Ocaml war glaub' ich auch mal ziemlich hipp, iirc gabs irgendwelches 
Filesharing-Zeugs was in Ocaml geschrieben war.)

Gruss
WK

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> und wann auch mal Software fuer nicht-mainstream Platformen haben will,
> kann's schonmal beliebig bloed werden mit dem Herbeizaubern einer (ggf.
> cross-)toolchain

Konnte nicht eine LLVM-Installation automatisch für alle Targets Code 
generieren?
Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy 
Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist 
auch ganz schön zum Haare raufen.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Konnte nicht eine LLVM-Installation automatisch für alle Targets Code
> generieren?
> Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy
> Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist
> auch ganz schön zum Haare raufen.

Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt 
nicht für jede Architektur einen eigenen Build. Mal abgesehn von der 
Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr 
(legacy) Abhängikeiten als LLVM und rustc.

Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen 
daran weil die Community über die "critical mass" hinaus gewachsen ist 
und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr 
attraktiv sein wird.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Dr. Sommer schrieb:
> Einen GCC mit allen benötigten libc-Varianten zu bauen ist
> auch ganz schön zum Haare raufen.

Eigentlich reicht ja eine. Aber OK, auch die kann schmerzhaft sein. Nur, 
wenn das schon nicht klappt, wie wirds dann llvm und "schlimmeres" 
geben?

Vincent H. schrieb:
> Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt
> nicht für jede Architektur einen eigenen Build.
Das klingt interessant. Haste mal ein Beispiel, wie man so auf die 
Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein 
HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren 
kann?

> Mal abgesehn von der
> Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr
> (legacy) Abhängikeiten als LLVM und rustc.
OK, und was waeren das fuer "(legacy) Abhängigkeiten"?

Vincent H. schrieb:
> Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen
> daran weil die Community über die "critical mass" hinaus gewachsen ist
> und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr
> attraktiv sein wird.

Naja, die verwendete Sprache sollte halt zum zu loesenden Problem 
passen. Da kanns schon sein, dass jetzt moderner Webkram mit Rust die 
tollste Wurst ist.
Ich sag' nochmal: Wenn man sicher ist, sich jederzeit mit "sudo apt-get 
install", setup.exe oder aehnlich "evelynesken" Kommandos die benoetigte 
Umgebung herzaubern kann, dann ist das alles simpel.

Nachdem aber im Eroeffnungspost explizit ein Zeitraum von 10 Jahren 
angegeben wurde, hab' ich halt so meine Zweifel an rust. Aber natuerlich 
kann ich nicht in die Zukunft blicken, nur aus der Vergangenheit 
versuchen zu interpolieren...

Gruss
WK

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Das klingt interessant. Haste mal ein Beispiel, wie man so auf die
> Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein
> HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren
> kann?

Man muss dem Compiler lediglich das Target als flag übermitteln. Also in 
etwa so:
--target=arm-none-eabi -march=armv7e-m

Default ist natürlich x86.

> OK, und was waeren das fuer "(legacy) Abhängigkeiten"?

isl und gmp fallen mir da ein...
und da gabs noch ein paar so lustige Acronmy wo man sich erstmal denkt 
"hä?"
Und wenn man schon auf Python rumhakt. Braucht GCC nicht Perl?

: Bearbeitet durch User
Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Theor schrieb:
>> Ich würde das Problem: "Entscheidung für eine Programmiersprache" in
>> Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig).
>
> Das sehe ich etwas anders. [...]

Möglicherweise ist eine Klarstellung angebracht: Mit "die Entscheidung 
ignorieren" meine ich, keine Entscheidung davon abhängig zu machen; 
keine Entscheidung zu treffen. Nicht trotz des fehlenden Wissen von der 
Zukunft eine Entscheidung dafür oder dagegen zu treffen, diese Sprache 
vorzugsweise oder als einzige zu benutzen.
Andernfalls beschreibt Dein Smalltalk-Beispiel genau, was ich meine: 
Weder für noch gegen Smalltalk allein entscheiden.

Mal abgesehen davon finde ich Smalltalk als Sprache gut. Mir doch egal, 
ob das in einer Nische hockt oder nicht.

> [...]
>> [...]

> Ja, so etwas ist sehr wichtig. Leider erlebe ich es auch bei manchen
> Kunden immer wieder, dass ausgerechnet die Leute mit den größten
> Scheuklappen diejenigen sind, die Architekturen mit seit zwanzig Jahren
> schwächelnden Konzepten entwerfen. :-/

Was meinst Du konkret damit? Welche Konzepte? Welche Sprache?

Das sind Meinungsfragen, keine absoluten, objektiven Werte. Solange eine 
Konzept stringent ist und die so geschriebenen Codes einigermaßen 
beweisbar und deterministisch tun was sie sollen, ist das alles ein 
Streit um des Kaisers Bart.

Die Realität ist doch eher so, dass es potentiell so viele 
Programmiersprachen gibt, wie es Vorstellungen von der programmatisch 
kontrollierten Wirklichkeit gibt. Gibt ja auch Sprachen die das aktiv 
unterstützen - etwa FORTH, oder mit Operator-Overloading eben auch C++ 
u.a.

> Ein kleiner Blick auf andere
> Programmiersprachen und deren Konzepte würde völlig ausreichen, um zu
> erkennen, dass gigantisch verschnörkelte C-Präprozessor-Makros nicht
> mehr zeitgemäß sind, um damit halbwegs zukunftssichere APIs zu
> definieren.

Darum ging es ja gar nicht. Nicht darum Sprachen zu entwerfen, sondern 
sie zu benutzen. Und worauf bezieht sich Architektur? Meinst Du 
eigentlich "Paradigma"?
Abgesehen davon, ist mir unklar, was "Verschnörkelungen" mit C-Makros zu 
tun haben und die wiederum mit "Architektur" oder "Paradigma".

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Vincent H. schrieb:
> Man muss dem Compiler lediglich das Target als flag übermitteln. Also in
> etwa so:
>
Hmmmm....
echo "main() {}" > hello.c
clang  hello.c #OK, da faellt ein a.out raus.
clang -target arm-none-eabi hello.c 
error: unable to create target: 'No available targets are compatible with this triple.'

Hm, ok - also was kann denn mein clang fuer Targets?

Uuupsi:
https://stackoverflow.com/questions/15036909/clang-how-to-list-supported-target-architectures

Scheint garnicht so simpel zu sein, das rauszukriegen...(Bloss gut dass 
ich ihn selbergebaut hab', da weiss ich's noch).
Es ist also keinesfalls so, dass da automatisch immer alle crosscompiler 
mitdrinnen sind. Das muss beim Bau angegeben sein.

Und genau solche Sachen erzeugen bei mir die Skepsis. Jeder blubberts 
nach, weils irgendwo steht, aber wenn man's dann wirklich ausprobieren 
will, wirds schnell zaeh'.

Vincent H. schrieb:
> isl und gmp fallen mir da ein...
OK, ohne isl und diverse andere Gimmicks lassen sich sehr wohl gccs 
bauen.

mpfr, gmp, mpc - ja klar, irgendwie muss der compiler konstante 
Ausdruecke ja auch berechnen koennen. Ich wuesst' nicht, wie llvm ums 
berechnen beim compilieren rumkommt. Vielleicht macht er's so wie alte 
gccs und hat den ganzen Schmonz irgendwo festeingebaut.

Ich sag' mal: An dem Tag, wo ein LFS/BLFS artiges Projekt rauskommt, bei 
dem nicht mit gcc usw. angefangen wird, sondern mit rustc und mit dem 
dann llvm und danach evtl noch gcc gebaut wird - da bin ich auch 
ueberzeugt, dass rust eine tolle Dauerwurst ist. vorher eher noch nicht 
:-)


Gruss
WK

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn BLFS und Co für dich die Messlatte für etablierte Sprachen ist, 
dann wirst du am Sterbebett noch mit K&R C zu tun haben (müssen). ;)

Dafür dass du bei deinen Builds alle Targets rausnimmst kann ja ich nix.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Eigentlich reicht ja eine

Eine für Soft float, eine für vfp4-sp-d16, eine für vfp4-dp-d16, 
vfp3-sp-d16, ...

Dergute W. schrieb:
> moderner Webkram mit Rust

Rust ist nicht für Web. Das ist für performante Low-Level Codes. Also 
hauptsächlich als C und C++ Ersatz.

Und wenn man unbedingt ein LLVM für ein exotisches Target/Host bauen 
will, kann man das ja unter einem Ubuntu tun, wo man alles per apt-get 
installiert hat. Wenn man's richtig macht läuft das dann überall.

Das Build Script für den GCC-ARM-Embedded ist auch ein paar kLoC lang. 
Ist wohl doch nicht so einfach. Den Rattenschwanz an Dependencies lädt 
es manuell runter. Es funktioniert auch nur unter Ubuntu, und nur unter 
32bit. Executables für Win64 kann es nicht erstellen. Da ist auch nicht 
alles in Butter...

Autor: Kaj (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Von rust werden momentan diese Architekturen unterstuetzt:
$ rustup target list
aarch64-apple-ios
aarch64-fuchsia
aarch64-linux-android
aarch64-pc-windows-msvc
aarch64-unknown-cloudabi
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armebv7r-none-eabi
armebv7r-none-eabihf
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv7-apple-ios
armv7-linux-androideabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabihf
armv7r-none-eabi
armv7r-none-eabihf
armv7s-apple-ios
asmjs-unknown-emscripten
i386-apple-ios
i586-pc-windows-msvc
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-apple-darwin
i686-linux-android
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu
i686-unknown-linux-musl
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips64-unknown-linux-gnuabi64
mips64el-unknown-linux-gnuabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
riscv32imac-unknown-none-elf
riscv32imc-unknown-none-elf
s390x-unknown-linux-gnu
sparc64-unknown-linux-gnu
sparcv9-sun-solaris
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
wasm32-unknown-emscripten
wasm32-unknown-unknown
x86_64-apple-darwin
x86_64-apple-ios
x86_64-fuchsia
x86_64-linux-android
x86_64-pc-windows-gnu (installed)
x86_64-pc-windows-msvc
x86_64-rumprun-netbsd
x86_64-sun-solaris
x86_64-unknown-cloudabi
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu (default)
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-netbsd
x86_64-unknown-redox

AVR soll auch unterstuetzt werden, sobald das AVR Backend fehlerfreier 
ist. Solange gibt es das avr-rust projekt.

Der Buildprozess ist mit cargo super angenehm. Man hat eine gewisse 
Sicherheit was Rebuild-Sicherheit angeht, da alle veroeffentlichen 
Versionen eines Crates immer wieder runterladbar sind. Man kan alte 
Versionen extra markieren, womit diese nicht mehr fuer neue projekte 
verwendet werden koennen, aber fuer alte projekte erhalten bleiben.
Arbeitet man mit den Crates von crates.io dann ist auch die verwaltung 
der abhaengigkeiten sehr einfach. Das Oekosystem ist meiner Meinung nach 
das groesste Plus bei Rust.

Durch die Gestaltung von Rust ist der Code sehr aussagekraeftig.
fn main() {
    let mut _x: u8 = 255;
    _x += 1;
}
Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5

Schreibt man das ganze so:
fn main() {
    let mut _x: u8 = 255;
    _x = _x.wrapping_add(1);
}
ist alles gut und man bekommt seinen ueberlauf. Die Sprache schuetzt zum 
einem vor dem Fehler von ungewollten ueberlaeufen, und zum anderen 
bietet sie die moeglichkeit eines gewollten ueberlaufs, was man dann 
aber auch so im code ausdruecken muss. Das traegt doch ungemein zum 
verstaendis von fremdcode bei. Neben wrapping_add() gibt es noch andere 
funktionen, die einem dann auch noch sagen ob es einen ueberlauf gab. 
Wie viele threads gibt es hier, wo sich drueber gestritten wird wie man 
in c oder c++ am besten und sichersten einen ueberlauf feststellt...

Die generierte Doku gefaellt mir deutlich besser, als das was ich bisher 
bei anderen Sprachen gesehen habe.

Unit-Tests (und auch benchmark-tests) sind gleich mit dabei, und man 
kann auch private Methoden testen, ohne sich einen abbrechen zu muessen. 
Mit rustfmt kann man den Code entsprechend den Rustguidlines formatieren 
lassen. Unter Visual Studio Code laesst sich Rust genauso einfach wie C 
oder C++ debuggen.

Ja, einige konzepte sind sehr ungewoht wenn man von c/c++ kommt (hallo 
borrow-checker, mein freund...), aber das ist okay.

Es gibt praktisch keinen Grund, Rust nicht mal wenigstens eine 
ernsthafte chance zu geben. Und mit ernsthaft meine ich, dass man sich 
schon mal 1 Monat etwas intensiver mit Rust beschaeftigt haben sollte.

Meiner Meinung nach ist Rust die beste alternative zu C und C++, wenn es 
um low-level geht, besonders weil sie auch viele embedded targets 
unterstuetzt. Ebenso denke ich, das Rust in zukunft noch eine grosse 
Rolle spielen wird, wenn es um sichere Software geht.

Ja, Rust ist gekommen um zu bleiben.

Autor: Nano (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Rust wird bleiben, da die Lizenz von LLVM frei genug ist um LLVM auch in 
proprietärer Software einzubauen und somit den langfristigen Support von 
LLVM und seiner Front- und Backends auch durch Firmen mit Geld in der 
Tasche und Manpower sicherzustellen.
Ein paar Dutzend an Compilern braucht es zum überleben der Sprache also 
da gar nicht zwingend, obwohl es die sicher auch geben wird, sondern nur 
die richtige Lizenz für den Marktrelevanten Compiler.

Zum Vergleich bei Java nimmt man für die x86 Architektur entweder den 
Compiler von Oracle Java oder OpenJDK und dann kommt eine Weile nichts 
mehr, obwohl es noch andere Implementationen gibt.
Bei C# ist es nicht viel anders.

LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz 
das alles alleine stemmen können und das auch langfristig.

Außerdem werden die Backends, also der Teil der den 
architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust 
Frontent komplett unabhängig entwickelt.
Allein das sorgt schon dafür das die Entwicklung weitgehend 
zukunftsicher ist, es müssen sich nur genug Leute finden die das 
Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch 
Firmen mit ins Boot holt gesichert.

Dazu kommen noch die Vorteile der Sprache selbst bezüglich 
Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für 
Programmierer extrem attraktiv macht.

Ich mache mir da keine Sorgen. Zum Vergleich, die Zukunftsicherheit von 
bspw. D ist weit weniger gewiss.

Autor: Silvano C. (silch12)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz
> das alles alleine stemmen können und das auch langfristig.
>
> Außerdem werden die Backends, also der Teil der den
> architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust
> Frontent komplett unabhängig entwickelt.
> Allein das sorgt schon dafür das die Entwicklung weitgehend
> zukunftsicher ist, es müssen sich nur genug Leute finden die das
> Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch
> Firmen mit ins Boot holt gesichert.
>
> Dazu kommen noch die Vorteile der Sprache selbst bezüglich
> Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für
> Programmierer extrem attraktiv macht.

Sehe ich genauso.

Mittlerweile nutzen einige Programmiersprachen (respektive deren 
Compiler) LLVM:
-ActionScript
-Ada
-C#
-Common Lisp
-Crystal
-CUDA
-D
-Delphi
-Fortran
-Graphical G Programming Language
-Halide
-Haskell
-Java bytecode
-Julia
-Kotlin
-Lua
-Objective-C
-OpenGL Shading Language
-Pony
-Python
-R
-Ruby
-Rust
-Scala
-Swift
-Xojo
(https://en.wikipedia.org/wiki/LLVM)

Ich denke also nicht das LLVM so schnell verschwinden wird.
Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese 
zum bleiben einladen:
-Firefox (zu mindestens Teile davon, bald auch die WebEngine)
-Microsoft Azure
-Stratis
-Railcar

Kaj schrieb:
> Ja, Rust ist gekommen um zu bleiben.

Das denke ich auch

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Silvano C. schrieb:
> Mittlerweile nutzen einige Programmiersprachen (respektive deren
> Compiler) LLVM:

Und natürlich auch C und C++! Clang ist eine ernstzunehmende Konkurrenz 
für GCC. Man könnte sogar sagen dass die Konkurrenz durch Clang die 
Entwicklung von GCC sogar auch beschleunigt hat...

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silvano C. schrieb:
> Ich denke also nicht das LLVM so schnell verschwinden wird.
> Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese
> zum bleiben einladen:
> -Firefox (zu mindestens Teile davon, bald auch die WebEngine)
> -Microsoft Azure
> -Stratis
> -Railcar

Mittelfristig wird sicherlich noch Thunderbird dazukommen.

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wuerde sagen: Rust ist wie C/C++, nur in "besser" -> mit weniger 
(Laufzeit)-Fallstricken und an die Zeit angepasst. Eine low level 
Sprache bei der man erkennen kann: Ja, wir haben aus den letzten 40 
Jahren Softwareentwicklung etwas gelernt (auch wenn es mit sicherheit 
nicht perfekt ist).

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Entwicklung von Rust begann 2006, also vor 13 Jahren und wird seit
2009 von Mozilla gesponsort. Seit 2012 gibt es offizielle Releases mit
Versionsnummer. Das angehängte Diagramm zeigt die Veröffentlichungsdaten
der Minor-Releases (d.h. mit einer Versionsnummer der Form x.y oder
x.y.0) seit 2012. Man sieht, dass die Release-Frequenz stetig zunimmt.
Allein letztes Jahr gab es 18 Releases, also etwa alle 20 Tage eines.

Das ist ein starkes Indiz dafür, dass sehr intensiv an dem Projekt
gearbeitet wird. Ein Projekt, wo 13 Jahre lang so viel Arbeit
hineingesteckt wurde, kommt nicht so schnell zum Stillstand. Laut Github
arbeiten 88 Leute daran, so dass auch der Ausfall einzelner Personen
kein unüberwindliches Problem darstellen sollte. Selbst wenn Mozilla die
finanzielle Förderung einstellen sollte, wird das die Entwicklung zwar
verlangsamen, ich kann mir aber nicht vorstellen¸ dass sich die
Entwickler komplett aus dem Projekt zurückziehen und damit ihre
langjährigen Arbeit in die Tonne treten werden.

IMHO wird Rust innerhalb der nächsten 10 Jahre nicht eine der
Mainstream-Sprachen werden wie heute bspw. C, C++, Java und Python, es
wird aber sehr wahrscheinlich "Marktanteile" hinzugewinnen. Aussterben
(in dem Sinne, dass Compiler und Bibliotheken nicht mehr gepflegt
werden) wird es nicht, da bin ich mir ganz sicher.

Autor: DPA (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ich bin gerade dazu gekommen mal ein simples "Hello World" Programm mit 
C, C++ und Rust in einer Anwendung zu machen, um zu sehen, wie gut das 
geht, und um einen Eindruck zu bekommen, ob es beim Build irgendwelche 
problematischen Dinge gibt. Es geht grundsätzlich, aber es gibt 2 
Problematische Sachen:

 1) Das erste ist eigentlich kein Rust Problem, sondern etwas, das 
eigentlich alle C, C++, Rust, etc. Compiler betrifft: Die Compiler 
bilden ein Wrapper für den Linker, und der Linker ist dadurch fast nicht 
mehr Standalone verwendbar, weil man beim Aufruf die Runtimelibraries 
der Sprachen, Systemweit verwendete libraries wie die jeweilige ld.so 
kennen muss, und noch viele weitere Optionen. Man kann einen der 
Compiler als Wrapper verwenden, bestenfalls der in dessen Sprache die 
main geschrieben wurde, und dann die anderen Runtimes dazu linken. gcc, 
g++, clang und clang++ haben derart ähnliche Optionen, und bieten derart 
gute Möglichkeiten Optionen zum Linker weiterzureichen, dass mich das 
dort nicht sehr gestört hat. Wenn jetzt aber noch rustc dazu kommt, mit 
komplett anderen Optionen, die viel mehr high-level sind und weniger 
low-level zeug erlauben, wird es langsam zum Problem, insbesondere, da 
vermutlich nicht vorgesehen ist, das ohne cargo so zu verwenden. Ich 
muss irgendwann mal eine standalone linker-wrapper Anwendung erstellen, 
der man einfach sagen kann, linker X, runtimes für rust&c&c++, entry 
point mit runtime X behandeln, und dann die restlichen linker Optionen 
an den Linker weitergeben, und womöglich noch ein allgemeines subset der 
Optionen bieten. Das würde das Problem lösen, und währe vermutlich auch 
nicht schwer umzusetzen, jedoch müssten es die Compiler/Linkerbauer 
sowie die Distributionen dann vermutlich in ihre Packages der jeweiligen 
Linker miteinbeziehen, damit es immer reibungslos verwendbar würde, was 
eher unwahrscheinlich ist.

 2) Das zweite Problem ist auch nicht direkt Rust, sondern cargo. Es ist 
nicht so, dass man rust nicht (noch) ohne cargo verwenden könnte, aber 
es ist klar, dass die Verwendung von rust mit cargo die einzige 
"normale" Nutzung von rust ist, und anderes nicht wirklich vorgesehen 
ist. Mein Problem mit Cargo ist wieder zweierlei:
 a) Es ist ein build tool (ähnlich wie make, cmake, automake, etc.) aber 
auch ein Package Manager. Es ist nicht vorgesehen, cargo nur als 
Packagemanager zu verwenden, und ein anderes, bestehendes build 
automations tool, die bei vielen anderen Sprachen zum Einsatz kommen, zu 
verwenden. Zudem wird die Projektstruktur zu einem gewissen grad 
vorgegeben. Das führt zu unnötigen Komplikationen, wenn man ein anderes 
build tool verwenden will, oder einzelne Rust quellen in ein bestehendes 
nicht-rust Projekt integrieren will.
 b) crates.io. Gut, das Problem haben npm und pip auch. Ja, man kann 
direkt auf ein Verzeichnis oder auf ein Git repo verweisen, und man 
könnte wohl auch irgendwie andere Registries angeben. Aber crates.io ist 
der default. Es steht nirgends, wer es betriebt. Vermutlich Mozilla? Es 
gibt keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es 
vollständig zu Mirroren. Die meisten Programme werden Dependencies 
darauf haben. All dies macht es zu einem gefährlichen Single point of 
failure.

Das alles ist jetzt noch nicht allzu tragisch, aber ich muss das bei 
zukünftigen Ernsthafteren Projekten im Auge behalten & Gegenmassnahmen 
treffen.

Mein "Hello World" versuch ist im Anhang. Ihr müsst vermutlich im 
makefile die Nummer beim "-lstd-df4a2aaeab5f3a68" anpassen (ist ein Teil 
der rust standard library). (Einfach mit ls -1 
/usr/lib/x86_64-linux-gnu/libstd-*.so nachsehen.)

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Code von crates.io kannst du forken und wie das mit den Mirrors geht 
steht auch auf der Github Seite von crates.io

https://github.com/rust-lang/crates.io

Deploying & using a mirror
https://github.com/rust-lang/crates.io/blob/master/docs/MIRROR.md#deploying--using-a-mirror

Und wie man ein crates.io lokal laufen laesst steht unter contributing:
https://github.com/rust-lang/crates.io/blob/master/docs/CONTRIBUTING.md
Once you have a local instance of crates.io running at 
http://localhost:4200 by following the instructions in the 
"Working on the Backend" section, you can go to another Rust project 
and tell cargo to use your local crates.io instead of production.


Warum es Cargo gibt, und warum das Paketmanager und Buildtool in einem 
ist (und warum das nutzen ohne Cargo nicht wirklich vorgesehen ist), ist 
auch schnell geklaert:

https://doc.rust-lang.org/cargo/guide/why-cargo-exists.html#why-cargo-exists
Cargo is a tool that allows Rust packages to declare their various 
dependencies and ensure that you’ll always get a repeatable build.

To accomplish this goal, Cargo does four things:
    Introduces two metadata files with various bits of package information.

    Fetches and builds your package’s dependencies.

    Invokes rustc or another build tool with the correct parameters to
    build your package.

    Introduces conventions to make working with Rust packages easier.

Das wichtige: "ensure that you’ll always get a repeatable build"

Das ist etwas, ueber das sich zu wenig leute gedanken machen. Auch ist 
das ein Thema, das nicht ganz trivial ist (siehe Google oder Debian als 
Beispiele).

DPA schrieb:
> Aber crates.io ist der default.
Der default, um ein Paket offiziell zu veroeffentlichen, damit das alle 
mitbekommen (zumindestens die, die auf crates.io gucken). Das ist ja 
aber nur eine Kopie. Den Code selbst kannst du irgendwo hosten, oder 
auch einfach nur auf deiner Platte liegen lassen (lokales crates.io oder 
ganz ohne crates.io).

Ein default wie crates.io finde ich aber immernoch besser, als gar 
nichts wie es bei C/C++ der Fall ist. Da wird was auf Github/Gitlab/etc. 
hochgeladen, und keiner bekommt es mit.
Bei crates.io erscheinen Pakete die neu sind, oder aktualisiert wurden 
auf der Hauptseite. Dadurch steigt die wahrscheinlichkeit das ein Paket 
gesehen wird. Ebenso verringert das zusammenspielen von crates.io und 
Cargo die wahrscheinlichkeit, das fuer neue Projekte veraltete 
(fehlerhafte) Libs verwendet werden.

https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#removing-versions-from-cratesio-with-cargo-yank
Although you can’t remove previous versions of a crate, you can prevent 
any future projects from adding them as a new dependency. This is useful 
when a crate version is broken for one reason or another. 
In such situations, Cargo supports yanking a crate version.

Yanking a version prevents new projects from starting to depend on 
that version while allowing all existing projects that depend on it 
to continue to download and depend on that version.

Auch etwas, das es so bei anderen (mir bekannten) Sprachen nicht gibt.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cargo als Paketmanager ist nett für
a) Windows-Nutzer, denn da muss der Anwender sowieso irgendwie mit der 
DLL-Hölle leben

b) Entwickler, die sich nur um eine spezifisch gepflegte Zielplattform 
kümmern müssen (z.B. die speziell für diese Applikation gedachten 
Cloudserver)

Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib 
möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können 
willst, dann macht Dir das cargo das Leben schwerer als nötig.

Das zentral Vorhalten und gemeinsam Aktualisieren ist vom Aspekt der 
Sicherheitspflege ein ganz entscheidender Punkt. Ich als Admin der eine 
solche Distribution nutzt, kann so ganz einfach prüfen was für einen 
Stand, Patchlevel,... eine bestimmte Lib hat und es verstecken sich eben 
nicht noch 20 andere Kopien der selben Lib in unterschiedlichen 
Versionen als .so oder statisch gelinkt auf der Platte.

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib
> möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können
> willst, dann macht Dir das cargo das Leben schwerer als nötig.
Und was hat das jetzt mit cargo zu tun?

Man kann mit rust genauso libs bauen wie mit C und C++ (bzw. mit gcc & 
co.). Und wenn die Lib ueber den distrubitionseigenen Paketmanager 
verteilt wird (was bei interessanten/wichtigen libs in der regel der 
fall ist), interessiert cargo ueberhaupt nicht. cargo ist zum entwickeln 
und bauen von rust programmen und zum managen der abhaengigkeiten (um 
das programm bauen zu koennen), nicht um die Programme/Libs an den 
Anwender zu verteilen (es sei denn, du baust alles aus den sourcen, aber 
dann hast du mit rust und cargo dieselben probleme wie mit anderen 
Sprachen und Tools auch).

cargo ist nichts anderes als das, was pip für python ist. Installierst 
du über pip irgendwelche Programme die in Python geschrieben sind? Nein? 
Dann gibt es mit cargo genauso wenig probleme.

Du siehst Probleme, wo keine sind.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Den Code von crates.io kannst du forken und wie das mit den Mirrors geht
> steht auch auf der Github Seite von crates.io

Ah, ja. Ein "Mirror" nennen sie das. Laut der verlinkten Seite ist das 
aber so:

> This mirror will function as a read-only duplicate of crates.io's API.
> You will be able to download crates using your index and your mirror,
> but the crate files will still come from crates.io's S3 storage.


Vieleicht war das nicht klar genug:
> keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es
> vollständig zu Mirroren

Ich verstehe unter einem Mirror etwas, dass alle Daten spiegelt. Ein apt 
mirror spiegelt alle debian Packete der angegebenen Repos. Ein Mirror 
der IETF RFCs hat eine Kopie von jedem RFC. Aber von der Beschreibung 
des cargo "Mirrors" tönt es so, als wäre das höchstens ein Cacheing 
Proxy, der die Pakete nur zwischenspeichert, die man abfragt, oder 
eventuell nicht einmal das, und einfach immer nur auf die Daten auf dem 
selben S3 zugreift. Vieleicht kann man die Daten des S3 irgendwie 
kopieren? Aber damit hab ich keine Erfahrung. Was auch immer das jetzt 
tatsächlich ist, ein Mirror ist es nicht. Ohne einen ECHTEN mirror, der 
eine Kopie aller Daten hält und es im Notfall ersetzen könnte, bleibt es 
ein Single Point of failure.

PS: Das ist nicht das erste mal, das ich "Mirrors" sehe, die gerade die 
eigentlichen Daten eben nicht alle spiegeln...

: Bearbeitet durch User
Autor: глупний форентроль (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Entscheidung zu einer Programmiersprache ist eigentlich immer "UND" 
nicht "ODER"

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Rust wird bleiben. Genauso wie Kotlin.

Aber die Vorgabe, wie ein Projekt strukturiert zu sein hat, und dass man 
Internetzugang braucht, um die Dependencies runterzuladen, und dass es 
einen Dienstleister im Internet geben muss, der mir die Daten 
bereitstellt, das ... stinkt.

Rust ist eine Sprache. Wozu muss man eine weltweite Übersicht über jeden 
bekommen, der diese Sprache spricht oder in ihr jemals etwas 
niedergeschrieben hat? Das einzige, was man sich damit reinzieht, sind 
Abhängigkeiten.

Ich kann C-Code aus den 80ern aus einem Usenet-Posting fischen, ihn 
kompilieren und ausführen. Zugegeben: Er stinkt, er ist unsicher, und 
vielleicht fällt er auch schlicht hin und kotzt er mir auf die Platte. 
Aber es ist prinzipiell möglich.

Wenn ich in 30 Jahren irgendwo Rust-Code finde, dann steht da "führe 
bitte dieses magische Script aus, welches sämtliche Abhängigkeiten 
automatisch runterlädt und installiert" (d.h. mir am System pfuscht) an. 
Die Server gibt es nicht mehr, die Abhängigkeiten gibt es nicht mehr, 
die Dateien selbst finde ich vielleicht noch irgendwo, aber ich kriege 
sie ohne weiteres nicht mehr in das Build integriert.

Magie lässt sich schlecht debuggen, vor allem, wenn schon lange kein 
Mana mehr in der Umgebung ist...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.