Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[discussion] changing the project name / acronym #208

Open
japaric opened this issue Jun 23, 2019 · 18 comments

Comments

Projects
None yet
@japaric
Copy link
Owner

commented Jun 23, 2019

Over the course of the two years I have been working on this project I have received several comments expressing displeasure over the acronym chosen for the project (RTFM). These comments have been along the lines of:

  • "The acronym of the project is terrible for searching it on the web because it coincides with the acronym for 'Read The Fucking Manual'."

  • "Some corporate environments may frown upon the acronym."

  • Some people have pointed out the disconnect (contradiction?) between the acronym and Rust's goal of being a welcoming, inclusive and empowering programming language / community.

Of course, I have also heard some people say that they find the acronym funny. However, those comments have been few in comparison to the first kind of comments. As the project has been growing in popularity the number of comments of disapproval I get has increased as well; I think the upcoming minor release is a good time to address this issue.

This thread is to discuss the possibility changing the name of the project or at the very least changing the acronym (e.g. to RTmass). I would greatly appreciate people sharing their thoughts on why they find that the current acronym is no good and / or how the project would benefit from changing its name / acronym. Name and acronym suggestions are welcome as well.

A name / acronym change would entail renaming the crate for the upcoming minor release (v0.5.0) and using this new name for the GitHub organization proposed in RFC #203.


I would gladly welcome a name that better conveys that the framework is for building any kind of multitasking / event-driven embedded application. I have often heard phrases like "RTFM is for building real-time applications" implying that one would only use RTFM for coding real time applications; this is clearly not true as evidenced by the many non-real-time projects built with RTFM.

Finally, I must stress that renaming the project or changing its acronym would not change or invalidate its history. This project, regardless of its name, will continue to be related to the Real Time for the Masses language and all the research associated to it -- this connection is stated in the project's README and book and will remain there.

@japaric japaric added the RFC label Jun 23, 2019

@japaric japaric added this to the v0.5.0 milestone Jun 23, 2019

@perlindgren

This comment has been minimized.

Copy link
Collaborator

commented Jun 23, 2019

Hi Folks

As the originator of the project, I have mixed feelings about changing the name. I could think of Low OVerhead Embedded, as an alternative. That would allow us to build systems with LOVE!!!!

@little-arhat

This comment has been minimized.

Copy link

commented Jun 24, 2019

The only issue I have with current name is that it's very similar to cortex-m-rt so I often end up in wrong directory or page, thanks to autocomplete. I guess cortex-m could be dropped as in theory this library is not limited to cortex-m, but then name would indeed sound a bit weird.

As an alternative I suggest something like mrt — Metal Real Time — following mio. (mrt can also be expandend as mu or micro).

@placrosse

This comment has been minimized.

Copy link

commented Jun 25, 2019

While I personally have no problem with rtfm, and think it would be very poor professional judgement for someone to not use it solely because of the name, @perlindgren 's suggestion would have a powerful positive effect.

Unfortunately, there's already a crate:

https://crates.io/crates/love

Perhaps love-rt would work (adding real-time back in). The ability to handle real time, when necessary, is a key feature which should not be hidden

@placrosse

This comment has been minimized.

Copy link

commented Jun 25, 2019

And to @japaric , I suspect many people found it somewhat amusing, but did not feel compelled to spend your time by informing you of their feelings.

@ssokolow

This comment has been minimized.

Copy link

commented Jun 25, 2019

My main issue with it is the searchability. LOVE would have had the same problem whenever someone didn't bother to write the full love-rt so I'd prefer something where, if it uses a common word, it's formatted without a dash that might encourage people to abbreviate it. (eg. camelcase instead of anything resembling snake case.)

@korken89

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2019

I faced the same issue when working on the C++ version of RTFM, and in the end I asked the embedded C++ community for help.
After a lot of discussions we chose crect (pronounced correct) for Compile-time Reactive Scheduler or correct by design.
Not the best of names, but it worked really well for the C++ community.

When it comes to here, I agree that the RTFM names give off a non-professional tone and a replacement should be found.
However what the replacement it, I am not sure.

@austinglaser

This comment has been minimized.

Copy link

commented Jun 26, 2019

I think one of boats' blog posts from a while back is relevant here. In particular:

names that are just made up out of nowhere are better than names that are constructed from internal jargon of the project domain, unless you expect all users to already be familiar with that jargon and that domain ... if you intend to introduce users to the complexities of this subject through your project, its much better to come up with a random, flashy name for it that is at best vaguely related to the subject of it.

