5 ms·

Erlang is a language with a purpose that I can relate to. I develop a cluster database product, and erlang seems to have an answer for many problems that I have

Erlang is a language with a purpose that I can relate to. I develop a cluster database product, and erlang seems to have an answer for many problems that I have actually faced. For instance: cluster global pids. When you send a message to a pid, you don't have to go through a dance of handling errors and timeouts just because it might live on another node. If the node goes down, there are several ways to handle that, including monitor_node() which gives you a message that you can handle in one place. I haven't used erlang in production, but I've invested some time to learn about it because I see that potential value. I don't really see that from Go. It seems to fall into a "general-purpose" bucket where it competes with Java, C#, python, ruby, haskell, clojure, scala, etc. I don't necessarily like all of those languages, and for any given one you can probably pick out some Go advantages. A lot of people say Go hits a nice sweet spot for many applications. But Go just doesn't speak to any problems I actually have. It can't replace the C/C++ code, because Go has a GC, and the code is C/C++ because it needs to manage memory[1]. It could replace the python code, perhaps to some benefit, but there would still be a bunch of awkward communication between processes and all of the associated error handling mess. And it can't replace Java, because that's a public API we offer, and lots of people are comfortable with Java. Go should have been another cluster language/VM that really could compete with erlang, in my opinion. To me, Go is just another language. [1] Rust does seem to have something to offer here.

cordite 13y ago
As mentioned in the post and having basic experience with go, go doesn't solve my problems and it's presence of nil makes it feel like a fancy C. Rust does have something to offer and I've helped a bit with a thing called oxidize (not the compilation phase in rustc) as an attempt to make a web framework (or at least a routing layer on top of an http lib from the community) I wonder how this author would feel to compare Erlang and Rust once it matures.
jaegerpicker 13y ago
Just because Go doesn't fit your use case doesn't mean it should be something else. In most cases Go IS a better choice than C/C++ in a server side case. For instance let's say you are writing a server for a multiplayer game. Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections. There are drawbacks and risks to managing memory in this type of system and Go's concurrency makes writing this code much easier. Another great go use case is a rest based web service, a lot of these are typically written in Java, Ruby, or Python. I love python but go has serious advantages over all three of those languages in this use case. This is where go was designed to be used and it's best spot. The glue servers that are most commonly used for web applications. Go is designed to be simpler, safer, and easier to write than C/C++, Java, or C# but faster, more modern, and more fault tolerant than python or ruby. It's not a perfect language by any means but it does fill a nice sweet spot.
- stcredzero 13y ago
  I'm writing a multiplayer game in Go. The reason I chose it is that it allows me to control memory layout at a low level. This can be very important for achieving multicore parallelism. (Also known as optimizing for fewer cache misses.)
  - jeffdavis 13y ago
    That's a good point. There aren't a lot of GC languages that let you control structure layout. Not a problem I face, but interesting.
    - stcredzero 13y ago
      Not a problem I face, but interesting. Only a problem you face if you are trying to keep multiple cores busy with low latency.
      - jeffdavis 13y ago
        I think I'm missing your point. Why do you need a GC language for that?
        stcredzero 13y ago
        I was more talking about being able to control memory layout.
- jeffdavis 13y ago
  "Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections." That sounds like a story I've heard a hundred times before. For the cases where it's true, good engineers have already been using one of the many other languages that fills that niche. For cases where that's not the primary problem, Go doesn't help. That doesn't mean Go isn't a better option for some use cases. Great. I just don't understand why it's worth reinventing the universe to get something a little better for some use cases. Fine with me -- I'm not the one doing the work. I am just saying that I don't get it. Especially for Google, a company which could have really made a difference in the way we write software.
stcredzero 13y ago
But Go just doesn't speak to any problems I actually have. It can't replace the C/C++ code, because Go has a GC, and the code is C/C++ because it needs to manage memory[1]. You can write go code that minimizes GC load. It's not like Java or Smalltalk where absolutely everything is a "value" that's really a reference. It's doable to default to pass by value and simply not have lots of pointers all over the place. You won't be able to completely reduce all GC pressure, but it can be minimized.
- jeffdavis 13y ago
  I'm not talking about a few stack allocations. For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. I'm sure there's some theoretical answer from GC folks about how to handle every situation, but in practice it doesn't usually work out well. GC languages target good performance on "normal" applications, where parameter passing and short-term heap allocations are the biggest memory problems you need to deal with.
  - stcredzero 13y ago
    For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. In Go, you can write your system, such that the GC doesn't have to get so involved with your objects on the heap. Simply use arrays and slices and avoid using pointers otherwise. Slices contain pointers, but if they are pointing to structs in an array that themselves contain no pointers, then you will greatly minimize GC pressure. I suspect you can use the "unsafe" package in Go to do allocations outside of the GC heap, in which case, the GC will not bother traversing there. However, there is the question of whether you would want to do this, as you are giving up type safety and GC and Go has no other facilities like RAII. Apparently, programmers at Twitter do tasks of the size you describe with Scala on the Hotspot JVM. http://www.parleys.com/play/514892290364bc17fc56c34b/chapter43/about http://www.parleys.com/play/514892290364bc17fc56c34b/chapter...
    - jeffdavis 13y ago
      We have large processes like that in the JVM as well, so it's not like we're allergic to garbage collectors. But we do see problems that are not a problem in our C code. It's possible that Go might have ways of avoiding this, but it would take a while to evaluate and it doesn't offer much in the way of guarantees (i.e. it may change in the future). Unsafe code would be pointless... Might as well use C. Rust seems to offer memory control, safety, and strong guarantees. That seems more appealing for the problems I work on.

