13 ms·

Out of curiosity, why is it that you wouldn't want Go for such a task? Is it the lack of maturity, dislike for the language itself?

Ygg2 12y ago
Probably the GC. Rust once finished and proved should be safe for concurrent usage AND without GC cleanup. That's a major feat of engineering.
- matthewmacleod 12y ago
  That's a major feat of engineering Absolutely, but it's not a reason to not use Go. The web is probably the platform with the least possible damage caused by GC. It's OK if people like the language and want to use it for web development, though. I'm personally pretty excited about it, because I'm not a huge fan of Go and Rust looks pretty neat.
- nkozyra 12y ago
  "On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. A careful programmer can reduce the garbage collection overhead dramatically by using the language well; see the article about profiling Go programs for a worked example, including a demonstration of Go's profiling tools." And "The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach." (which I'm certain it will) http://golang.org/doc/faq#garbage_collection http://golang.org/doc/faq#garbage_collection
  - pcwalton 12y ago
    > On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. That's true (although I would question the use of "allocation" there—I think Java has as much control over when you allocate as Go does), but "some control" is not always enough control.
- personZ 12y ago
  While the web is one place where GCs have been well proven and a non-problem, are there actually any cases at all with Go where the GC became a problem? It seems like this GC advocacy is based upon a checkmark more than a reality. My experience has been that Go has very lightweight GC. The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). It, by design, minimizes the amount of work that the GC needs to do, and in most real projects it just becomes a complete non-issue.
  - pcwalton 12y ago
    > It seems like this GC advocacy is based upon a checkmark more than a reality. There are many domains in which GC is a deal-breaker, simply because you lose the fine-grained control over memory that you require: for example, games, embedded systems, kernels, and browser engines. (Go does not give you control over memory in the same way that C++, for example, does; consider map elements or closure upvars.) > The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). No, .NET and Java do escape analysis as well. The difference is that the JVM and CLR have generational garbage collectors with a copying nursery, so heap allocations are essentially as cheap as stack allocations: just a pointer bump. In the JVM (in contrast to Go) escape analysis is mainly used for eliding locks; allocation is so cheap that promoting heap allocations to stack allocations barely matters.
    - personZ 12y ago
      There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies. You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?), but it's interesting that you did exactly what I said -- it's just a checkmark. "GC baaaaaaad". Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language. Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that. No, .NET and Java do escape analysis as well. .NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding. so heap allocations are essentially as cheap as stack allocations: just a pointer bump When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
- stcredzero 12y ago
  Probably the GC. Have you done a back of the envelope calculation to justify this? I have a Javascript/browser MMO engine backend that's written in Go. I simply invoke the garbage collector every world-tick (8 times a second) and that works great for me. I can manage a huge world with GC pauses as large as 20ms.
  - Ygg2 12y ago
    Ok, and? Go is ok for server, that much is a given. Rust is X for server. Generally Rust is on par with C but how well will it work on server is anyone's guess.
    - stcredzero 12y ago
      My point is that you may not have to wait for Rust to be completed for a suitable server language. Do some back of the envelope calcs and quantify your needs in a concrete way.
scriptdevil 12y ago
I am rooting for Rust to succeed because I love strong types and the Rust type-system is a good bit more sophisticated than Go.

Ygg2 12y ago

Probably the GC. Rust once finished and proved should be safe for concurrent usage AND without GC cleanup. That's a major feat of engineering.

matthewmacleod 12y ago
That's a major feat of engineering Absolutely, but it's not a reason to not use Go. The web is probably the platform with the least possible damage caused by GC. It's OK if people like the language and want to use it for web development, though. I'm personally pretty excited about it, because I'm not a huge fan of Go and Rust looks pretty neat.
nkozyra 12y ago
"On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. A careful programmer can reduce the garbage collection overhead dramatically by using the language well; see the article about profiling Go programs for a worked example, including a demonstration of Go's profiling tools." And "The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach." (which I'm certain it will) http://golang.org/doc/faq#garbage_collection http://golang.org/doc/faq#garbage_collection
- pcwalton 12y ago
  > On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. That's true (although I would question the use of "allocation" there—I think Java has as much control over when you allocate as Go does), but "some control" is not always enough control.
personZ 12y ago
While the web is one place where GCs have been well proven and a non-problem, are there actually any cases at all with Go where the GC became a problem? It seems like this GC advocacy is based upon a checkmark more than a reality. My experience has been that Go has very lightweight GC. The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). It, by design, minimizes the amount of work that the GC needs to do, and in most real projects it just becomes a complete non-issue.
- pcwalton 12y ago
  > It seems like this GC advocacy is based upon a checkmark more than a reality. There are many domains in which GC is a deal-breaker, simply because you lose the fine-grained control over memory that you require: for example, games, embedded systems, kernels, and browser engines. (Go does not give you control over memory in the same way that C++, for example, does; consider map elements or closure upvars.) > The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). No, .NET and Java do escape analysis as well. The difference is that the JVM and CLR have generational garbage collectors with a copying nursery, so heap allocations are essentially as cheap as stack allocations: just a pointer bump. In the JVM (in contrast to Go) escape analysis is mainly used for eliding locks; allocation is so cheap that promoting heap allocations to stack allocations barely matters.
  - personZ 12y ago
    There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies. You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?), but it's interesting that you did exactly what I said -- it's just a checkmark. "GC baaaaaaad". Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language. Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that. No, .NET and Java do escape analysis as well. .NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding. so heap allocations are essentially as cheap as stack allocations: just a pointer bump When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
stcredzero 12y ago
Probably the GC. Have you done a back of the envelope calculation to justify this? I have a Javascript/browser MMO engine backend that's written in Go. I simply invoke the garbage collector every world-tick (8 times a second) and that works great for me. I can manage a huge world with GC pauses as large as 20ms.
- Ygg2 12y ago
  Ok, and? Go is ok for server, that much is a given. Rust is X for server. Generally Rust is on par with C but how well will it work on server is anyone's guess.
  - stcredzero 12y ago
    My point is that you may not have to wait for Rust to be completed for a suitable server language. Do some back of the envelope calcs and quantify your needs in a concrete way.

scriptdevil 12y ago

I am rooting for Rust to succeed because I love strong types and the Rust type-system is a good bit more sophisticated than Go.