Mozilla präsentiert Programmiersprache Rust

[314159265358979]

Also ich finde, die Sprache ist ziemlich schön geworden. Vor allem der Sprachsupport für die 3 verschiedenen Zeigertypen ist nett. (Dennoch fehlt mir da der weak_ptr.)

An OOP gibts leider recht wenig und vor allem vermisse ich Operatorüberladungen.

Dass bei Kontrollstrukturen keine runden Klammern nötig sind, empfinde ich persönlich als Segen. Je weniger unnötige Zeichen, desto besser. Die Keywords finde ich zu kurz.

Dass char 32 Bit groß ist, kann doch echt nur ein Witz sein. Totale Verschwendung von Bytes, noch schlimmer als in Java.

Fehlende implizite Umwandlungen zwischen Integern und Floats sind bestimmt ziemlich nervig.

Zusammenfassung: Ein paar sehr nette Ideen, aber nicht überzeugend genug.

[cooky451]

314159265358979 schrieb:

Also ich finde, die Sprache ist ziemlich schön geworden.

Klar, sieht ja auch fast aus wie deine Wunschsprache.

[314159265358979]

Bitte was? Ich habe keine Wunschsprache.

[*rant*]

Gefällt mir nicht. Ich mag es nicht, wenn die Schlüsselwörter zwingend als solche geschrieben werden müssen, dann aber abgekürzt werden. fn , mod ?

Was ich toll finde, ist der Umgang mit Objekten im Speicher. Nicht wie in Java (und Tausend anderen Sprachen), wo intern alles Pointer sind, sondern wie in C und C++, wo die Unterscheidung beim Programmierer liegt.

use std;
import std::io;

