Very bad advice - off putting - in 10.2: A little Rust with your C

[worikgh]

This is a minor point, and can be fixed by removing the offending sentence. But is is an offensive (in a technical sense) sentence.

I am coming to this chapter via a web search for calling Rust from C

It says this:

Apart from cargo and meson, most build systems don't have native Rust support. So you're most likely best off just using cargo for compiling your crate and any dependencies.

Coming from the perspective of 90k lines of C code, a build system that has been sweated over, saying "you're most likely best off just using cargo" is saying "get lost, we do not care about you".

Removing that sentence - especially right at the start - would help.

Integrating with Make is a bare minimum for calling Rust from C

I am in a situation of settling onto a new job with a project that is over 90k lines of C, so not huge, but significant. I would like to point my new boss at resources that help explain why new capabilities could be added in Rust - a possibility.

I cannot point them here. If I were my boss (thirty years programming Linux modules in C) and I saw that, I would stop reading.

All that said I must finish with: Well done! Keep up the good work!

[adamgreig]

Hi, thanks for the report. I worry that you've misunderstood the intent behind this sentence as I don't think it's offensive. Perhaps it can be clarified. The sentence intends to say "you should use Cargo to build your Rust code, because it is infeasible to use Make directly to compile Rust", but it does not mean "you should throw away your Makefiles and use Cargo to build your whole project", because Cargo does not build C projects.

The idea is that you use Cargo to compile your Rust crate, typically to a static library (e.g. a .a or .lib file), and then you link that library in your C build process, just as you would any other pre-compiled library. You might additionally want to have your Makefile run Cargo to check the static library is rebuilt when appropriate (probably by always calling cargo, rather than having to tell Make about all the Rust source that the library depends on).

Integrating with Make is a bare minimum for calling Rust from C

Most C projects probably aren't using Make, so I don't think this is true. The important thing is how to build a static library using Cargo which you can then link in to your normal C or C++ build process. Optionally, having the C build process call cargo for you could be convenient too.

[worikgh]

Yes. I was coming to this with the mindset of a C programmer, which I am, looking for advice for/reasons to, use Rust.

Dropping into the middle of the book like that I miss the wider context, and I see the statement about "build using Cargo" as "Go away". Unfair, I know. Sorry.

I see the next paragraph talks about "build your crate as usual..." Again, where I am coming from that makes no sense. But I am out of context.

I think this is not what I am looking for. If you want this page to be welcoming to a C programmer, it needs a complete rewrite, but I am unsure if that is your audience.

I love and hate C. For a long time there was no alternative. It was the C-way or something really really bad.

Times have changed in the last five years, and I want to change with them. There is no hope of rewriting a lot of software (I have 95k lines of C in my immediate attention) but for adding units to our system, I think (?) Rust is the way to go.

SO I show up, searching the Interweb for "Calling Rust from C" and I end up on your book, on this page.

That is the background to me raising this issue.

I have no idea what you want to do about that, if anything.

I love your work, you are doing a great job, it is not exactly what I need!

cheers

[akauppi]

I have no idea what you want to do about that, if anything.

@worikgh I think you made your point, and got a reply from the book authors. I visited this page today (though via reading through the whole book) and I wouldn’t see anything worth changing in it.

I can see you having two choices now:

1. Close the issue since you got the message through
2. Be more specific how you’d like the text to be changed. ”I have no idea what you want to do […]” is not the kind of language that I usually see in GitHub Issues. Try to be friendly and gentle. We are here mostly on our own time, and want to enjoy the neighbourhood. :)