Ja, Ada und das Ökosystem finde ich auch sehr gut. Bisher füllt Ada im Wesentlichen nur eine Nische, aber eine die sehr gut zahlt, sodass insgesamt trotzdem ein hohes Ertragsvolumen mittels Ada generiert werden kann.
Hier gibt es eine hilfreiche Übersicht, um sich einen guten ersten Eindruck zu verschaffen. Davon kann/muss man dann ziemlich sicher extrapolieren, denn viele realisierte/zukünftige Projekte stehen auch einfach unter einer Geheimhaltungsstufe, sodass es schwierig ist, alle Einsatzgebiete zu kennen.
Wenn man die Entstehungsgeschichte Adas kennt, weiß man auch, wie es dazu kam.
Man kann sich vorstellen, dass die Sprache heute nicht besonders "hip" ist, obwohl sie so einiges zu bieten hat. Das hängt sicherlich auch damit zusammen, dass man andere Ansprüche an die Programme hat, als an Wald-und-Wiesen-Web/Desktop/Smartphone-Software. Da gibt es einfach ganz andere Kompromisse bei Entwicklungsressourcen (Geld, Zeit bzw. Aufwand, Geschwindigkeit), Verlässlichkeit, Robustheit, Sicherheit, Echtzeitfähigkeit, Performance, Erlernbarkeit & zur Verfügung stehende Arbeitskräfte/Entwickler, usw.
An den geschweiften Klammern an sich nichts, jedoch macht für mich die Art und Weise, wie sie bei C und Syntaxnachahmern in eigenen Zeilen in der Gegend rumfliegen den Quellcode nur unter hohem Konzentrationsaufwand lesbar.
Programmiersprachen, die ohne diese Abscheulichkeit auskommen gibt es ja nicht erst seit Python, das konnten auch schon Fortran und Pascal.
> An den geschweiften Klammern an sich nichts, jedoch macht für mich die Art und Weise, wie sie bei C und Syntaxnachahmern in eigenen Zeilen in der Gegend rumfliegen den Quellcode nur unter hohem Konzentrationsaufwand lesbar.
Blockklammern sollten normalerweise ja auch nicht "in der Gegend rumfliegen", sondern schon dort stehen, wo sie hingehören bzw. zu erwarten sind.
Ein gewisser Konzentrationsaufwand lässt sich beim Lesen von Quellcode nun mal nicht vermeiden. Im Notfall helfen zeitgemäße Editoren. Bei Kate z. B. reicht ein Klick neben eine (x-beliebige) Klammer und man weiß Bescheid.
> Programmiersprachen, die ohne diese Abscheulichkeit auskommen gibt es ja nicht erst seit Python, das konnten auch schon Fortran und Pascal.
Jede Sprache hat halt ihre Besonderheiten. Die lernt man kennen und gewöhnt sich dran. Die "perfekte" Sprache wird ohnehin nie geben.
Aber die gibt es ja, Du hast ja selbst schon welche genannt. Guckst Dir halt eine aus.
Nur - beim *Lesen* von Code mit C-ähnlicher Syntax nutzt Dir das natürlich wenig. Hier hilft dann vielleicht eine Einstellungsänderung im Sinne von "Dr. Strangelove or: How I Learned to Stop Worrying and Love Braces"
Auf den ersten Blick sieht das alles beeindruckend aus, vor allem wenn man bedenkt, dass das aus der Feder einer einzelnen Person kommt. Wenn man sich hingegen die Argumente und Versprechen mal genauer anschaut, scheint nicht viel übrig zu bleiben: https://christine.website/blog/v-vaporware-2019-06-23
Das kann das allseits geschmähte C schon lange. Auf einer Promotiontour macht es sich aber schlecht, darauf hinzuweisen. Auf POSIX-kompatiblen Systemen lauten die Namen der zugehörigen Funktionen: dlopen, dlclose, dlsym, dlerror, ...
C++ natürlich auch, aber es ging mir primär um die Möglichkeit, shared objects zur Laufzeit einzubinden und sie wieder zu entfernen. Ich denke, C und auch C++ werden gerne schlecht geredet, weil der Markt für Programmiersprachen endlich ist und diese beiden "Oldtimer" immer noch einen riesigen Marktanteil haben. Es bleiben also nicht viele Möglichkeiten sich Anteile herbeizureden.
Jetzt bin ich aber ernsthaft neugierig: Wie setzt man mit diesen POSIX-Aufrufen Code Hot swapping praktisch um? Wie tauscht man mit den oben genannten POSIX-Aufrufen beliebigen C-Code eines beliebigen C-Programms zur Laufzeit? Fügen Sie diese Aufrufe zur Laufzeit in das C-Programm ein? Wie? Könnten Sie das bitte anhand eines Minimalbeispiels zeigen? Vielen Dank!
Hast Du außer Schlagworten und Suggestivfragen in Kombination mit einem Link zur Wikipedia zu einem Thema, welches weder im Artikel noch im vorhergehenden Beitrag On Topic ist, irgend etwas sinnvolles zur Diskussion beizutragen? Ich fürchte nicht...
1. Die Schlagworte standen nicht für sich, sondern in Sätzen. Der Zusammenhang ergibt sich aus den vorangehenden Kommentaren, genauer: kamome umidori stimmte hosis Kritik zu und ergänzte sie um den Punkt, der üblicherweise auch "Code Hot swapping" genannt wird (s.o.: "geänderter Code kann zur Laufzeit neu geladen werden" mit Verweis auf ein Beispiel). Darauf entgegneten Sie, dass C diese Funktion "schon lange" mittels gewisser, POSIX-standardisierter Aufrufe ("dlopen, dlclose, dlsym, dlerror, ...") unterstützen würde. Letztere spezifizieren/implementieren, was man gängigerweise "Dynamic Loading" nennt; ein völlig orthogonale Features. So viel zu den "Schlagworten"...
2. Für meine Aussage "Demnach wäre Dynamic loading mindestens so mächtig wie Code Hot swapping." nahm ich an, Ihr vorangehender Kommentar wäre in diesem Kontext inhaltlich korrekt. Damit und den in dieser Aussagen enthaltenen Verweisen wollte ich Ihnen einen Hinweis darauf geben, dass hier etwas nicht stimmen kann. Haben Sie nicht verstanden, um welches Feature es kamome umidori ging? Oder halten Sie diese beiden Features für gleichwertig?
Meine Fragen leiten sich aus diesem Verständnis Ihres möglichen Missverständnisses direkt ab. So gesehen, kann man sie auch als Suggestivfragen werten. Sie sind nicht böse gemeint, sondern stellen lediglich eine weitere Möglichkeit dar, einen Hinweis darauf zu geben, dass hier etwas nicht zusammen passt. Vielleicht wären Sie ja selbst darauf gekommen.
3. In diesem Sinne habe ich bereits etwas sinnvolles zur Diskussion beigetragen, nämlich genau den Hinweis, dass hier etwas nicht ganz koscher ist, d.h. dass es vermutlich ein Missverständnis zwischen kamome umidori und Ihnen, zwischen "Code Hot swapping" und "Dynamic loading" gab.
4. Mit "Ich fürchte nicht..." machen Sie sich übrigens selbst des Gebrauchs der Suggestivfrage schuldig. Ich fürchte, dass Sie mich bewusst falsch verstehen wollen...
dlopen, dlclose und die damit zusammenhängenden C-Funktionen leisten genau das geforderte: geänderter Code kann zur Laufzeit neu geladen werden. Natürlich funktioniert das nur auf Betriebssystemen. Der OS-Verschnitt aus Redmond hätte das bekannte Problem, dass er nicht mit gelöschten Dateien, die in Verwendung sind, umzugehen versteht. Falls Du darauf hinaus wolltest: Es ist dein ureigenstes Problem, wenn Du POSIX-kompatible Eigenschaften auf einem nicht POSIX-kompatiblen System nutzen möchtest. Ein etwas genauerer Blick in die zugehörige man-Page könnte zu deiner Erleuchtung beitragen...
who knows
PS: "kamome umidori" scheint ja im Gegernsatz zu dir verstanden zu haben, wie das Ganze funktioniert. Oder aber er nimmt sich einfach die Zeit sich zu informieren und Antwortet nicht einfach mit einem verklausulierten "Ich kann das nicht, also Geht es nicht". PPS: Es steht dir nicht zu, unaufgefordert im Namen anderer zu schreiben. PPPS: ldd /usr/lib64/firefox/firefox zeigt unter anderem folgende interessante Zeile: libdl.so.2 => /lib64/libdl.so.2 ... und sonst nicht sehr viel. Denk mal darüber nach...
Zunächst: Danke, damit lässt sich wieder sinnvoll diskutieren.
zu "PPS": Ich wollte mit meinem letzten Kommentar meine Reaktion, die Sie kritisierten, rechtfertigen. Dazu musste ich die bisherige Diskussion in Kürze zusammenfassen und Ihnen meine Auffassung jener darlegen. Dabei habe ich das von kamome umidori erwähnte Feature als "code hot swapping" identifiziert, und das Ihres Einwands als "dynamic loading" ("dlopen", "dlclose"). Falls ich Beiträge von Dritten irrtümlicherweise fehlinterpretiert haben sollte, bitte ich Sie darum, mich darauf aufmerksam zu machen. Danke!
dlopen, dlclose und die damit zusammenhängenden C-Funktionen leisten genau das geforderte: geänderter Code kann zur Laufzeit neu geladen werden.
Und ich bezweifle, dass dieses "dynamic loading" tatsächlich das selbe leistet wie "code hot swapping".
Wie kann man bspw. mit den erwähnten POSIX-Aufrufen für "dynamic loading" den Ablauf eines beliebigen Programms, z.B. das von Ihnen erwähnte Firefox, nachträglich zur Laufzeit beliebig manipulieren, also bspw. aktualisieren ohne es neustarten zu müssen? Wenn ich es richtig verstehe, müsste ein Programm doch schon vor dessen Übersetzung, d.h. in der Entwicklung, darauf vorbereitet worden sein, dieses Problem mittels dieser POSIX-Aufrufen lösen zu können. Das bedeutet, es müsste die Aktualisierung seiner Bestandteile (z.B. Bibliotheken und sonstigen object code) erkennen, den betreffenden Ablaufszweig pausieren oder abbrechen, den betreffenden Teil des Zustands sichern, den betreffenden Bestandteil entladen und in aktualisierter Version laden, den zwischengesicherten Zustand widerherstellen (die Zustandsintegration benötigt auch die Unterstützung jenes Bestandteils) und den Ablaufszweig resümieren oder neustarten, oder nicht?
"code hot swapping" könnte das ohne größere Vorbereitungen oder vorbeugende Entwicklungen am Programm.
Natürlich funktioniert das nur auf Betriebssystemen. Der OS-Verschnitt aus Redmond hätte das bekannte Problem, dass er nicht mit gelöschten Dateien, die in Verwendung sind, umzugehen versteht. Falls Du darauf hinaus wolltest: [...]
Nein, das wollte ich nicht. Diese Details interessieren mich weniger, aber dafür andere umso mehr.
Ein etwas genauerer Blick in die zugehörige man-Page könnte zu deiner Erleuchtung beitragen...
Danke. Meinen Sie dlopen(3)? Die und weitere habe ich bereits gelesen. Von welcher Erleuchtung sprechen Sie?
zu "PS": Wollen Sie mir unterstellen, ich würde mich nicht informieren? Woran erkennen Sie das? Außerdem handelt es sich eher um ein verklausuliertes "Ich könnte das (von Ihnen Behauptete) nicht umsetzen, denn ich habe begründete Zweifel daran, dass es geht. Also zeigen Sie mir in meiner Neugierigkeit bitte, wie es geht, um Ihren Standpunkt zu begründen!". Über einschlägige, hilfreiche Referenzen wäre ich ebenfalls hocherfreut. So kann man sich nunmal missverstehen...
zu "PPPS": Es beweist nicht, dass "dynamic loading" das selbe leistet wie "code hot swapping". Was gibt pldd(1) aus?
Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden. Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden. Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird. Unter *DOS war dies durchaus üblich. Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden. Man könnte auf diese Weise dann auch beliebigen Code einfügen, aber das liefe dann wohl eher unter der Rubrik „Schadsoftware“. Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen. Ich wiederhole aber dennoch: Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden.
Dann habe ich Sie und kamome umidori missverstanden. Um das aufzuklären: der Link oben enthält Folgendes:
Hot-reloading is a technique that allows for rapid iteration during the development of an application.
The core idea is that by encapsulating core logic in dynamic libraries, and then carefully managing application state, we can reload a newly compiled library while the application continues to run and have changes take immediate effect. [...] In this approach to hot-reloading, libaries must contain no internal state. All state needed by the hot-reloaded libraries is declared outside of the libraries, owned by the application and then passed into each library function call.
This means that you can simply reload the library while the game is still running, and have your game update live. As a consequence however, you can't have any global state in your library, everything must be owned by the host in order to avoid getting unloaded with the library.
Diese Form des "hot/live reloading" wäre natürlich mit den POSIX-Aufrufen für "dynamic loading" abgedeckt. Da haben Sie Recht.
Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden.
Ja, das ist natürlich eine wichtige Einschränkung, die wir lang und breit diskutierten.
Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird.
Einige JIT-Compiler tun dies bspw., aber es müsste nicht unbedingt selbstmodizierender Code sein, das wäre lediglich ein Spezialfall. Bei "code hot swapping" z.B. modifiziert sich der Code nicht zwingend selbst.
Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden.
Ja, richtig: unter geeigneten Randbedingungen, z.B. an den Programmzustand und dessen Verwaltung, wie ich oben bereits andeutete.
Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen.
Genau, aber eben nur, wenn man entsprechende Vorkehrungen trifft, bevor das Programm läuft.
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben.
So hatte ich Ihre Aussagen aber nun einmal verstanden gehabt. Tut mir Leid, aber Missverständnisse geschehen mitunter, auch ganz ohne verwerflich Absichten. Schön, dass wir das nun wissen.
> Ich wiederhole aber dennoch: Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Der Verdacht drängt sich allerdings auf. Ich kann die Absichten zwar noch nicht sicher verorten, tippe aber auf eine politische Motivation. Mit der Zeit wird das sicher deutlicher.
Da es sich um eine Fähigkeit der daraunterliegenden VM handelt, unterstützen andere darauf aufbauende Sprachen dies häufig auch, so z.B. Elixir (BEAM) oder diverse JVM-Sprachen.
Die Zukunft gehört Rust. Außerdem steht mit der Mozilla Foundation eine große Organisation dahinter die das entsprechend mit Projekten aus der Praxis, wie eben Firefox, pushen wird.
Rust allein? Existiert in Ihrer Zukunft nur noch Rust? Gibt es in Ihrer Zukunft auch noch andere Dinge, für die schon heute eine Bezeichnung existiert? Falls ja, welche?
Spaß beiseite: Was soll diese Aussage eigentlich genau bedeuten? "Die Zukunft gehört Rust." eröffnet viele Fragen, z.B.: Was verstehen Sie unter Zukunft? 10s, 4h, 2d, 5 Monate, 8 Jahre, ein Menschenleben, zwei Generationen, ein Jahrtausend, ... ? Rust als Alternative wozu? An wessen/welche Stelle tritt Rust, die es vorher nicht inne hatte? Was wird durch Rust obsolet und ersetzt? Was kann es ersetzen? Wieso kann es das? Was wird es ersetzen können? Wieso wird es das können? Warum werden alle Alternativen von Rust verdrängt werden? Und was passiert, wenn der freie Wille einer Person nicht mit Ihren Zukunftsklängen übereinstimmt (z.B. aus Protest), diese zu Fall bringt und in die Traumlande transferiert? Haben wir dann nur unterschiedliche Realitäten oder verschiedene Zeitstränge oder gar die Entstehung eines Paralleluniversums?
Wer zu so einer Behauptung kommt, müsste eigentlich auch ganz klare Antworten auf die obigen Fragen kennen. Wer überdies jene Behauptung äußert, müsste auch sein Wissen teilen und ganz klare Antworten auf die obigen Fragen liefern. Falls nicht, so kann der gesunde Verstand eine solche Aussage nicht ernst nehmen. Mit anderen Worten wären Sie uns ein paar Antworten schuldig, wenn Sie nicht unglaubwürdig wirken wollen.
Und was passiert, wenn der freie Wille einer Person nicht mit Ihren Zukunftsklängen übereinstimmt (z.B. aus Protest), diese zu Fall bringt und in die Traumlande transferiert? Haben wir dann nur unterschiedliche Realitäten ...
Ungläubige Heiden die sich nicht zu Rust bekehren lassen werden dann durch Steinigung umgebracht.
Mal ernsthaft, du willst auf deine Fragen gar keine Antworten, sondern lediglich stänkern. Das kannst du dir sparen. Wer im Business ist, der weiß, wo der Hase hinläuft. Das reicht als Antwort.
Mal ernsthaft, du willst auf deine Fragen gar keine Antworten, sondern lediglich stänkern. Das kannst du dir sparen.
Sie machen hier von einem hypothetischen Argument Gebrauch. Können Sie das auch glaubhaft untermauern?
Wie sagt man doch so schön: Getroffene Hunde bellen.
Wer im Business ist, der weiß, wo der Hase hinläuft.
Als Kombination eines argumentum ad verecundiam und eines argumentum ad populum haben Sie hier ein wirklich überzeugeugendes Totschlagargument komponiert. Bravo!
Das reicht als Antwort.
Ihnen vielleicht... Mir reicht das jedenfalls nicht; höchstens dazu, Ihnen keine weitere Aufmerksamkeit zu schenken.
Schade, sachlicher ging es wohl nicht. Ich muss wohl einen wunden Punkt Ihres Kommentars getroffen haben.
Ich muss wohl einen wunden Punkt Ihres Kommentars getroffen haben.
Es ist so wie Pointer sagte. Der gesunde Verstand kann einen solchen BS nicht ernst nehmen.
Insofern nein, sie haben bei mir keinen Wunden Punkt getroffen, sondern mir ist es schlichtweg zu blöd darauf einzugehen. Ihr Problem ist eher, dass Sie sich daran stören und ich weiß das.
Dass Sie keine stichhaltigen Argumente liefern, wenn die Luft dünne wird, und stattdessen lieber dazu übergehen, Phrasen zu dreschen, ist ja nun schon lange kein Gerücht mehr.
Ihr Problem ist eher, dass Sie sich daran stören und ich weiß das.
Was Sie nicht alles wissen, ist ja allerhand. Mit Ihren Fähigkeiten der telepathischen Psychoanalyse ließe sich sicherlich eine Menge Schotter scheffeln.
Ihr Problem ist, dass Sie keine gescheiten Gegenargumente liefern können, wenn Sie beim Dummschwätzen ertappt wurden.
> Spaß beiseite: Was soll diese Aussage eigentlich genau bedeuten? "Die Zukunft gehört Rust." eröffnet viele Fragen, z.B.: Was verstehen Sie unter Zukunft? 10s, 4h, 2d, 5 Monate, 8 Jahre, ein Menschenleben, zwei Generationen, ein Jahrtausend, ... ? Rust als Alternative wozu? An wessen/welche Stelle tritt Rust, die es vorher nicht inne hatte? Was wird durch Rust obsolet und ersetzt? Was kann es ersetzen? Wieso kann es das? Was wird es ersetzen können? Wieso wird es das können? Warum werden alle Alternativen von Rust verdrängt werden? Und was passiert, wenn der freie Wille einer Person nicht mit Ihren Zukunftsklängen übereinstimmt (z.B. aus Protest), diese zu Fall bringt und in die Traumlande transferiert? Haben wir dann nur unterschiedliche Realitäten oder verschiedene Zeitstränge oder gar die Entstehung eines Paralleluniversums?
> Wer zu so einer Behauptung kommt, müsste eigentlich auch ganz klare Antworten auf die obigen Fragen kennen. Wer überdies jene Behauptung äußert, müsste auch sein Wissen teilen und ganz klare Antworten auf die obigen Fragen liefern. Falls nicht, so kann der gesunde Verstand eine solche Aussage nicht ernst nehmen.
Sicher ist: "der gesunde Verstand" kann einen solchen BS nicht ernst nehmen. Realsatire at its best! Unbezahlbar!
Hast du dir den verlinkten Blogpost mal durchgelesen?
Der verlässt das Projekt, weil er was neues sucht und nicht, weil ihn irgendwas an Mozilla oder Rust stört. Er ist von Rust und seiner Community beeindruckt und weiß das Projekt in sicheren Händen.
BUT, it is time for me to learn some new things, and work on some new things with some new people. ... The Rust team at Mozilla and the Rust community in general are good people, and I'll miss working with you all terribly. ... None of the projects I've worked on are going to be left unmaintained, I'm very confident in the people working on them, on the teams I'm leaving behind, and in the Rust community in general (did I say you were awesome already?).
Eine Stimme, die sich beruflich nur umorientieren möchte. Ich sehe da kein Problem für Rust.
> Hast du dir den verlinkten Blogpost mal durchgelesen?
Siehe da. Ein Horst ergreift das Wort und stellt die Frage in den Raum ob die Quelle auch gelesen wurde ohne sie selbst gelesen zu haben.
Hier, nur für dich mein lieber Horst, direkt aus den Kommentaren rauskopiert:
> What’s really important is this: I’m not proud to be a Mozillian anymore. A variety of incidents contributed to this, but at the end of the day, it’s what’s true. Furthermore, I don’t have any personal opportunity at Mozilla; I recently discovered I’m the lowest-paid person on my team, and Mozilla doesn’t pay particularly well in the first place. In order to have any kind of career growth, I would have to not do the work that aligns with my skills, and what I’m doing now is really how I can have the most impact on Rust moving forward. I don’t believe that has any chance of changing; when I’ve tried to express my frustrations, I’ve only gotten disciplined. Mozilla is not interested in hearing what I have to say.
Das, mein lieber Horst, ist der dritte Rust-Coreentwickler der in kurzer Zeit das Handtuch schmeisst. Guck dir doch mal an was noch bleiben würde wenn sie alle weg gehen. Ob nun, wie in diesem Fall, weil es ein Nebenlaufprojekt ist oder weil Mozilla das nach 7 Jahren einstellt. Was würde übr8g bleiben jenseits von einem Servo-Prototypen?
Das Problem liegt hier aber nicht an Rust, sondern an der Bezahlung seitens Mozilla. Wenn man halt 160000 Dollar pro Jahr verdienen will, aber Mozilla nur 110000 Dollar bezahlt, dann ist doch klar, dass die Entwickler zu Microsoft und Co abwandern, die besser bezahlen. Mit der Sprache hat das aber nichts zu tun. Die hat schon alle für eine Sprache notwendige Sprachelemente und LLVM Compiler wird von vielen Firmen, Organisationen und Entwicklern weiterentwickelt.
Und wo steht, dass das ein Rust-Coreentwickler ist?
Das Problem liegt hier aber nicht an Rust, sondern an der Bezahlung seitens Mozilla.
Wenn Mozilla zu geringe Löhne auszahlt, liegt ihnen nicht genug am Fortschritt von Rust, jedenfalls nicht hinreichend genug, um damit "Die Zukunft gehört Rust." unwiderlegbar behaupten zu können.
Worin liegt also der Unterschied zu den Worten von xyz oben "[...] wenn Mozilla sein Sponsoring einstellt und seine Entwickler abzieht."?
Mit der Sprache hat das aber nichts zu tun. Die hat schon alle für eine Sprache notwendige Sprachelemente und LLVM Compiler wird von vielen Firmen, Organisationen und Entwicklern weiterentwickelt.
Ihr Argument zieht nicht, denn eine Sprache muss gepflegt und weiterentwickelt werden, um erfolgreich zu sein. Also hat es sehr wohl etwas mit Rust als Sprache zu tun. Wie kommen Sie darauf, dass es das nicht täte?
Und wo steht, dass das ein Rust-Coreentwickler ist?
P.S.: Waren Sie sich wiedereinmal zu bequem, durch Eigeninitiative selbst Antworten auf Ihre Fragen zu recherchieren? Und wieso nehmen Sie das als Anlass, die Fakten mithilfe mangelhafter Argumente oder Suggestivfragen verdrehen zu versuchen?
Aber "V" ist offensichtlich wichtig genug, sodass Sie sich gezwungen fühlen, unsachliche Beiträge samt ad hominem zur Diskussion abliefern zu müssen, siehe oben.
Was ist daran so bahnbrechend neu, wenn noch nichtmal die fürchterlichen C-style geschweiften Klammern aufgegeben wurden?
Nichts.
Nur ein großes Ego und warscheinlich zuviel Langweile.
Es haben sich in der Vergangenheit zur wenige Sprachen auf Dauer durchgesetzt...
Ich persönliche finde ADA sehr gelungen, aber leider wenig verbreitet...
Ja, Ada und das Ökosystem finde ich auch sehr gut. Bisher füllt Ada im Wesentlichen nur eine Nische, aber eine die sehr gut zahlt, sodass insgesamt trotzdem ein hohes Ertragsvolumen mittels Ada generiert werden kann.
Hier gibt es eine hilfreiche Übersicht, um sich einen guten ersten Eindruck zu verschaffen. Davon kann/muss man dann ziemlich sicher extrapolieren, denn viele realisierte/zukünftige Projekte stehen auch einfach unter einer Geheimhaltungsstufe, sodass es schwierig ist, alle Einsatzgebiete zu kennen.
Wenn man die Entstehungsgeschichte Adas kennt, weiß man auch, wie es dazu kam.
Man kann sich vorstellen, dass die Sprache heute nicht besonders "hip" ist, obwohl sie so einiges zu bieten hat. Das hängt sicherlich auch damit zusammen, dass man andere Ansprüche an die Programme hat, als an Wald-und-Wiesen-Web/Desktop/Smartphone-Software. Da gibt es einfach ganz andere Kompromisse bei Entwicklungsressourcen (Geld, Zeit bzw. Aufwand, Geschwindigkeit), Verlässlichkeit, Robustheit, Sicherheit, Echtzeitfähigkeit, Performance, Erlernbarkeit & zur Verfügung stehende Arbeitskräfte/Entwickler, usw.
Ja es ist sehr schade dass Ada nicht den Zuspruch bekommt den es verdient hat. Mit Python, C, Haskell und Ada kann man locker ein Google 2.0 bauen.
Es kommt auf den Bereich an. Es gibt eine Vorgabe bei Militär (US) und in kritischer medizinischer Umgebung für den Einsatz von Ada.
Was ist denn an geschweiften Klammern "fürchterlich"?
An den geschweiften Klammern an sich nichts, jedoch macht für mich die Art und Weise, wie sie bei C und Syntaxnachahmern in eigenen Zeilen in der Gegend rumfliegen den Quellcode nur unter hohem Konzentrationsaufwand lesbar.
Programmiersprachen, die ohne diese Abscheulichkeit auskommen gibt es ja nicht erst seit Python, das konnten auch schon Fortran und Pascal.
> An den geschweiften Klammern an sich nichts, jedoch macht für mich die Art und Weise, wie sie bei C und Syntaxnachahmern in eigenen Zeilen in der Gegend rumfliegen den Quellcode nur unter hohem Konzentrationsaufwand lesbar.
Blockklammern sollten normalerweise ja auch nicht "in der Gegend rumfliegen", sondern schon dort stehen, wo sie hingehören bzw. zu erwarten sind.
Ein gewisser Konzentrationsaufwand lässt sich beim Lesen von Quellcode nun mal nicht vermeiden. Im Notfall helfen zeitgemäße Editoren. Bei Kate z. B. reicht ein Klick neben eine (x-beliebige) Klammer und man weiß Bescheid.
> Programmiersprachen, die ohne diese Abscheulichkeit auskommen gibt es ja nicht erst seit Python, das konnten auch schon Fortran und Pascal.
Jede Sprache hat halt ihre Besonderheiten. Die lernt man kennen und gewöhnt sich dran. Die "perfekte" Sprache wird ohnehin nie geben.
Eine "perfekte Sprache" suche ich gar nicht. Nur sollte sie keine an C angelehnte Syntax haben.
Aber die gibt es ja, Du hast ja selbst schon welche genannt. Guckst Dir halt eine aus.
Nur - beim *Lesen* von Code mit C-ähnlicher Syntax nutzt Dir das natürlich wenig. Hier hilft dann vielleicht eine Einstellungsänderung im Sinne von "Dr. Strangelove or: How I Learned to Stop Worrying and Love Braces"
Auf den ersten Blick sieht das alles beeindruckend aus, vor allem wenn man bedenkt, dass das aus der Feder einer einzelnen Person kommt. Wenn man sich hingegen die Argumente und Versprechen mal genauer anschaut, scheint nicht viel übrig zu bleiben:
https://christine.website/blog/v-vaporware-2019-06-23
Das klingt in der Tat weniger toll – leider wurde dort ein für mich sehr interessant klingender Aspekt nicht beleuchtet:
> geänderter Code kann zur Laufzeit neu geladen werden
Ob das wohl funktioniert?
Das scheint auch in anderen Sprachen möglich zu sein:
https://github.com/irh/rust-hot-reloading
Das kann das allseits geschmähte C schon lange. Auf einer Promotiontour macht es sich aber schlecht, darauf hinzuweisen. Auf POSIX-kompatiblen Systemen lauten die Namen der zugehörigen Funktionen: dlopen, dlclose, dlsym, dlerror, ...
who knows
C wird geschmäht?? Meinst Du nicht C++?
C++ natürlich auch, aber es ging mir primär um die Möglichkeit, shared objects zur Laufzeit einzubinden und sie wieder zu entfernen. Ich denke, C und auch C++ werden gerne schlecht geredet, weil der Markt für Programmiersprachen endlich ist und diese beiden "Oldtimer" immer noch einen riesigen Marktanteil haben. Es bleiben also nicht viele Möglichkeiten sich Anteile herbeizureden.
who knows
Demnach wäre Dynamic loading mindestens so mächtig wie Code Hot swapping.
Jetzt bin ich aber ernsthaft neugierig:
Wie setzt man mit diesen POSIX-Aufrufen Code Hot swapping praktisch um? Wie tauscht man mit den oben genannten POSIX-Aufrufen beliebigen C-Code eines beliebigen C-Programms zur Laufzeit? Fügen Sie diese Aufrufe zur Laufzeit in das C-Programm ein? Wie? Könnten Sie das bitte anhand eines Minimalbeispiels zeigen? Vielen Dank!
Hast Du außer Schlagworten und Suggestivfragen in Kombination mit einem Link zur Wikipedia zu einem Thema, welches weder im Artikel noch im vorhergehenden Beitrag On Topic ist, irgend etwas sinnvolles zur Diskussion beizutragen? Ich fürchte nicht...
who knows
Ruhig Brauner, immer der Reihe nach...
1. Die Schlagworte standen nicht für sich, sondern in Sätzen. Der Zusammenhang ergibt sich aus den vorangehenden Kommentaren, genauer: kamome umidori stimmte hosis Kritik zu und ergänzte sie um den Punkt, der üblicherweise auch "Code Hot swapping" genannt wird (s.o.: "geänderter Code kann zur Laufzeit neu geladen werden" mit Verweis auf ein Beispiel). Darauf entgegneten Sie, dass C diese Funktion "schon lange" mittels gewisser, POSIX-standardisierter Aufrufe ("dlopen, dlclose, dlsym, dlerror, ...") unterstützen würde. Letztere spezifizieren/implementieren, was man gängigerweise "Dynamic Loading" nennt; ein völlig orthogonale Features.
So viel zu den "Schlagworten"...
2. Für meine Aussage "Demnach wäre Dynamic loading mindestens so mächtig wie Code Hot swapping." nahm ich an, Ihr vorangehender Kommentar wäre in diesem Kontext inhaltlich korrekt. Damit und den in dieser Aussagen enthaltenen Verweisen wollte ich Ihnen einen Hinweis darauf geben, dass hier etwas nicht stimmen kann. Haben Sie nicht verstanden, um welches Feature es kamome umidori ging? Oder halten Sie diese beiden Features für gleichwertig?
Meine Fragen leiten sich aus diesem Verständnis Ihres möglichen Missverständnisses direkt ab. So gesehen, kann man sie auch als Suggestivfragen werten. Sie sind nicht böse gemeint, sondern stellen lediglich eine weitere Möglichkeit dar, einen Hinweis darauf zu geben, dass hier etwas nicht zusammen passt. Vielleicht wären Sie ja selbst darauf gekommen.
3. In diesem Sinne habe ich bereits etwas sinnvolles zur Diskussion beigetragen, nämlich genau den Hinweis, dass hier etwas nicht ganz koscher ist, d.h. dass es vermutlich ein Missverständnis zwischen kamome umidori und Ihnen, zwischen "Code Hot swapping" und "Dynamic loading" gab.
4. Mit "Ich fürchte nicht..." machen Sie sich übrigens selbst des Gebrauchs der Suggestivfrage schuldig. Ich fürchte, dass Sie mich bewusst falsch verstehen wollen...
dlopen, dlclose und die damit zusammenhängenden C-Funktionen leisten genau das geforderte: geänderter Code kann zur Laufzeit neu geladen werden.
Natürlich funktioniert das nur auf Betriebssystemen. Der OS-Verschnitt aus Redmond hätte das bekannte Problem, dass er nicht mit gelöschten Dateien, die in Verwendung sind, umzugehen versteht. Falls Du darauf hinaus wolltest: Es ist dein ureigenstes Problem, wenn Du POSIX-kompatible Eigenschaften auf einem nicht POSIX-kompatiblen System nutzen möchtest. Ein etwas genauerer Blick in die zugehörige man-Page könnte zu deiner Erleuchtung beitragen...
who knows
PS:
"kamome umidori" scheint ja im Gegernsatz zu dir verstanden zu haben, wie das Ganze funktioniert. Oder aber er nimmt sich einfach die Zeit sich zu informieren und Antwortet nicht einfach mit einem verklausulierten "Ich kann das nicht, also Geht es nicht".
PPS:
Es steht dir nicht zu, unaufgefordert im Namen anderer zu schreiben.
PPPS:
ldd /usr/lib64/firefox/firefox
zeigt unter anderem folgende interessante Zeile:
libdl.so.2 => /lib64/libdl.so.2 ...
und sonst nicht sehr viel. Denk mal darüber nach...
Zunächst: Danke, damit lässt sich wieder sinnvoll diskutieren.
zu "PPS": Ich wollte mit meinem letzten Kommentar meine Reaktion, die Sie kritisierten, rechtfertigen. Dazu musste ich die bisherige Diskussion in Kürze zusammenfassen und Ihnen meine Auffassung jener darlegen. Dabei habe ich das von kamome umidori erwähnte Feature als "code hot swapping" identifiziert, und das Ihres Einwands als "dynamic loading" ("dlopen", "dlclose").
Und ich bezweifle, dass dieses "dynamic loading" tatsächlich das selbe leistet wie "code hot swapping".Falls ich Beiträge von Dritten irrtümlicherweise fehlinterpretiert haben sollte, bitte ich Sie darum, mich darauf aufmerksam zu machen. Danke!
Wie kann man bspw. mit den erwähnten POSIX-Aufrufen für "dynamic loading" den Ablauf eines beliebigen Programms, z.B. das von Ihnen erwähnte Firefox, nachträglich zur Laufzeit beliebig manipulieren, also bspw. aktualisieren ohne es neustarten zu müssen? Wenn ich es richtig verstehe, müsste ein Programm doch schon vor dessen Übersetzung, d.h. in der Entwicklung, darauf vorbereitet worden sein, dieses Problem mittels dieser POSIX-Aufrufen lösen zu können. Das bedeutet, es müsste die Aktualisierung seiner Bestandteile (z.B. Bibliotheken und sonstigen object code) erkennen, den betreffenden Ablaufszweig pausieren oder abbrechen, den betreffenden Teil des Zustands sichern, den betreffenden Bestandteil entladen und in aktualisierter Version laden, den zwischengesicherten Zustand widerherstellen (die Zustandsintegration benötigt auch die Unterstützung jenes Bestandteils) und den Ablaufszweig resümieren oder neustarten, oder nicht?
"code hot swapping" könnte das ohne größere Vorbereitungen oder vorbeugende Entwicklungen am Programm.
Nein, das wollte ich nicht. Diese Details interessieren mich weniger, aber dafür andere umso mehr.Danke. Meinen Siedlopen(3)? Die und weitere habe ich bereits gelesen. Von welcher Erleuchtung sprechen Sie?zu "PS": Wollen Sie mir unterstellen, ich würde mich nicht informieren? Woran erkennen Sie das?
Außerdem handelt es sich eher um ein verklausuliertes "Ich könnte das (von Ihnen Behauptete) nicht umsetzen, denn ich habe begründete Zweifel daran, dass es geht. Also zeigen Sie mir in meiner Neugierigkeit bitte, wie es geht, um Ihren Standpunkt zu begründen!". Über einschlägige, hilfreiche Referenzen wäre ich ebenfalls hocherfreut.
So kann man sich nunmal missverstehen...
zu "PPPS": Es beweist nicht, dass "dynamic loading" das selbe leistet wie "code hot swapping". Was gibt
pldd(1)aus?Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden. Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden. Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird. Unter *DOS war dies durchaus üblich. Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden. Man könnte auf diese Weise dann auch beliebigen Code einfügen, aber das liefe dann wohl eher unter der Rubrik „Schadsoftware“. Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen.
Ich wiederhole aber dennoch:
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
who knows
Schön, dass wir das nun wissen.Naja, ich weiß nicht...
Machen Sie's gut!
> Ich wiederhole aber dennoch:
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Der Verdacht drängt sich allerdings auf. Ich kann die Absichten zwar noch nicht sicher verorten, tippe aber auf eine politische Motivation. Mit der Zeit wird das sicher deutlicher.
> geänderter Code kann zur Laufzeit neu geladen werden
Fuer Erlang und Elixir ein alter hut
Code Hot swapping (während der Laufzeit) ist in der Tat ein wirklich praktisches Feature, z.B. für Anwendungen mit hoher Verfügbarkeit.
Es ist in mehreren Sprachen verfügbar. Klassiker sind Lisp, Smalltalk, Erlang (BEAM) und Java (HotSpot JVM) z.B. per OSGi.
Da es sich um eine Fähigkeit der daraunterliegenden VM handelt, unterstützen andere darauf aufbauende Sprachen dies häufig auch, so z.B. Elixir (BEAM) oder diverse JVM-Sprachen.
Die Zukunft gehört Rust.
Außerdem steht mit der Mozilla Foundation eine große Organisation dahinter die das entsprechend mit Projekten aus der Praxis, wie eben Firefox, pushen wird.
was kriegst du für solche Einsätze wie " die Zukunft gehört Rust" hast du nee Glaskugel?
Ich kenne mich aus und kann das abschätzen.
Jo im Marketing
Und das soll ich Ihnen abkaufen?
Spaß beiseite: Was soll diese Aussage eigentlich genau bedeuten? "Die Zukunft gehört Rust." eröffnet viele Fragen, z.B.: Was verstehen Sie unter Zukunft? 10s, 4h, 2d, 5 Monate, 8 Jahre, ein Menschenleben, zwei Generationen, ein Jahrtausend, ... ? Rust als Alternative wozu? An wessen/welche Stelle tritt Rust, die es vorher nicht inne hatte? Was wird durch Rust obsolet und ersetzt? Was kann es ersetzen? Wieso kann es das? Was wird es ersetzen können? Wieso wird es das können? Warum werden alle Alternativen von Rust verdrängt werden?
Und was passiert, wenn der freie Wille einer Person nicht mit Ihren Zukunftsklängen übereinstimmt (z.B. aus Protest), diese zu Fall bringt und in die Traumlande transferiert? Haben wir dann nur unterschiedliche Realitäten oder verschiedene Zeitstränge oder gar die Entstehung eines Paralleluniversums?
Wer zu so einer Behauptung kommt, müsste eigentlich auch ganz klare Antworten auf die obigen Fragen kennen. Wer überdies jene Behauptung äußert, müsste auch sein Wissen teilen und ganz klare Antworten auf die obigen Fragen liefern. Falls nicht, so kann der gesunde Verstand eine solche Aussage nicht ernst nehmen.
Mit anderen Worten wären Sie uns ein paar Antworten schuldig, wenn Sie nicht unglaubwürdig wirken wollen.
Ungläubige Heiden die sich nicht zu Rust bekehren lassen werden dann durch Steinigung umgebracht.
Mal ernsthaft, du willst auf deine Fragen gar keine Antworten, sondern lediglich stänkern. Das kannst du dir sparen.
Wer im Business ist, der weiß, wo der Hase hinläuft. Das reicht als Antwort.
"Wer im Business ist"
Was denn für ein Business? Finanzen? Versicherungen? Automation? Wo liegt denn z.Z. der hauptsächliche Einsatzbereich von Rust?
Wie sagt man doch so schön: Getroffene Hunde bellen.
Als Kombination eines argumentum ad verecundiam und eines argumentum ad populum haben Sie hier ein wirklich überzeugeugendes Totschlagargument komponiert. Bravo!Ihnen vielleicht... Mir reicht das jedenfalls nicht; höchstens dazu, Ihnen keine weitere Aufmerksamkeit zu schenken.Schade, sachlicher ging es wohl nicht. Ich muss wohl einen wunden Punkt Ihres Kommentars getroffen haben.
Es ist so wie Pointer sagte.
Der gesunde Verstand kann einen solchen BS nicht ernst nehmen.
Insofern nein, sie haben bei mir keinen Wunden Punkt getroffen, sondern mir ist es schlichtweg zu blöd darauf einzugehen.
Ihr Problem ist eher, dass Sie sich daran stören und ich weiß das.
Dass Sie keine stichhaltigen Argumente liefern, wenn die Luft dünne wird, und stattdessen lieber dazu übergehen, Phrasen zu dreschen, ist ja nun schon lange kein Gerücht mehr.
Was Sie nicht alles wissen, ist ja allerhand. Mit Ihren Fähigkeiten der telepathischen Psychoanalyse ließe sich sicherlich eine Menge Schotter scheffeln.Ihr Problem ist, dass Sie keine gescheiten Gegenargumente liefern können, wenn Sie beim Dummschwätzen ertappt wurden.
> Spaß beiseite: Was soll diese Aussage eigentlich genau bedeuten? "Die Zukunft gehört Rust." eröffnet viele Fragen, z.B.: Was verstehen Sie unter Zukunft? 10s, 4h, 2d, 5 Monate, 8 Jahre, ein Menschenleben, zwei Generationen, ein Jahrtausend, ... ? Rust als Alternative wozu? An wessen/welche Stelle tritt Rust, die es vorher nicht inne hatte? Was wird durch Rust obsolet und ersetzt? Was kann es ersetzen? Wieso kann es das? Was wird es ersetzen können? Wieso wird es das können? Warum werden alle Alternativen von Rust verdrängt werden?
Und was passiert, wenn der freie Wille einer Person nicht mit Ihren Zukunftsklängen übereinstimmt (z.B. aus Protest), diese zu Fall bringt und in die Traumlande transferiert? Haben wir dann nur unterschiedliche Realitäten oder verschiedene Zeitstränge oder gar die Entstehung eines Paralleluniversums?
> Wer zu so einer Behauptung kommt, müsste eigentlich auch ganz klare Antworten auf die obigen Fragen kennen. Wer überdies jene Behauptung äußert, müsste auch sein Wissen teilen und ganz klare Antworten auf die obigen Fragen liefern. Falls nicht, so kann der gesunde Verstand eine solche Aussage nicht ernst nehmen.
Sicher ist: "der gesunde Verstand" kann einen solchen BS nicht ernst nehmen. Realsatire at its best! Unbezahlbar!
Gute Besserung!
Wollen Sie im Umkehrschluss damit andeuten, dass Sie sich Ghuls Aussage "Die Zukunft gehört Rust." kritiklos anschließen?
Spielen Sie Ihre Spielchen doch mit sich selbst.
Wenn Sie es wirklich meinen, wieso äußern Sie es dann? Reden ist Silber - Schweigen ist Gold! Vor Allem, wenn man nichts zu sagen hat...
> Wenn Sie es wirklich meinen, wieso äußern Sie es dann? Reden ist Silber - Schweigen ist Gold!
Sagt jetzt es ausgerechnet der Mensch mit Wortdurchfall. Ihre unfreiwillige Komik ist einfach köstlich.
Frage ist was mit Rust passiert wenn Mozilla sein Sponsoring einstellt und seine Entwickler abzieht.
Sowas lässt aufhorchen.
Hast du dir den verlinkten Blogpost mal durchgelesen?
Der verlässt das Projekt, weil er was neues sucht und nicht, weil ihn irgendwas an Mozilla oder Rust stört.
Er ist von Rust und seiner Community beeindruckt und weiß das Projekt in sicheren Händen.
Eine Stimme, die sich beruflich nur umorientieren möchte.
Ich sehe da kein Problem für Rust.
> Hast du dir den verlinkten Blogpost mal durchgelesen?
Siehe da. Ein Horst ergreift das Wort und stellt die Frage in den Raum ob die Quelle auch gelesen wurde ohne sie selbst gelesen zu haben.
Hier, nur für dich mein lieber Horst, direkt aus den Kommentaren rauskopiert:
> What’s really important is this: I’m not proud to be a Mozillian anymore. A variety of incidents contributed to this, but at the end of the day, it’s what’s true. Furthermore, I don’t have any personal opportunity at Mozilla; I recently discovered I’m the lowest-paid person on my team, and Mozilla doesn’t pay particularly well in the first place. In order to have any kind of career growth, I would have to not do the work that aligns with my skills, and what I’m doing now is really how I can have the most impact on Rust moving forward. I don’t believe that has any chance of changing; when I’ve tried to express my frustrations, I’ve only gotten disciplined. Mozilla is not interested in hearing what I have to say.
Das, mein lieber Horst, ist der dritte Rust-Coreentwickler der in kurzer Zeit das Handtuch schmeisst. Guck dir doch mal an was noch bleiben würde wenn sie alle weg gehen. Ob nun, wie in diesem Fall, weil es ein Nebenlaufprojekt ist oder weil Mozilla das nach 7 Jahren einstellt. Was würde übr8g bleiben jenseits von einem Servo-Prototypen?
Das Problem liegt hier aber nicht an Rust, sondern an der Bezahlung seitens Mozilla.
Wenn man halt 160000 Dollar pro Jahr verdienen will, aber Mozilla nur 110000 Dollar bezahlt, dann ist doch klar, dass die Entwickler zu Microsoft und Co abwandern, die besser bezahlen.
Mit der Sprache hat das aber nichts zu tun. Die hat schon alle für eine Sprache notwendige Sprachelemente und LLVM Compiler wird von vielen Firmen, Organisationen und Entwicklern weiterentwickelt.
Und wo steht, dass das ein Rust-Coreentwickler ist?
Worin liegt also der Unterschied zu den Worten von xyz oben "[...] wenn Mozilla sein Sponsoring einstellt und seine Entwickler abzieht."?
Ihr Argument zieht nicht, denn eine Sprache muss gepflegt und weiterentwickelt werden, um erfolgreich zu sein.Also hat es sehr wohl etwas mit Rust als Sprache zu tun. Wie kommen Sie darauf, dass es das nicht täte?... möglicherweise nirgendwo. Unabhängig davon wie man den Begriff "Coreentwickler" definiert, sprechen die Zahlen schon für sich: siehe bspw. #Commits von Nick Cameron (Kündigungsnachricht via xyz oben) und Steve Klabnik (Kündigungsnachricht via Blogeintrag von Nick Cameron), bzw. die Contributor Graphs der jeweiligen Projekte im direkten Vergleich zur absoluten Anzahl aller Beteiligten.
P.S.: Waren Sie sich wiedereinmal zu bequem, durch Eigeninitiative selbst Antworten auf Ihre Fragen zu recherchieren? Und wieso nehmen Sie das als Anlass, die Fakten mithilfe mangelhafter Argumente oder Suggestivfragen verdrehen zu versuchen?
Hier kostet der Liter Diesel zur Zeit 1,209 €.
Und Pottwale verrecken elendig, weil sie Plastik für Nahrung halten.
ACK, es gibt wirklich Wichtigeres als "V".
Das stimmt natürlich.
Aber "V" ist offensichtlich wichtig genug, sodass Sie sich gezwungen fühlen, unsachliche Beiträge samt ad hominem zur Diskussion abliefern zu müssen, siehe oben.
Und klebrig sind Sie auch noch.
q.e.d.
kk() {}