Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprachen…

Ich glaube die haben eher andere Probleme als die Programmiersprache.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Sinnfrei 04.01.17 - 13:58

    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.

    __________________
    ...

  2. Ich halts da eher mit dem Spruch

    Autor: Klausens 04.01.17 - 14:07

    Anything that can go wrong will go wrong.

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

  3. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 14:25

    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. :-)

  4. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: stiGGG 04.01.17 - 14:27

    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.

  5. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: bernd71 04.01.17 - 14:52

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

  6. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: mnementh 04.01.17 - 14:59

    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.

  7. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 15:00

    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.

  8. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: shoggothe 04.01.17 - 15:36

    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.

  9. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: stiGGG 04.01.17 - 15:43

    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.

  10. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 15:45

    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.

  11. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: pythoneer 04.01.17 - 15:54

    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.

  12. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 15:54

    ja, genau, das will ich sagen.

  13. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: stiGGG 04.01.17 - 15:58

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

    In golang nur wenn eine goroutine blockt.

  14. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 16:01

    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.

  15. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: mnementh 04.01.17 - 16:08

    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.

  16. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: crypt0 04.01.17 - 16:10

    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

  17. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: mnementh 04.01.17 - 16:12

    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.

  18. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: Anonymer Nutzer 04.01.17 - 16:16

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

  19. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: mnementh 04.01.17 - 16:18

    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.

  20. Re: Ich glaube die haben eher andere Probleme als die Programmiersprache.

    Autor: pythoneer 04.01.17 - 16:44

    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!

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, München, Meckenheim
  2. VPV Versicherungen, Stuttgart
  3. Rational AG, München
  4. BWI GmbH, Nürnberg, Bonn, Berlin, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,32€
  2. (-80%) 1,99€
  3. (-75%) 3,75€
  4. 4,19€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Projektorkauf: Lumen, ANSI und mehr
Projektorkauf
Lumen, ANSI und mehr

Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
Von Mike Wobker


    Radeon RX 5700 (XT) im Test: AMDs günstige Navi-Karten sind auch super
    Radeon RX 5700 (XT) im Test
    AMDs günstige Navi-Karten sind auch super

    Die Radeon RX 5700 (XT) liefern nach einer Preissenkung vor dem Launch eine gute Leistung ab: Wer auf Hardware-Raytracing verzichten kann, erhält zwei empfehlenswerte Navi-Grafikkarten. Bei der Energie-Effizienz hapert es aber trotz moderner 7-nm-Technik immer noch etwas.
    Ein Test von Marc Sauter

    1. Navi 14 Radeon RX 5600 (XT) könnte 1.536 Shader haben
    2. Radeon RX 5700 (XT) AMD senkt Navi-Preise noch vor Launch
    3. AMD Freier Navi-Treiber in Mesa eingepflegt

    In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
    In eigener Sache
    Neue Workshops zu agilem Arbeiten und Selbstmanagement

    Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

    1. In eigener Sache ITler und Board kommen zusammen
    2. In eigener Sache Herbsttermin für den Kubernetes-Workshop steht
    3. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung

    1. Tracking: Google und Facebook tracken auch auf vielen Pornoseiten
      Tracking
      Google und Facebook tracken auch auf vielen Pornoseiten

      Forscher haben mehr als 22.000 Pornowebseiten auf Trackingdienste untersucht - und dort auch Google und Facebook gefunden. Diese geben jedoch an, die Daten nicht zu verwenden.

    2. Quartalsbericht: Microsofts Cloud-Geschäft steigert Rekordumsatz
      Quartalsbericht
      Microsofts Cloud-Geschäft steigert Rekordumsatz

      Microsoft hat in einem Quartal über 13,2 Milliarden US-Dollar Gewinn gemacht. Der Cloud-Bereich macht ein Drittel des Umsatzes aus.

    3. Nach Unfall: Wiener Verkehrsbetrieb stoppt autonome Busse
      Nach Unfall
      Wiener Verkehrsbetrieb stoppt autonome Busse

      Nachdem eine Fußgängerin in einen der autonom fahrenden Busse gelaufen ist, hat der Wiener Verkehrsbetrieb das Pilotprojekt erst einmal gestoppt: Die Passantin, die leicht verletzt wurde, ist offensichtlich aus Unachtsamkeit mit dem Fahrzeug kollidiert.


    1. 07:30

    2. 22:38

    3. 17:40

    4. 17:09

    5. 16:30

    6. 16:10

    7. 15:45

    8. 15:22