<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>rdtsc</author><text>Yes.&lt;p&gt;In Erlang:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    exit(kill).
&lt;/code&gt;&lt;/pre&gt;
or 
    exit(Pid,kill).&lt;p&gt;Will kill a process. It has an isolated heap, so it won&amp;#x27;t affect other (possibly hundreds of thousands of) running processes. That memory will be garbage collected, safely and efficiently.&lt;p&gt;This will also work in Elixir, LFE and other languages running on the BEAM VM platform.&lt;p&gt;EDIT: masklinn user below pointed out correctly, the example is exit&amp;#x2F;2, that is exit(Pid,kill). In fact it is just exit(Pid, Reason), where Reason can be other exit reason, like say my_socket_failed. However in that case the process could catch it and handle that signal instead of being un-conditionally killed.</text><parent_chain><item><author>IshKebab</author><text>There&amp;#x27;s no way to kill goroutines either. In fact, are there any systems that allow you to cleanly kill threads?</text></item><item><author>gregwebs</author><text>Send + Sync are great. The downside of concurrency in Rust is:&lt;p&gt;1) There isn&amp;#x27;t transparent integration with IO in the runtime as in Go or Haskell. Rust probably won&amp;#x27;t ever do this because although such a model scales well in general, it does create overhead and a runtime.&lt;p&gt;2) OS threads are difficult to work with compared to a nice M:N threading abstraction (which again are the default in Go or Haskell). OS threads leads to lowest common denominator APIs (there is no way to kill a thread in Rust) and some difficulty in reasoning about performance implications. I am attempting to solve this aspect by using the mioco library, although due to point #1 IO is going to be a little awkward.</text></item></parent_chain></comment><story><title>Concurrency in Rust</title><url>http://doc.rust-lang.org/book/concurrency.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>steveklabnik</author><text>Every one I know of has regretted it, and seen it as an antipattern. For example, Java way back in 1.5: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;docs.oracle.com&amp;#x2F;javase&amp;#x2F;1.5.0&amp;#x2F;docs&amp;#x2F;guide&amp;#x2F;misc&amp;#x2F;threadPrimitiveDeprecation.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;docs.oracle.com&amp;#x2F;javase&amp;#x2F;1.5.0&amp;#x2F;docs&amp;#x2F;guide&amp;#x2F;misc&amp;#x2F;threadPr...&lt;/a&gt;&lt;p&gt;I think Erlang might be okay with it, because &amp;quot;this thread can fail at any time&amp;quot; is a core value of Erlang. But it&amp;#x27;s an exception.</text><parent_chain><item><author>IshKebab</author><text>There&amp;#x27;s no way to kill goroutines either. In fact, are there any systems that allow you to cleanly kill threads?</text></item><item><author>gregwebs</author><text>Send + Sync are great. The downside of concurrency in Rust is:&lt;p&gt;1) There isn&amp;#x27;t transparent integration with IO in the runtime as in Go or Haskell. Rust probably won&amp;#x27;t ever do this because although such a model scales well in general, it does create overhead and a runtime.&lt;p&gt;2) OS threads are difficult to work with compared to a nice M:N threading abstraction (which again are the default in Go or Haskell). OS threads leads to lowest common denominator APIs (there is no way to kill a thread in Rust) and some difficulty in reasoning about performance implications. I am attempting to solve this aspect by using the mioco library, although due to point #1 IO is going to be a little awkward.</text></item></parent_chain></comment><story><title>Concurrency in Rust</title><url>http://doc.rust-lang.org/book/concurrency.html</url></story>