<p>I'm building an app and the backend preferably would interface with Rust. I could just do that with Rails and FFI but I would much rather the benefit of a statically typed language. Is there a way to do this? I can't seem to find any good documentation online.</p>
<p>Thank you!</p>
<p>Edit: I believe I found what I was looking for. <a href="https://github.com/medimatrix/rust-plus-golang/" rel="nofollow">This project</a> is a little tutorial for building rust libraries and running them with Go. But I'll leave this up here in case anyone needs it in the future.</p>
<p>Go is great.</p>
<hr/>**评论：**<br/><br/>epiris: <pre><p>You could use cgo if you want to call the function from your Go application. If the rust system is large enough maybe considering separating it into its own service and creating an official contract between the two using grpc. Typically I think it's good to stay away from cgo unless you end up hitting a road block that leaves no other options.</p></pre>ethyn_bunt: <pre><p>Thanks for the advice! Are there any real downsides to cgo?</p></pre>epiris: <pre><p>Yes I think working with cgo is just nuanced and unpleasant in general, but I also don't like working with c or c++ anymore so your mileage may vary. A more concrete reason to avoid it anything beyond hello world with basic types you end up importing unsafe to work outside the type system.</p></pre>connor4312: <pre><ul>
<li>An overhead to calls across the cgo<-> go boundary, a few hundred <del>ms</del> <strong>ns</strong></li>
<li>Cgo calls establish full C threads and are significantly more expensive than lightweight Go calls</li>
<li>It makes compiling and consuming your application much more difficult </li>
</ul>
<p>Dave Cheney goes into much more detail in this great article: <a href="https://dave.cheney.net/2016/01/18/cgo-is-not-go" rel="nofollow">https://dave.cheney.net/2016/01/18/cgo-is-not-go</a></p></pre>dlsniper: <pre><blockquote>
<p>An overhead to calls across the cgo<-> go boundary, a few hundred ms</p>
</blockquote>
<p>False, it is massively improved since 1.8 and never was hundreds of ms of begin with.</p>
<blockquote>
<p>Cgo calls establish full C threads and are significantly more expensive than lightweight Go calls</p>
</blockquote>
<p>Depending on your needs, this might not be a problem at all. </p>
<blockquote>
<p>It makes compiling and consuming your application much more difficult</p>
</blockquote>
<p>False, the compilation remains the same and if you layout the packages in a nice way, you pay the C compilation penalty only when you actually have changes in the C files, much like the Go compiler does for the .go files.</p></pre>connor4312: <pre><p>Whoa, sorry, didn't mean to personally offend or anything! Happy to answer questions and discuss to clarify what I said.</p>
<blockquote>
<p>False, it is massively improved since 1.8 and never was hundreds of ms of begin with.</p>
</blockquote>
<p>I made a super trivial cgo program <a href="https://play.golang.org/p/3fUwNqaVGS" rel="nofollow">here</a> and benchmarked it on 1.8.1</p>
<pre><code>➜ cgo_test go test -bench=. ./
BenchmarkCgoCall 20000000 96.4 ns/op
PASS
ok _/home/connor/cgo_test 2.030s
</code></pre>
<p>The hundred<strong>s</strong> might have been a bit high, but bear in mind that for any non-trivial function you're probably going to be passing in data that needs to be allocated and copied over to the C heap. Even if it's just a filename for C to do further processing on. "Real world" overheads are usually in the hundreds of nanoseconds. Just passing in a string to the function, for instance, bumps it up to 372 ns/op.</p>
<p><strong>edit</strong>: realize I wrote ms instead of ns in my comment above, I meant ns. My bad!</p>
<blockquote>
<p>Depending on your needs, this might not be a problem at all.</p>
</blockquote>
<p>Totally agree!</p>
<blockquote>
<p>False, the compilation remains the same and if you layout the packages in a nice way</p>
</blockquote>
<p>Hm, that's interesting. For me, compilation of that sample program I linked above failed on Windows with Cygwin -- not a particularly exotic environment.</p>
<pre><code>{ cgo-test } » go test -bench=. ./
gcc: error: CreateProcess: No such file or directory
FAIL _/C_/Users/Connor/Downloads/cgo-test [build failed]
</code></pre>
<p>Ended up running it on a Linux VM. Indeed, it looks like cgo in cygwin has <a href="https://www.google.com/search?q=cygwin+cgo" rel="nofollow">no shortage of issues</a> and, at least four years ago, <a href="https://github.com/golang/go/issues/3624#issuecomment-66067201" rel="nofollow">no support</a>. Considering I develop normal Go code perfectly fine in cygwin, I would say this is making compilation more difficult.</p></pre>dlsniper: <pre><blockquote>
<p>Whoa, sorry, didn't mean to personally offend or anything!</p>
</blockquote>
<p>How did you even got that?</p></pre>definitelynotpietro: <pre><p>probably your aggressive use of the word FALSE</p></pre>dlsniper: <pre><p>How do you say: this thing is false without using false? If I use "incorrect" instead would that make any difference? The statement is still false and I still have no control on how you choose to read the sentence. And for the record, I used "False", not "FALSE".</p></pre>definitelynotpietro: <pre><p>Dunno. When I see the world false, I read it in Dwight's voice and it bothers me. Reading "incorrect" seems pretty low-impact. Seems like I'm not alone</p>
<p>also, only angry nerds actually use the word false in conversation, so there's that.</p>
<p>edit: you can also totally correct someone without prefacing the correction with the words false or incorrect. they're implied by the correction, no? wtf am I even having this conversation just stop being an angry nerd</p></pre>dlsniper: <pre><blockquote>
<p>wtf am I even having this conversation just stop being an angry nerd</p>
</blockquote>
<p>I'm very relaxed, it seems you are the one thinking I'm not (for whatever reason). Maybe try not to assume this much about plain text next time? It really is a terrible medium to convey emotions :)</p></pre>
