<story><title>Rust as the New C Part 1: Building and Combining Native Libs into C API</title><url>http://hotforknowledge.com/2019/07/14/6-rust-the-new-c/</url></story><parent_chain><item><author>ChrisSD</author><text>&amp;gt; So despite the fact that many consider Go to be the main Rust competitor for writing complete programs...&lt;p&gt;Really? That seems odd to me. I guess there&amp;#x27;s some overlap between the two languages but they mostly exists in different spheres.&lt;p&gt;C++ would be the more obvious comparison.</text></item></parent_chain><comment><author>buybackoff</author><text>Author here. I have read somewhere (and have two links in the post) that the FFI transition between native code and Go has huge overhead because of Go runtime and bookkeeping Go has to do for making such call safe. But calling Rust e.g. from C# P&amp;#x2F;Invoke has the same cost as calling C library. So the point is that writing a complete program in Go is probably better or equal, e.g. some network utility. But if I write a shared library that I call &lt;i&gt;&lt;/i&gt;a lot&lt;i&gt;&lt;/i&gt; from C# via P&amp;#x2F;Invoke, Go will have much higher overhead. This may be wrong for the latest Go versions, I researched that around a year ago.</text></comment>
<story><title>Rust as the New C Part 1: Building and Combining Native Libs into C API</title><url>http://hotforknowledge.com/2019/07/14/6-rust-the-new-c/</url></story><parent_chain><item><author>ChrisSD</author><text>&amp;gt; So despite the fact that many consider Go to be the main Rust competitor for writing complete programs...&lt;p&gt;Really? That seems odd to me. I guess there&amp;#x27;s some overlap between the two languages but they mostly exists in different spheres.&lt;p&gt;C++ would be the more obvious comparison.</text></item></parent_chain><comment><author>rienbdj</author><text>Indeed. Go competes most obviously with Java.</text></comment>