Go erinnert mich an Occam. http://de.wikipedia.org/wiki/Occam
Beide sind compilierbare Sprachen und unterstützen Parallelität explizit.
Go bringt zusätzlich Objektorientierung und asynchrone Channels, die ich in Occam vermisst habe.
Occam hat aber explizite Statements für SEQ, PAR und ALT sowie PLACED PAR. Ausserdem fand ich gut, dass dort nicht geklammert wird, sondern um 2 Spaces eingerückt wird. Dieses Konzept wird durch Folding Editoren hervorragend unterstützt. http://www.transputer.net/tn/16/tn16.html#x1-130004.2
Neuen Programmiersprachen stehe ich prinzipiell kritisch gegenüber. Bei Google werden Projekte auch mal wieder schnell aufgegeben. Nach meiner Meinung kann man Vieles auch durch Bibliotheken abdecken und braucht nicht erst eine neue Sprache zu erfinden.
In unserem OSS Projekt setzen wir z.B. auf C/C++ und eine eigene Bibliothek.
Channels werden durch eine eigene Socket Klasse implementiert (Asynchronität/Fifo ist dort auch vorhanden) Das hat den Nebeneffekt, dass parallele Anwendungen auf Netzwerke verteilt werden können. http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSocket.html
Parallelität wird durch Thread, Mutex und Semaphore Klassen unterstützt, die Windows und Unixoide unter einen Hut bringen. http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlThread.html http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlMutex.html http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSemaphore.html
Der select() Aufruf kann auf Sockets angewendet werden, um ALT in Occam zu ersetzen.
Dieses Vorgehen hat mir in all den Jahren nach dem Transputer geholfen, die dort gewonnen Erkenntnisse weiter anwenden zu können. Hier ist die Doxygen Doc unserer Bibliothek, die portabel zwischen Unixoiden, Windows und OpenVMS ist. http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.html
Beide basieren auf Hoare's CSP. Occam war meines Wissens nach die erste Programmiersprache, die CSP umsetzte, unter Mitwirkung von Hoare. Später hat Rob Pike bei den Bell Labs Newsqueak und Limbo entwickelt und Phil Winterbottom Alef, die noch zusätzlich Channels einführten. CSP hatte bei den Bell Labs eine lange Tradition. Siehe auch Rob Pike's Talk Origins of Go Concurrency (Video)
Thompson, Pike und ein paar andere Plan9-er sind von den Bell Labs zu Google gewechselt und haben zusammen mit anderen Google-Kollegen und der Open-Source-Gemeinschaft nun Go entwickelt, nachdem sie über die monströsen C++ Codebasen bei Google die Hände über den Kopf geschlagen haben.
SEQ ist ein Code-Block in Go, PAR ist "go" in Go und ALT ist "select" in Go.
> Parallelität wird durch Thread, Mutex und Semaphore Klassen unterstützt
Ein Vorteil von Goroutines gegenüber Threads ist, dass nicht jede Goroutine automatisch einen Thread mit seinem ganzen Overhead erzeugt, sondern sie werden nach Notwendigkeit auf weniger Threads gemultiplext. Goroutinen haben einen kleineren Stack, der später dynamisch wachsen und schrumpfen kann, man kann problemlos hunderttausende davon erzeugen. Node.js versucht den schwergewichtigen Threads mit dem asynchronen Eventloop-basierten Callback-Geraffel zu entgehen. In Go kann hingegen einfach pro Request eine Goroutine erzeugt werden, weil sie so leichtgewichtig sind, und dann sequentiell programmieren, weil bei einem blockierenden Call einfach eine andere Goroutine geschedult wird.
> man kann problemlos hunderttausende davon erzeugen. Das ist in Occam ähnlich.
Bei der Anwendung in unserem OSS Projekt sollten aber normale Threads auch OK sein.
Wenn ein neuer Client kommt, wird ein Thread erzeugt. Beim Programmstart werden einige Threads erzeugt, die dann die ganze Zeit durchlaufen (Datenerfassung) Beim Programmstart werden auch einige Threads erzeugt, die Zustandsmaschinen permanent abarbeiten (wie eine SPS)
Nur ganz kurzzeitig gestartete "Threads", die sich dann schnell wieder beenden, haben wir da eigentlich nicht.
...damals mit dem FluxCompensator ging das ja auch noch. Was mich bloß immer gestört hat, waren die nicht-initialisierbaren types und vor allem dass es nur bedingt parallelisierbare EntryStackVolumeClassPointer gab (diese ESVCPs-Geschichte war ja im Prinzip schon clever). Bin seitdem eher in Vorgol unterwegs, da kann man eher threadorientiert coden und rutsch nicht nur auf dem Metaputer rum.
Von den Leuten, die uns B, Unix, Plan 9, UTF-8 und den Java-Hotspot-Compiler brachten ...
Ist das jetzt Lob oder Kritik?
Ich verstehe das eher als Lob.
Nun ich hatte dies auch als ein Lob aufgefasst.
War nur ein wertneutrales Statement.
Go erinnert mich an Occam.
http://de.wikipedia.org/wiki/Occam
Beide sind compilierbare Sprachen und unterstützen Parallelität explizit.
Go bringt zusätzlich Objektorientierung und asynchrone Channels, die ich in Occam vermisst habe.
Occam hat aber explizite Statements für SEQ, PAR und ALT sowie PLACED PAR.
Ausserdem fand ich gut, dass dort nicht geklammert wird, sondern um 2 Spaces eingerückt wird.
Dieses Konzept wird durch Folding Editoren hervorragend unterstützt.
http://www.transputer.net/tn/16/tn16.html#x1-130004.2
Neuen Programmiersprachen stehe ich prinzipiell kritisch gegenüber.
Bei Google werden Projekte auch mal wieder schnell aufgegeben.
Nach meiner Meinung kann man Vieles auch durch Bibliotheken abdecken und braucht nicht erst eine neue Sprache zu erfinden.
In unserem OSS Projekt setzen wir z.B. auf C/C++ und eine eigene Bibliothek.
Channels werden durch eine eigene Socket Klasse implementiert (Asynchronität/Fifo ist dort auch vorhanden)
Das hat den Nebeneffekt, dass parallele Anwendungen auf Netzwerke verteilt werden können.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSocket.html
Parallelität wird durch Thread, Mutex und Semaphore Klassen unterstützt, die Windows und Unixoide unter einen Hut bringen.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlThread.html
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlMutex.html
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSemaphore.html
Der select() Aufruf kann auf Sockets angewendet werden, um ALT in Occam zu ersetzen.
Dieses Vorgehen hat mir in all den Jahren nach dem Transputer geholfen, die dort gewonnen Erkenntnisse weiter anwenden zu können.
Hier ist die Doxygen Doc unserer Bibliothek, die portabel zwischen Unixoiden, Windows und OpenVMS ist.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.html
Unser Projekt:
http://pvbrowser.org
Beide basieren auf Hoare's CSP. Occam war meines Wissens nach die erste Programmiersprache, die CSP umsetzte, unter Mitwirkung von Hoare. Später hat Rob Pike bei den Bell Labs Newsqueak und Limbo entwickelt und Phil Winterbottom Alef, die noch zusätzlich Channels einführten. CSP hatte bei den Bell Labs eine lange Tradition. Siehe auch Rob Pike's Talk Origins of Go Concurrency (Video)
Thompson, Pike und ein paar andere Plan9-er sind von den Bell Labs zu Google gewechselt und haben zusammen mit anderen Google-Kollegen und der Open-Source-Gemeinschaft nun Go entwickelt, nachdem sie über die monströsen C++ Codebasen bei Google die Hände über den Kopf geschlagen haben.
SEQ ist ein Code-Block in Go, PAR ist "go" in Go und ALT ist "select" in Go.
Hier sind übrigens die Slides zum Talk.
> Parallelität wird durch Thread, Mutex und Semaphore Klassen unterstützt
Ein Vorteil von Goroutines gegenüber Threads ist, dass nicht jede Goroutine automatisch einen Thread mit seinem ganzen Overhead erzeugt, sondern sie werden nach Notwendigkeit auf weniger Threads gemultiplext. Goroutinen haben einen kleineren Stack, der später dynamisch wachsen und schrumpfen kann, man kann problemlos hunderttausende davon erzeugen. Node.js versucht den schwergewichtigen Threads mit dem asynchronen Eventloop-basierten Callback-Geraffel zu entgehen. In Go kann hingegen einfach pro Request eine Goroutine erzeugt werden, weil sie so leichtgewichtig sind, und dann sequentiell programmieren, weil bei einem blockierenden Call einfach eine andere Goroutine geschedult wird.
> man kann problemlos hunderttausende davon erzeugen.
Das ist in Occam ähnlich.
Bei der Anwendung in unserem OSS Projekt sollten aber normale Threads auch OK sein.
Wenn ein neuer Client kommt, wird ein Thread erzeugt.
Beim Programmstart werden einige Threads erzeugt, die dann die ganze Zeit durchlaufen (Datenerfassung)
Beim Programmstart werden auch einige Threads erzeugt, die Zustandsmaschinen permanent abarbeiten (wie eine SPS)
Nur ganz kurzzeitig gestartete "Threads", die sich dann schnell wieder beenden, haben wir da eigentlich nicht.
Nachdem du von all den Features gesprochen hast: Hast du dich schon mal mit Erlang beschäftigt?
nein, ich verwende C/C++ sowie. Lua als Scriptinglanguage, die man in einen C/C++ Wirst einbauen kann.
Auf dem Transputer habe ich damals aber auch ParC verwendet.
http://cs.haifa.ac.il/~yosi/PARC/ParCManual.pdf
Lua ist so goldig!!
Eine dieser kleinen, klar umrissenen Programmiersprachen, die ich so liebe.
...damals mit dem FluxCompensator ging das ja auch noch. Was mich bloß immer gestört hat, waren die nicht-initialisierbaren types und vor allem dass es nur bedingt parallelisierbare EntryStackVolumeClassPointer gab (diese ESVCPs-Geschichte war ja im Prinzip schon clever). Bin seitdem eher in Vorgol unterwegs, da kann man eher threadorientiert coden und rutsch nicht nur auf dem Metaputer rum.