41–46 of 46 posts
Earlier quoted context omitted.
This. The fact that, as opposed to to Goroutines, Erlang processes can be transparently running on some other node is the most important difference.
Akka does that as well, and you're right, it's very important for writing declarative, distributed logic. Akka's ActorRef abstracts over the physical location of the actor, just as Erlang's PIDs do.
Earlier quoted context omitted.
In Go, channels can be between boxes, so a channel could be used to trigger or communicate with Go code running on another box.
Oh, could you please show me some code that does this (a 'channel between boxes'), and supports sending of exactly the same data types that you send over a regular Go channel? Using the old deprecated netchan package doesn't count ;).
Erlang's error checking model is a great deal more like Go's than he thinks. Erlang is in the "exceptions are exceptional" camp too, and idiomatic code should not be throwing exceptions around willy-nilly. Go is noticably more fragile with errors. Unhandled exceptions (which are just a fact of life unless you're a perfect programmer) will result in the entire program terminating if you don't have something that handl…
> I want a better Erlang than Erlang, but talking yourself into how Go is already better than Erlang isn't going to get you there. I don't mean to go against this point--it's very true, and I think it's important--but I think this conversation (and most comparisons of Go with Erlang) miss something: Erlang is a platform (it has its own VM, and basically its own OS, just relying on the outer OS as a hypervisor.) Meanw…
In fact, let me underline that... the UNIX platform is a GREAT deal weaker than the Erlang platform on this front. It has faint shadows of what Erlang supports, which are incredibly heavyweight, far less reliable, FAR less granular, and effectively can not be used the way Erlang's can be. It's an answer, sure, but it's not even in the same league in this particular way, so don't fool yourself otherwise.
Of course UNIX has other advantages, but, well, that's why I run Erlang on UNIX, so....
Earlier quoted context omitted.
> Meanwhile, Go isn't a platform, nor is it trying to be. Its designers (Rob Pike and Ken Thompson) already made the platform, first, a long time ago. It was called Unix. This is great, and I think many of Go's advocates - including devs at Google - underplay it. I don't understand why, particularly given the pedigree of Pike and Thompson. My approach to building large systems in Go is based around processing pipelin…
I have been playing around with Go on Windows- I really like it (especially the built-in concurrency types) but after reading these comments I feel like I would be better off trying it on UNIX (my mac will do). It probably does not help I am still somewhat lost on UNIX, either, but could you give an example of what a 'processing pipeline' approach would look like? That sounds very much like functional programming to…
Earlier quoted context omitted.
In Go, channels can be between boxes, so a channel could be used to trigger or communicate with Go code running on another box.
Oh, could you please show me some code that does this (a 'channel between boxes'), and supports sending of exactly the same data types that you send over a regular Go channel? Using the old deprecated netchan package doesn't count ;).
Earlier quoted context omitted.
> Meanwhile, Go isn't a platform, nor is it trying to be. Its designers (Rob Pike and Ken Thompson) already made the platform, first, a long time ago. It was called Unix. This is great, and I think many of Go's advocates - including devs at Google - underplay it. I don't understand why, particularly given the pedigree of Pike and Thompson. My approach to building large systems in Go is based around processing pipelin…
I have been playing around with Go on Windows- I really like it (especially the built-in concurrency types) but after reading these comments I feel like I would be better off trying it on UNIX (my mac will do). It probably does not help I am still somewhat lost on UNIX, either, but could you give an example of what a 'processing pipeline' approach would look like? That sounds very much like functional programming to…
For example: one system I implemented needs to take a few hundred very large CSV files every day, aggregate and sort them, perform some complex processing on them, and output a result in a very different format to many different output files. It's an extremely complex system, and each component is in Go, performing a specific task, e.g.:
* combining the many source files * cleaning the source files * performing some aggregation on the stream * splitting the stream into many parts that other components can read from in parallel ('named pipes' in unix make this very nice) * splitting the stream into many output files
etc. Every component is dumb and does one thing, but a single controlling program is responsible for handling command line arguments that describe the overall outcome and setting up the stdin and stdout stream of all of the components to create the final result.
There's a beautiful simplicity to systems implemented like this, and it means you can take advantage of existing tools like grep, awk, sed, sort, cut, etc. to do a lot of the heavy lifting more reliably and quickly than you could probably implement yourself, while still coding the overall system at a reasonably high level of abstraction. Go doesn't lead to this approach directly, but it's very pleasant working with it as a citizen of this wider environment.