Ich glaube die haben eher andere Probleme als die Programmiersprache.

[Sinnfrei]

Wenn man sich an gewisse Standards hält ist C nicht unsicher. Und wenn man sich nicht an Grundlagen für sicheres Programmieren halten kann, dann sollte man besser ganz die Finger davon lassen. Auch in Rust oder Go kann man Fehler machen, welche die Sicherheit gefährden, abgesehen davon, dass Rust und Go sicher selbst auch Fehler mitbringen.

__________________
...

[Klausens]

Anything that can go wrong will go wrong.

Also sorg dafür, dass möglichst viele Probleme garnicht erst passieren können.

[Anonymer Nutzer]

ja, aber sie sind doch gerade so hipp und cool. wer heutzutage voll am puls der zeit sein will, musst doch fast go oder rust schreiben. vor allem, weil so tolle firmen hinter beiden sprachen stecken. :-)

[stiGGG]

Sinnfrei schrieb:
--------------------------------------------------------------------------------
> Wenn man sich an gewisse Standards hält ist C nicht unsicher. Und wenn man
> sich nicht an Grundlagen für sicheres Programmieren halten kann, dann
> sollte man besser ganz die Finger davon lassen.

In 45 Jahren C hat die Menschheit jetzt langsam begriffen, dass das in der Praxis, abseits von 4 Zeilen Spielprojekten, eben nicht geht und jetzt kommst du?



1 mal bearbeitet, zuletzt am 04.01.17 14:36 durch stiGGG.

[bernd71]

Es gibt halt Sprachen die sind für Web Services und Parallelisierung einfach besser geeignet als C.

[mnementh]

Sinnfrei schrieb:
--------------------------------------------------------------------------------
> Wenn man sich an gewisse Standards hält ist C nicht unsicher. Und wenn man
> sich nicht an Grundlagen für sicheres Programmieren halten kann, dann
> sollte man besser ganz die Finger davon lassen. Auch in Rust oder Go kann
> man Fehler machen, welche die Sicherheit gefährden, abgesehen davon, dass
> Rust und Go sicher selbst auch Fehler mitbringen.

C und C++ enthalten viel mehr Fallstricke als so manche moderne Sprache. Schon allein das automatische Verhindern von Überläufen durch das Sprachdesign ist ein Vorteil der viele Probleme vermeidet. Das heißt nicht dass deshalb automatisch alles richtig ist, aber weniger Fehler ist doch schon mal ein Vorteil.

[Anonymer Nutzer]

dem kann ich nicht zustimmen. die sprache hat damit nichts zu tun. es geht rein um die standard bibliothek. sag mir ein beispiel, bei dem go für paralleles besser geeignet ist als c mit threads? vor allem, weil alle sprachen es ja schlussendlich eh mit c und threads implementieren. die sprachen sind nur wrapper über die api des os, die mit c/c++ direkter angesprochen wird.

[shoggothe]

Die Go-Runtime unterstützt leichtgewichtige Threads (Goroutines). Von denen darf es gleichzeitig 100.000 oder mehr geben, da nur sehr kleine Stacks reserviert werden (die wachsen können).

Das Denkmodell hinter Threads und deren Synchronisation ist intuitiver und weniger fehleranfällig. Statt den konkurrierenden Zugriff auf gemeinsame Daten mittels kritischer Pfade zu schützen/zu synchronisieren wird durch Datenaustausch zwischen den Threads synchronisiert. Vereinfacht; ein Thread blockiert solange bis ein anderer Thread benötigte Daten liefert und umgekehrt.

[stiGGG]

bjs schrieb:
--------------------------------------------------------------------------------
> dem kann ich nicht zustimmen. die sprache hat damit nichts zu tun. es geht
> rein um die standard bibliothek. sag mir ein beispiel, bei dem go für
> paralleles besser geeignet ist als c mit threads? vor allem, weil alle
> sprachen es ja schlussendlich eh mit c und threads implementieren. die
> sprachen sind nur wrapper über die api des os, die mit c/c++ direkter
> angesprochen wird.

Das ist doch gerade bei golang nicht der Fall. Go Routines werden in der der Runtime erzeugt und nicht über Threads vom Kernel, was für viele Einsatzzwecke schneller ist aber auch so absurde Sachen mitbringt, dass man dem Compiler sagen muss wieviele Cores das Zielsystem hat.

[Anonymer Nutzer]

ja... aber die runtime verwendet trotzdem dann os threads. rust und go haben halt wrapper darum. is ja ok, aber man sollte es halt dann doch nicht vergessen.