cordite 13y ago

As mentioned in the post and having basic experience with go, go doesn't solve my problems and it's presence of nil makes it feel like a fancy C. Rust does have something to offer and I've helped a bit with a thing called oxidize (not the compilation phase in rustc) as an attempt to make a web framework (or at least a routing layer on top of an http lib from the community) I wonder how this author would feel to compare Erlang and Rust once it matures.

jaegerpicker 13y ago

Just because Go doesn't fit your use case doesn't mean it should be something else. In most cases Go IS a better choice than C/C++ in a server side case. For instance let's say you are writing a server for a multiplayer game. Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections. There are drawbacks and risks to managing memory in this type of system and Go's concurrency makes writing this code much easier. Another great go use case is a rest based web service, a lot of these are typically written in Java, Ruby, or Python. I love python but go has serious advantages over all three of those languages in this use case. This is where go was designed to be used and it's best spot. The glue servers that are most commonly used for web applications. Go is designed to be simpler, safer, and easier to write than C/C++, Java, or C# but faster, more modern, and more fault tolerant than python or ruby. It's not a perfect language by any means but it does fill a nice sweet spot.

stcredzero 13y ago
I'm writing a multiplayer game in Go. The reason I chose it is that it allows me to control memory layout at a low level. This can be very important for achieving multicore parallelism. (Also known as optimizing for fewer cache misses.)
- jeffdavis 13y ago
  That's a good point. There aren't a lot of GC languages that let you control structure layout. Not a problem I face, but interesting.
  - stcredzero 13y ago
    Not a problem I face, but interesting. Only a problem you face if you are trying to keep multiple cores busy with low latency.
    - jeffdavis 13y ago
      I think I'm missing your point. Why do you need a GC language for that?
      - stcredzero 13y ago
        I was more talking about being able to control memory layout.
jeffdavis 13y ago
"Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections." That sounds like a story I've heard a hundred times before. For the cases where it's true, good engineers have already been using one of the many other languages that fills that niche. For cases where that's not the primary problem, Go doesn't help. That doesn't mean Go isn't a better option for some use cases. Great. I just don't understand why it's worth reinventing the universe to get something a little better for some use cases. Fine with me -- I'm not the one doing the work. I am just saying that I don't get it. Especially for Google, a company which could have really made a difference in the way we write software.

stcredzero 13y ago

But Go just doesn't speak to any problems I actually have. It can't replace the C/C++ code, because Go has a GC, and the code is C/C++ because it needs to manage memory[1]. You can write go code that minimizes GC load. It's not like Java or Smalltalk where absolutely everything is a "value" that's really a reference. It's doable to default to pass by value and simply not have lots of pointers all over the place. You won't be able to completely reduce all GC pressure, but it can be minimized.

jeffdavis 13y ago
I'm not talking about a few stack allocations. For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. I'm sure there's some theoretical answer from GC folks about how to handle every situation, but in practice it doesn't usually work out well. GC languages target good performance on "normal" applications, where parameter passing and short-term heap allocations are the biggest memory problems you need to deal with.
- stcredzero 13y ago
  For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. In Go, you can write your system, such that the GC doesn't have to get so involved with your objects on the heap. Simply use arrays and slices and avoid using pointers otherwise. Slices contain pointers, but if they are pointing to structs in an array that themselves contain no pointers, then you will greatly minimize GC pressure. I suspect you can use the "unsafe" package in Go to do allocations outside of the GC heap, in which case, the GC will not bother traversing there. However, there is the question of whether you would want to do this, as you are giving up type safety and GC and Go has no other facilities like RAII. Apparently, programmers at Twitter do tasks of the size you describe with Scala on the Hotspot JVM. http://www.parleys.com/play/514892290364bc17fc56c34b/chapter43/about http://www.parleys.com/play/514892290364bc17fc56c34b/chapter...
  - jeffdavis 13y ago
    We have large processes like that in the JVM as well, so it's not like we're allergic to garbage collectors. But we do see problems that are not a problem in our C code. It's possible that Go might have ways of avoiding this, but it would take a while to evaluate and it doesn't offer much in the way of guarantees (i.e. it may change in the future). Unsafe code would be pointless... Might as well use C. Rust seems to offer memory control, safety, and strong guarantees. That seems more appealing for the problems I work on.