I think it's worth putting on the table something that isn't an acronym or a directly embedded-related term, or even a name to which we can attach a thin metaphor (I spent some time thinking of "lightweight metals," but all good names seemed to be taken).

I'll probably dump a couple suggestions I think will fit this mold in a follow-up comment.

@austinglaser

This comment has been minimized.

Copy link

commented Jun 26, 2019

Some output of my brain's psuedo-random name generator (all checked to be free on crates.io):

  • bauble
  • sunjammer
  • juggler (cause it juggles tasks/resources)
  • implant (a synonym for embed)
  • unos ("UNOS is Not an OS")
@ssokolow

This comment has been minimized.

Copy link

commented Jun 26, 2019

I'm rather partial to portmanteaus and two-word phrases because they're still easy to search, they're easy to make pronounceable, and they lend themselves well to providing a good mnemonic hook via intrinsic meaning so that, if you wandered past but didn't need it, and some of the design elements caught your eye, you're likely to also remember what it was called when you do need it.

The TaskJuggler time-management software is a good example of that.

@dbrgn

This comment has been minimized.

Copy link

commented Jun 26, 2019

Incredible but true: The crate fearless doesn't exist yet. Fearless embedded real-time systems with Rust.

@TeXitoi

This comment has been minimized.

Copy link
Collaborator

commented Jun 26, 2019

Fearless interruptions!

@TeXitoi

This comment has been minimized.

Copy link
Collaborator

commented Jun 26, 2019

I personally like the RTFM name because it's easy to remember. I can understand that we want to choose to avoid the impolite reference.

@TeXitoi

This comment has been minimized.

Copy link
Collaborator

commented Jun 26, 2019

To take the example of the tokio project, I searched for cities in which we can write IRQ inside. I've found:

@ssokolow

This comment has been minimized.

Copy link

commented Jun 26, 2019

It never even occurred to me that tokio had anything to do with the city.

Since I generally stick to Django's mature ecosystem for network-related needs, and don't have much need for async outside that domain, aside from wanting generators so I can replicate design patterns I use in Python, I always assumed it was a portmanteau of some variation on the word "token" and I/O.

@placrosse

This comment has been minimized.

Copy link

commented Jun 26, 2019

What if RTFM just used the entire acronym and became RTFTM ?

It no longer matches the well-known "problem abbreviation" while sticking to @perlindgren 's full original name.

It is now unique, and search-engine friendly.

@burjui

This comment has been minimized.

Copy link

commented Jun 26, 2019

@placrosse RTFTM doesn't sound nearly as good.
Anyway, personally, I find the reason for the renaming not convincing.

Firstly, "rust rtfm" works fine both in Google and DuckDuckGo. We, software engineers, are generally smart enough to add "rust" to the query when searching for a Rust project.

Secondly, there are always people too soft to take a joke, even if the joke is not designed to irritate anyone. This is a perfect example: obviously, the author of the project does not dislike the users to the point of sending them to read the documentation in such a rude form. I feel silly explaining it. Everyone understands that this is just a reference, but some people want attention, so they become offended by random stuff to get it.

Thirdly, renaming the project involves renaming it in documentation, source files, crate names and whatnot. To me it seems a big waste of time for no gain whatsoever.

All this talk about being welcoming and inclusive is mostly muddying the water, to be honest. You get code for free, it comes with documentation and examples, authors respond to comments and fix bugs. For me, it's quite welcoming. But okay, fine. Just change "masses" to "people" (or "ponies"), and RTFM will become RTFP. No more "confusion" and bad feelings.

@placrosse

This comment has been minimized.

Copy link

commented Jun 26, 2019

@burjui I agree with your points, and find the name fine as it is. There are plenty of acronyms with multiple meanings. I was simply offering a suggestion which would be a very minimal change, if one has to occur. Your suggestion is fine, but, like mine, also has all the negatives of renaming crates, changing code, etc. for something which may not end up as a gain at all.

@rmsthebest

This comment has been minimized.

Copy link

commented Jun 27, 2019

I think the acronym is somewhat funny, but I also dislike acronyms, even more so if there is one acronym with multiple meanings.
I'd be in favour of a name that is not an acronym, there are enough of them in the world already.
Perjorge[ic] is your two names put together and kinda sounds like period or periodic which is kind of related to real time systems. You can still have real time for the masses as a subtitle.

I can't think of a reason Perjorge would be offensive, it is unique, and has a little bit of humor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.