A Week with Mozilla's Rust
relistan.com
A Week with Mozilla's Rust
1–10 of 104 posts
Re: A Week with Mozilla's Rust
#2I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals.
However, I want to question the claim:
> Go is also not particularly friendly to interface to external libraries written in C
which doesn't seem to be explained anywhere in the article, and jars with my understanding.
Go does play very well with C; cgo[0] makes this pretty straightforward.
Maybe there are specific things that the author is trying to do that they found difficult in Cgo, but I would say that Go does play fairly nicely with C; that was a design goal.
Here's a simple example of cgo in action: http://golang.org/doc/articles/c_go_cgo.html. As you can see, it's relatively straightforward and easy to use.
Re: A Week with Mozilla's Rust
#3I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…
I think it's more of a comparative statement. Interfacing with C in Rust is very simple, as he details in the article.
Re: A Week with Mozilla's Rust
#4I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…
The keyword here is "friendly", which cgo really isn't.
Re: A Week with Mozilla's Rust
#5I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content
The second sentence:
> I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code.
And we see no explicit demonstrations of the memory management and no demonstrations at all of the concurrency model. It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored before reaching the conclusion. :\
Re: A Week with Mozilla's Rust
#6I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content The second sentence: > I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code. And we see no explicit demonstrations of the memory management a…
A fair critique. I should write more on the subject.
Re: A Week with Mozilla's Rust
#7I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content The second sentence: > I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code. And we see no explicit demonstrations of the memory management a…
It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored...
Or it could be that this post is just the beginning of his journey of learning & blogging about Rust. He did post another one 4 days later, albeit not yet touching on the topics you mention:
http://relistan.com/a-pattern-for-wrapping-c-function-calls-...
Re: A Week with Mozilla's Rust
#8I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…
Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat.
So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to write a piece of your application (even mainly C application) in something that gives you a different kind of expressibility. If there's need for that is another question, specifically, I'd like to see some examples that would really impress me. The examples the article author provided give me only the impression "OK it's weirder syntax but it's not so far from what would have to be written in C anyway, so where's the advantage?"
What I consider missing for "properly" interfacing with C is for Rust to be able to slurp C headers as they are, without the need for additional "translation" files that are presented in the article. At least the headers without the definitions of the functions. But the declarations of the structures and functions and even basic preprocessing were really, really convenient.
Re: A Week with Mozilla's Rust
#9I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…
Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat. So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to…
> The examples the article author provided give me only the impression "OK it's weirder syntax but it's not so far from what would have to be written in C anyway, so where's the advantage?"
Memory safety.
Re: A Week with Mozilla's Rust
#10I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…
What about callbacks to/from C code and function pointers? Embedding Go from C? Building shared libs in Go that can be loaded in C?