Mozilla präsentiert Programmiersprache Rust
-
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.
-
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.
-
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.
-
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.
-
[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
-
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.
-
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.
-
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.
-
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.
-
314159265358979 schrieb:
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.
Default werden doch nur 8bit Chars in Rust verwendet, dh. mit ASCII sind deine Strings kein bischen größer.
Sag mir einen Fall, in dem du größere Mengen Chars speicherst, der nichts mit einem String zu tun hat.Ansonsten sind kleinere Chars einfach nur fehleranfällig, da es nicht intuitiv ist, 2 chars für ein Umlaut zu brauchen. Das sehe ich auch als Problem bei std::string in der C++ Standardbibliothek, im Endeffekt ist es doch nicht mehr als ein std::vector<char> mit mehr Bloat.