Blog contribution for TWiR

Sorry if this is off topic here but I do not quite know where to send it. There are some calls for blogs but they are two years out of date.

You had been kind enough to publish a quote by me in TWiR previously.

This time I am offering my blog on the Rust experience. It is an outsider's view with some critical elements, so if you don't like it, feel free to ignore it.

Otherwise you may like to publish it in the next TWiR.

Here it is: To Rust or not to Rust?


Nice article!

If you haven't already, you may want to post the link to the r/programming and r/rust subreddits. These platforms tend to be quite amenable to this sort of article.

FYI, usually if you find/write an article that would be worth publishing in TWiR you'll create a pull request against the TWiR repo adding it to the latest draft (example). From what I've seen it tends to be the author's responsibility to submit their article, although I the maintainers will sometimes add an article if they see it come up in their feed or someone forwards it to them via social media.

I'm not 100% sure whether the article will be a good fit for TWiR. This comment mentions they tend to avoid opinionated articles (e.g. "Why I love/hate Rust") or introductory articles/comparisons where it's unlikely the article will present new information to readers, and your article may fall in the latter category.

That said, I'm in no way affiliated with TWiR and just a random dude on the internet who's made a couple submissions in the past. I'd recommend creating a PR anyway and seeing how it goes.

Keep up the good work :slight_smile:

1 Like

Thanks. I really liked it. You might consider changing its category to "announcements", which nauplii (new cRustaceans) sometimes sort on, but the "community" category fits as well.

I noticed one statement in the blog that I believe to be in error:

My understanding is that it requires unique borrowing. Ownership provides the ability to drop the item or to transfer ownership, but even the owner cannot do that when an &mut (unique borrow) is outstanding.

1 Like

I like it. Nice job. One correction, though. You have the "!" in the wrong place when naming macros in the body of the blog. For example, "!panic" should be "panic!"

1 Like

Many thanks for the useful feedback and corrections. I will make those corrections and try to submit the pull request.

In my defence, I believe that there is one piece of original/new information contained in my article. Specifically, my suggestion to use a 'HolE CasE' to distinguish (for human readers) immutable variables from mutable ones within the code.

I find your 'HolE CasE' extremely difficult to read, and I'm a literate native American-English reader with a long career as a part-time professional proofreader. This proposal gets a big down-vote from me.

Also note that this proposal won't work at all in the majority of world languages, which don't have both upper and lower case.

1 Like

My only gripe with this is that when you declare a lot of variables, the compiler remembers perfectly well which ones are mutable but I often don’t.

I agree with @TomP here, your code is trying to tell you that the function has too many moving parts and is doing too much. Working around it by making up a naming convention isn't the right solution, you should instead break the function up according to the different steps or responsibilities.

I get what you are saying but that is not quite what I had in mind. There are situations, for instance when passing a mutable var to some function as immutable, where you will want a similar name for it but it would be useful to somehow mark its changed status, imho.

Yes, I agree that it is not very pretty and that the Chinese might have difficulty with it but then the same arguments already apply to CONSTANTS. Maybe just simply capitalising the first two letters would be easier on the eyes.

I improved the text a little, using your suggestions, thank you. I am pleased to say that it has now gone into the latest This Week in Rust. I look forward to contributing more in the future.


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.