fn main() {
    for i in [1, 2, 3] {
        io::println(#fmt("hello %d\n", i));
    }
}

[Siassei]

Hallo,

mir persönlich gefällt der Ansatz sehr gut. Persönlich bin ich ein Fan von Scala (für Java / .NET Platform). Das Verschmelzen von Objekt-Orientierten und Funktional-Orientierten Ansätzen mag ich sehr gerne.
Endlich gibt es auch eine Sprache, die einen native Code Compiler hat

Das Abkürzen von Schlüsselwörter verstehe ich nicht. Aber egal, daran "gewöhnt" man sich.

Aus der offiziellen Seite kann ich einiges nicht erkennen.
http://www.rust-lang.org/

• Es wird von "It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles" gesprochen. Persönlich konnte ich nichts sehen, wass an object-oriented erinnert.
  Wie erzeugt man in rust eine Klasse mit Methoden?
• Wie reserviert man einen Speicherbereich und gibt in wieder frei? Wie arbeitet der GC?

[Ethon_]

Deutliche Ähnlichkeiten mit der Sprache, die ich mir überlegt habe. oO
Von daher gefällt sie mir.

[Bashar]

Wieder eine Sprache mehr auf der TODO-Liste ... Go oder Rust zuerst?

[Ethon_]

// A conditionally-compiled module
#[cfg(target_os="linux")]
mod bar {
  ...
}

Yipeeee ... sowas wollte ich immer schon, da ich versuche alles portabel zu schreiben, builtin- Support dafür ist schon immer mein Traum gewesen. Keine Präprozessor-Schlacht mehr ... Omg, muss es gleich heute ausprobieren.

[Ethon_]

Dass char 32 Bit groß ist, kann doch echt nur ein Witz sein. Totale Verschwendung von Bytes, noch schlimmer als in Java.

In C++ nutzt man auch 32bit ints zur Darstellung von beliebigen Zeichen (siehe char_traits etc). Strings in Rust werden per UTF8 kodiert, also wieder 8bit pro ASCII-Char.

[Artchi]

Siassei schrieb:

Hallo,

mir persönlich gefällt der Ansatz sehr gut. Persönlich bin ich ein Fan von Scala (für Java / .NET Platform). Das Verschmelzen von Objekt-Orientierten und Funktional-Orientierten Ansätzen mag ich sehr gerne.
Endlich gibt es auch eine Sprache, die einen native Code Compiler hat

Na, da gab es aber schon lange OCaml für dich. Oder? Es unterstützt sowohl FP und OOP. Und es kann Bytecode und nativen Code erzeugen.

Bisher hat mich von OCaml lediglich der miese Windows-Support abgeschreckt. Aber ich denke für Linux-Fans ist OCaml eine feine Sache.

[maximAL]

Artchi schrieb:

Na, da gab es aber schon lange OCaml für dich. Oder? Es unterstützt sowohl FP und OOP. Und es kann Bytecode und nativen Code erzeugen.

Wobei den OOP Layer von OCaml wohl kaum einer benutzt. Als ich mir die Sprache vor Jahren mal angesehen hatte, wirkte der OOP-Aufsatz wie ein hässlicher Fremdkörper in der ansonsten ziemlich eleganten Sprache und wirklich funktional konnte man damit afair auch nicht mehr programmieren.

[314159265358979]

Ethon_ schrieb:

Dass char 32 Bit groß ist, kann doch echt nur ein Witz sein. Totale Verschwendung von Bytes, noch schlimmer als in Java.

In C++ nutzt man auch 32bit ints zur Darstellung von beliebigen Zeichen (siehe char_traits etc). Strings in Rust werden per UTF8 kodiert, also wieder 8bit pro ASCII-Char.

In C++ habe ich aber char, char16_t, char32_t und wchar_t, also 4 verschiedene Typen, jeder für den jeweiligen Zeichentyp, den ich gerade haben möchte.

[Zeus]

Bashar schrieb:

Wieder eine Sprache mehr auf der TODO-Liste ... Go oder Rust zuerst?

Persönlich halt ich mehr von Rust als von Go, daher - wem überrascht, ich rate zu - Rust.

[rüdiger]

314159265358979 schrieb:

und vor allem vermisse ich Operatorüberladungen.

oh, das ist blöd.

Bashar schrieb:

Wieder eine Sprache mehr auf der TODO-Liste ... Go oder Rust zuerst?

Ich finde Rust interessanter als Go. Siehe auch in der Rust FAQ den Abschnitt zu Go: https://github.com/mozilla/rust/wiki/Doc-language-FAQ
->

Have you seen this Google language, Go? How does Rust compare?

Yes.

* Rust development was several years underway before Go launched, no direct inspiration.
** Though Pike's previous languages in the Go family (Newsqueak, Alef, Limbo) were influential.
* Go adopted semantics (safety and memory model) that are quite unsatisfactory.
** Shared mutable state.
** Global GC.
** Null pointers.
** No RAII or destructors.
** No type-parametric user code.
* There are a number of other fine coroutine / actor languages in development presently. It's an area of focus across the PL community.

314159265358979 schrieb:

In C++ habe ich aber char, char16_t, char32_t und wchar_t, also 4 verschiedene Typen, jeder für den jeweiligen Zeichentyp, den ich gerade haben möchte.

Der Punkt ist doch, dass du mit den 32Bit chars nicht falsch liegen kannst. Wieviele Programme haben kaputten Unicode-Support, weil sie einfach von 8Bit Zeichen ausgehen? Natürlich gibt es Fälle, wo man mit einem 8Bit char vielleicht ein bisschen Speicher sparen könnte. Aber das ist doch Microoptimierung. Und da Strings, wie Ethon schon gesagt hat, als UTF-8 kodiert werden, hält sich die Speicherverschwendung doch in Grenzen.

[Ethon]

In C++ habe ich aber char, char16_t, char32_t und wchar_t, also 4 verschiedene Typen, jeder für den jeweiligen Zeichentyp, den ich gerade haben möchte.

Deswegen kannst du tolle Dinge machen wie:

char c = 'ä';

Und das Selbe mit UTF32-Codepoints bei char16_t etc. Im Endeffekt hast du eh nur mit char32_t deine Ruhe.
Außerdem ... wie oft arbeitet man mit einzelnen Chars und wo werden sie gespeichert? Bei Stringoperationen sind sie sowieso nur temporär und im String sind es ja nur 8bit Chars.

[Siassei]

[quote="Ethon"]

Deswegen kannst du tolle Dinge machen wie:

char c = 'ä';

Und das Selbe mit UTF32-Codepoints bei char16_t etc. Im Endeffekt hast du eh nur mit char32_t deine Ruhe.
Außerdem ... wie oft arbeitet man mit einzelnen Chars und wo werden sie gespeichert? Bei Stringoperationen sind sie sowieso nur temporär und im String sind es ja nur 8bit Chars.

Persönlich würde es mich freuen, wenn man string auch in UTF-16 oder UTF-32 dargestellt werden könnte. Aber das ist von den Machern nicht berücksichtigt.

Etwa wie folgt

[#encoding="utf-32"]
let s:string

[314159265358979]

rüdiger schrieb:

Der Punkt ist doch, dass du mit den 32Bit chars nicht falsch liegen kannst. Wieviele Programme haben kaputten Unicode-Support, weil sie einfach von 8Bit Zeichen ausgehen? Natürlich gibt es Fälle, wo man mit einem 8Bit char vielleicht ein bisschen Speicher sparen könnte. Aber das ist doch Microoptimierung. Und da Strings, wie Ethon schon gesagt hat, als UTF-8 kodiert werden, hält sich die Speicherverschwendung doch in Grenzen.

Die meisten Sprachen sind mit ASCII komplett abgedeckt. Des Weiteren bezweifle ich mal, dass du jede deiner Anwendungen in eine andere Sprache als Deutsch oder Englisch übersetzt.

[Siassei]

314159265358979 schrieb:

rüdiger schrieb:

Der Punkt ist doch, dass du mit den 32Bit chars nicht falsch liegen kannst. Wieviele Programme haben kaputten Unicode-Support, weil sie einfach von 8Bit Zeichen ausgehen? Natürlich gibt es Fälle, wo man mit einem 8Bit char vielleicht ein bisschen Speicher sparen könnte. Aber das ist doch Microoptimierung. Und da Strings, wie Ethon schon gesagt hat, als UTF-8 kodiert werden, hält sich die Speicherverschwendung doch in Grenzen.

Die meisten Sprachen sind mit ASCII komplett abgedeckt. Des Weiteren bezweifle ich mal, dass du jede deiner Anwendungen in eine andere Sprache als Deutsch oder Englisch übersetzt.

Um das jetzt zu beenden. Es ist wohl eher eine philosophische Frage.
ASCII, UTF-8 oder ...
Einzig allein die kaotische Umsetzung auf den verschiendenen Platformen ist ein wenig ärgerlich.

@314159265358979
Es sollte Grundsätzlich die Möglichkeit bestehen, ein Programm in alle relavanten Sprachen übersetzen zu können.

[314159265358979]

Siassei schrieb:

Es sollte Grundsätzlich die Möglichkeit bestehen, ein Programm in alle relavanten Sprachen übersetzen zu können.

Natürlich, aber das sollte nicht die einzige Möglichkeit sein und schon gar nicht default.

[rüdiger]

314159265358979 schrieb:

rüdiger schrieb:

Der Punkt ist doch, dass du mit den 32Bit chars nicht falsch liegen kannst. Wieviele Programme haben kaputten Unicode-Support, weil sie einfach von 8Bit Zeichen ausgehen? Natürlich gibt es Fälle, wo man mit einem 8Bit char vielleicht ein bisschen Speicher sparen könnte. Aber das ist doch Microoptimierung. Und da Strings, wie Ethon schon gesagt hat, als UTF-8 kodiert werden, hält sich die Speicherverschwendung doch in Grenzen.

Die meisten Sprachen sind mit ASCII komplett abgedeckt. Des Weiteren bezweifle ich mal, dass du jede deiner Anwendungen in eine andere Sprache als Deutsch oder Englisch übersetzt.

ASCII deckt die wenigsten Sprachen ab. Es reicht ja nicht einmal für Deutsch. Die meisten Programmierer haben halt leider keine Ahnung von Unicode und wählen daher zu oft das falsche Default. Mein Name enthält ein nicht-ASCII-Zeichen und es gibt so viele Software die damit nicht klar kommt, weil zu viele Leute glauben, dass 8Bit eben alles sei. Daher finde ich 32Bit chars sinnvoll. Und wie oft schaut man sich ein einzelnes Zeichen an? Der Speicherplatzbedarf dürfte für praktische Anwendungen nur minimal größer sein.

Siassei schrieb:

Es ist wohl eher eine philosophische Frage.
ASCII, UTF-8 oder ...

Nein, es ist keine philosophische Frage. ASCII reicht halt für Englisch und ein paar wenige andere Sprachen. Es reicht nicht für Deutsch, Französisch, Spanisch, Portugiesisch, Chinesisch, Japanisch, Russisch, Arabisch, etc. Es ist heutzutage einfach nicht mehr zeitgemäß nur noch auf ASCII zu setzen.