3 ms·

"Systems language" embraces more than kernels and such. Go is a new Erlang; its the Erlang for people who don't like Erlang, perhaps?

masklinn 15y ago
> Go is a new Erlang; It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime). Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.
- willvarfar 15y ago
  Are you confusing concurrency with parallelism? > Erlang's primary goal has always been reliability. Not concurrency Wrong. Concurrency is not some accidental bolt-on in Erlang: http://www.erlang.org/course/history.html http://www.erlang.org/course/history.html Now I picked out Erlang because it has ... garbage collection. I was replying to the parent saying that GC is utterly incompatible with a systems language. Go and Rust are the new Erlangs in that they are the go-to language for system services above kernel level.
  - jamii 15y ago
    Erlang disallows shared memory in favour of per-process gc. Whether or not this is a good tradeoff in general is debatable but it is what makes the gc acceptable in soft-realtime environments. Go makes a different set of tradeoffs (shared mutable memory, whole process gc, no hot code reloading) which place it in a different niche to erlang.
  - masklinn 15y ago
    > Are you confusing concurrency with parallelism? No. > Wrong. Concurrency is not some accidental bolt-on in Erlang You might want to read my comment correctly and avoid injecting things which are not in it. I did not say concurrency was "bolted on", I said it was not a primary goal of Erlang's design, it was merely one of the tool deployed to reach the over-arching goal of reliability. > I was replying to the parent saying that GC is utterly incompatible with a systems language. Can't say I've ever seen Erlang called a systems language. But in any case Erlang's design and VM structure does make it suitable for soft real-time (per-process shared-nothing[0] heaps independently GC'd with configurable initial heaps, allowing such things as never GC'ing a process at all). Go still's no Erlang. [0] aside from reference counted big binaries

masklinn 15y ago

> Go is a new Erlang; It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime). Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.

willvarfar 15y ago
Are you confusing concurrency with parallelism? > Erlang's primary goal has always been reliability. Not concurrency Wrong. Concurrency is not some accidental bolt-on in Erlang: http://www.erlang.org/course/history.html http://www.erlang.org/course/history.html Now I picked out Erlang because it has ... garbage collection. I was replying to the parent saying that GC is utterly incompatible with a systems language. Go and Rust are the new Erlangs in that they are the go-to language for system services above kernel level.
- jamii 15y ago
  Erlang disallows shared memory in favour of per-process gc. Whether or not this is a good tradeoff in general is debatable but it is what makes the gc acceptable in soft-realtime environments. Go makes a different set of tradeoffs (shared mutable memory, whole process gc, no hot code reloading) which place it in a different niche to erlang.
- masklinn 15y ago
  > Are you confusing concurrency with parallelism? No. > Wrong. Concurrency is not some accidental bolt-on in Erlang You might want to read my comment correctly and avoid injecting things which are not in it. I did not say concurrency was "bolted on", I said it was not a primary goal of Erlang's design, it was merely one of the tool deployed to reach the over-arching goal of reliability. > I was replying to the parent saying that GC is utterly incompatible with a systems language. Can't say I've ever seen Erlang called a systems language. But in any case Erlang's design and VM structure does make it suitable for soft real-time (per-process shared-nothing[0] heaps independently GC'd with configurable initial heaps, allowing such things as never GC'ing a process at all). Go still's no Erlang. [0] aside from reference counted big binaries