Leserbriefe Juni 2021

Rust schlecht lesbar

(Programmiersprachen: Was Rust hat, das andere nicht haben; iX 5/2021, S. 42)

Programmiersprachen wurden ja irgendwann einfach lesbarer. Ein erster Ansatz war das schrecklich aufgeblähte COBOL, aber gerade Java und C# waren dann tatsächlich gut lesbar, noch besser sicher Pascal und Oberon.

Irgendwann kamen dann wieder schöne Konstrukte aus C++ ins C#, womit man zwar effizienter programmieren kann, aber die Lesbarkeit abnimmt. Was ich immer wieder feststelle: Je lesbarer Code ist, desto weniger grobe und gefährliche Schnitzer kommen darin vor.

Rust empfinde ich als nicht besonders gut lesbar (wobei es eine Vielzahl an Sprachen gibt, die noch schlimmer sind) und ich frage mich, ob der Compiler nicht einfach die Fehler aufzeigen muss, die man bei einer besser lesbaren Sprache selber bemer­ken würde.

Ingo Höckenschnieder, aus dem iX-Forum

Erfahrung als Java-Entwickler

(Programmierung: Apple M1 als Entwicklungssystem; iX 5/2021, S. 54)

Ich entwickle hauptsächlich in Java und habe zum Vergleich noch einen circa sieben Jahre alten Mac mit i5 und einen mit i7 von 2016. Ich kann nur sagen, mit nativer Software zieht der M1 beiden die Wurst vom Brot – bei meinen realen Use Cases ist er um den Faktor drei bis vier schneller. Es handelt sich hauptsächlich um größere mvn-Builds, und natürlich ist alles lokal gecacht. Über Rosetta 2 ist der M1 dabei immer noch mit den Intels etwa gleichauf.

Als JRE verwende ich die nativen zulu-­Builds, auch die native Eclipse-Preview läuft mittlerweile top – alleine die Start-up-Zeiten waren für mich bisher unvorstellbar. Dabei verwende ich sogar das – eigentlich hoffnungslos veraltete – Andmore für die Android-Entwicklung.

Einzig auf zwei Probleme stieß ich: Virtual­Box et cetera läuft nicht mehr und wird wahrscheinlich auch nie mehr laufen. Ferner habe ich noch ein kleines Nebenprojekt mit Jekyll, und das hat mich – weil Ruby gerne Abhängigkeiten nativ lokal kompiliert – voll in die Dependency Hell geführt. Letztlich hat nur der Umweg über Homebrew funktioniert, das wird aber mit Big Sur mittlerweile sowieso empfohlen.

LostException, aus demiX-Forum

Warnung, kein Fehler

(Softwareentwicklung: Rust-Tutorial, Teil 1: Sprachkon­strukte, Ownership und asynchrone Programmierung; iX 5/2021, S. 46)

Im Tutorial über Rust steht auf Seite 47:

let tup = (500, 6.4, 1);

Die wird jedoch im Playground mit der Fehlermeldung

^^^ help: if this is intentional, prefix it with an underscore: `_tup`

abgebrochen. Wie ist das zu erklären?

Norbert Gerhard Zemke, via E-Mail

Vielen Dank für Ihren Hinweis. Die Zeile erzeugt jedoch keinen Fehler, vielmehr handelt es sich um eine Compilerwarnung. Sie informiert darüber, dass eine Variable angelegt, aber nicht verwendet wurde. Sobald die Variable verwendet wird, verschwindet diese Warnung. Ein _ vor den Variablennamen teilt dem Compiler mit, dass dies bewusst geschieht und er nicht warnen soll. (Dr. Jens Breitbart, Dr. Stefan Lankes)

Zu hohe Anforderungen

(IT-Recht & Datenschutz: Dürfen Datenschutzaufsichtsbehörden vor IT-Produkten warnen? iX 5/2021, S. 31)

Im Artikel über Warnungen von Datenschutzbehörden vor IT-Produkten heißt es: „[...] Unabhängig davon müssen sie allerdings bestimmte inhaltliche Kriterien erfüllen [...].“

Meiner Meinung nach wird die Angemessenheit an dieser Stelle mit zweierlei Maß gemessen. Qualitätskriterien an Gutachten wären damit „unverhältnismäßig“ höher als die an Werbeversprechen zu den Produkten. Ich kann nachvollziehen, dass der (Werte-)Maßstab an eine Kontrollinstanz höher sein sollte, aber die Latte liegt nicht halb so hoch, wie uns die Industrie anzeigen will.

Die Erstellung eines sorgsamen Gutachtens beziehungsweise einer guten Bewertung setzt eine ausreichende und vor allem aufrichtige Messwertaufnahme voraus. Das sollte in den meisten Fällen also zeitaufwendig und kostspielig sein – und daher nicht im (marktwirtschaftlichen) Interesse der Unternehmen liegen. Ich persönlich habe starke Zweifel daran, dass ausgerechnet Kaufleute ihre Werbeprojekte inhaltlich ausreichend sorgsam auf Richtigkeit oder Sachlichkeit prüfen. Warum sollte das also für entsprechende Warnungen gelten müssen?

Als Systemadministrator und Anwendungsentwickler kann ich nur sagen: Nicht eingehaltene Werbeversprechen der Hersteller werden in der Regel nicht in Rechnung gestellt; vielmehr bleiben Kunden oft (stillschweigend) auf einem Schaden sitzen. Wie oft ist das Kind schon in den Brunnen gefallen, ohne dass es Konsequenzen gab – und ohne dass ein Entscheidungsträger tatsächlich Verantwortung für seine getroffene Entscheidung übernimmt. Weder als Anwender noch als Adminis­trator habe ich ausreichend Kraft, geschweige denn Lust, auf die immer wiederkehrenden „Verstrickungen“.

SK, via E-Mail

Ergänzungen und Berichtigungen

Software-defined Storage: Cephs neues Werkzeug cephadm richtig nutzen; iX 4/2021, S. 122

An der Stelle der Abbildung 5 ist auf Seite 125 die Abbildung 3 noch einmal abgedruckt, allerdings mit der Bildunterschrift von Abbildung 5. Zu sehen sein sollte dort aber ein podman-Log-Auszug (siehe Abbildung unten).

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.