[pythoneer]

bjs schrieb:
--------------------------------------------------------------------------------
> ja... aber die runtime verwendet trotzdem dann os threads. rust und go
> haben halt wrapper darum. is ja ok, aber man sollte es halt dann doch nicht
> vergessen.

Und C ist ein Wrapper um Assembler, was genau möchtest du uns sagen? Das man mit Assembler alles machen kann was man in Rust und Go kann? Das man in Assembler genauso sicheren Code machen kann wie in Go und Rust? Ja kann man. Aber man kann es eben nicht so gut.

[Anonymer Nutzer]

ja, genau, das will ich sagen.

[stiGGG]

bjs schrieb:
--------------------------------------------------------------------------------
> ja... aber die runtime verwendet trotzdem dann os threads.

In golang nur wenn eine goroutine blockt.

[Anonymer Nutzer]

nein, auch ohne. wenn nicht, würde man threads nie auf mehr als einen core/ht-thread/prozessor aufteilen können. ohne support des os kann man nur einen code verwenden. software im userspace hat keine möglichkeit ohne os support mehr als einen core auszunützen.

[mnementh]

bjs schrieb:
--------------------------------------------------------------------------------
> dem kann ich nicht zustimmen. die sprache hat damit nichts zu tun. es geht
> rein um die standard bibliothek. sag mir ein beispiel, bei dem go für
> paralleles besser geeignet ist als c mit threads? vor allem, weil alle
> sprachen es ja schlussendlich eh mit c und threads implementieren. die
> sprachen sind nur wrapper über die api des os, die mit c/c++ direkter
> angesprochen wird.
Das Betriebssystem wird mit einer API angesprochen. Das hat nichts direkt mit C zu tun.

[crypt0]

bjs schrieb:
--------------------------------------------------------------------------------
> ja... aber die runtime verwendet trotzdem dann os threads. rust und go
> haben halt wrapper darum. is ja ok, aber man sollte es halt dann doch nicht
> vergessen.

Es geht hier nicht darum wie Nebenläufigkeit realisiert/implementiert wird, sondern wie das entsprechende Programmiermodel aussieht.
Das bedeutet, dass Go beispielsweise nicht nur Wrapper um OS threads anbietet, sondern das Go auch ein anderes Concurrency-Programmiermodel (Channels, go-routinen, etc.) anbietet. Mit diesem lassen sich viele nebenläufige Programme "leichter und robuster" schreiben, als mit dem "klassichen" Thread-Model

[mnementh]

bjs schrieb:
--------------------------------------------------------------------------------
> nein, auch ohne. wenn nicht, würde man threads nie auf mehr als einen
> core/ht-thread/prozessor aufteilen können. ohne support des os kann man nur
> einen code verwenden. software im userspace hat keine möglichkeit ohne os
> support mehr als einen core auszunützen.
??? Ich weiß nicht was die Aussage soll. Software ohne OS-Support läuft erst gar nicht, ob Single Thread oder Multi Thread. Wenn Du meinst dass man in den meisten Betriebssystemen Betriebssystemunterstützung benötigt um Threads zu machen, dann stimmt das. Das hat aber immer noch nichts mit C zu tun, man kommuniziert über die API des Betriebssystems.

[Anonymer Nutzer]

naja, du stimmst ja zu, dass die aussage korrekt ist. dann is ja alles gut. :-)

[mnementh]

bjs schrieb:
--------------------------------------------------------------------------------
> naja, du stimmst ja zu, dass die aussage korrekt ist. dann is ja alles gut.
> :-)
Ja, aber C verwendet die gleiche API. Es ist kein Unterschied.

[pythoneer]

bjs schrieb:
--------------------------------------------------------------------------------
> ja, genau, das will ich sagen.

Dann schreib das doch auch so. Für mich und wahrscheinlich auch die anderen klang das so.

bernd71:
Es gibt halt Sprachen die sind für Web Services und Parallelisierung einfach besser geeignet als C.

bjs:
dem kann ich nicht zustimmen.

pythoneer:
was genau möchtest du uns sagen?
Das man mit Assembler alles machen kann was man in Rust und Go kann?

bjs:
ja, genau, das will ich sagen.


Du willst also im Endeffekt sagen, dass man Web Services und Parallelisierung am besten mit Assembler schreibt, weil die Sprache keine Rolle spielt und es keine anderen Sprachen als Assembler gibt die dafür besser geeignet wären, weil man mit Assembler eben auch das machen kann was die anderen können nur halt nicht so komfortabel – was für dich aber kein Problem ist. Interessant!