Mozilla präsentiert Programmiersprache Rust

[rüdiger]

Ich finde Rust schaut sehr interessant aus. Es bietet ja sogar Haskell-ähnliche Typeclasses. Es gibt einen GC aber der ist nur optional. Multithreading wird über Messagepassing und nicht über Sharedstate implementiert. Das FFI scheint sehr gut zu sein. Mozilla will Rust ja wohl in

maximAL schrieb:

Wurde bei mir auf Arbeit schon niedergebuht, weil ein bitterböser Garbage Collector dabei ist

Der ist optional.

[maximAL]

rüdiger schrieb:

maximAL schrieb:

Wurde bei mir auf Arbeit schon niedergebuht, weil ein bitterböser Garbage Collector dabei ist

Der ist optional.

Aber allein die Verfügbarkeit verführt natürlich schon zur dunklen Seite der Macht.

(Nein, das ist nicht meine Meinung )

[Gast]

Ähm, mit OOP ist da nicht viel, oder habe ich was übersehen?

[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.