(1) The name "Guilds":
To me the name guild implies something that is related to one another.
In medieval days, the concept of a guild was mostly used to refer e. g.
to the "guild of mastersmiths", that is people of a certain profession.
They may also agree to not undercut their own profession and profits,
e. g. by not working too cheaply, and such.
There is another concept that I know of guilds, that comes from ecology.
For example, within the bird family, there are different guilds that can
use different resources/niches, depending on the shape of their beak.
Birds with a larger, heavier beak, may often wish to crack hard(er),
stronger nuts, whereas birds with a smaller beak, may specialize on
other plant seeds - this is also a concept of guilds, just from ecology.
As for ruby, I think the name guild does not reveal a lot of intent or
intention. It could mean a lot. If we are to assume that guilds relate to
resources related to threads, and sharing data between threads, then
perhaps this may make some sense, but I think the fundamental problem
with the name itself here, if there is one, is that it does not carry a
whole lot of a "specific description" related to the main function at
hand.
I think this is the primary reason why another name may be better than
guilds. But ... which name, then? Often suggesting another name is not
necessarily better.
Guilds relate to concurrency in ruby, but I think the name guilds per se
is not that good. I hope koichi does not mind this comment, it is just an
opinion, and people have lots of opinions. :)
Guilds are assumed to allow communication with one another using "channels"
(Guild::Channel) - at the least that was proposed at one point. I think
the name "Channel" is semi-ok, but it should be pointed out that we have
similar names, such as "shared mutex/semiphore". So in this case, we would
have to be able to explain what the difference is between channels, mutex
and semaphores... and fibers ... and couroutines... and threads ... and
... well.
In my opinion, no matter which name is chosen, I think it would be best
to stick with the same name for the same or very closely related concepts.
Otherwise it can become quite confusing if we use different terminology.
I also assume that part of the name choice comes from the fact that objects
can be copied and moved between guilds, so this is where the "relatedness"
aspect comes in.
Note that in the URL given above, koichi views Guilds as implementation in
terms of existing Thread and Fibers. So this may also be a reason why the
name was chosen; but even there I am still not sure if the name is great.
Actually, I wonder if fibers, as names, could be removed, and everything
be put into Threads as-is ... but I guess this may not be easy to do at
this point ... ;)
A good resource to read was:
https://olivierlacan.com/posts/concurrency-in-ruby-3-with-guilds/
However, it is a bit complicated, and ideally this could all be much,
much simpler ... I don't think I was the only one to notice that this
is not trivial. The GIL is not trivial either. :\
Part of the problem is with the API, I think such as:
Guild::Channel.
transfer_membership(object)
(I may have made up that API, but how many can easily remember that
API and what it does? And how it should be used, even more so when we
already have Threads, Mutex and Fibers? And that is just one ...)
(2) The name "Isolate" / "Isolates":
Matz suggested this name, and I think it carries a better intent than
guilds, purely from the name part alone. People may have an easier time
associating with what "isolates" do in ruby (if they understand the concept).
I am not sure if "isolates" fully capture the intent behind the name
guilds, though; for example, sharing state? That does not seem to be
fully addressed by isolates, or perhaps this comes simply from another
point of view. With the name "Isolates" we put into focus the idea
that individual "threads" may run in a way that they are completely
unhindered by other threads or events that may be ongoing in these
threads. Because they may be "isolated from one another".
I think one problem with the name "isolates" as such, though, is that it
is a bit clunkier to use overall, at the least for me. "Guilds" as a name
sounds a bit better, even though "isolates" as a name may carry a slightly
more specific intent for its purpose.
(3) The name "Fibers" / "AutoFibers":
Matz mentioned this too during presentations. Perhaps this is used in other
languages.
To me personally, it does not tell me that much. I still don't know what
fibers really are. :D
You could say the same thing about threads, but oddly enough I have adjusted
to threads as a name fairly well. No clue how others think about threads.
(4) The name "Coroutines" / "Rutines":
I tried to coin the latter word to ruby ... Go has goroutines or something
lke that, so ruby may have Rutines. ;) But the name "Rutines" is not
good; goroutines sounds better because of the word "Go". (By the way,
names of programming languages are REALLY strange if you think about it;
"Go" means to walk, right? So that is weird too ... and Rust, that is also
a strange name ... C, C++, D ... perl, ruby, python ... why name
something after an animal. But I digress ... ;))
Coroutines may be used in other programming languages, so perhaps it
fits. I have no real opinion on that, though.
(5) The name "Mutex" / "Semaphore":
I think Mutex came from "mutually exclusive", so perhaps this is where matz
came from, when the name "isolates" was proposed, which seem to make sense
or relate to that concept. At the least you can read this often how difficult
it is to share state between threads.
I have no idea about where the name "semaphore" came from, but I have heard
it before somewhere. Lots of words here.
(6) The name "Threads":
Matz also mentioned this. Personally I like Threads. I used them back in the
days when the pickaxe showed example, to download different URLs at the
"same time", and it was easy to work with.
My personal favourite choice would be to group this all under "Threads",
no matter which name is chosen, simply because I think it makes the most
sense.
But this may not be ideal either, for example, "Threads::Guilds"
would be longer to type than e. g. just "Guilds" (toplevel) or just
"Fibers", rather than "Threads::Fibers".
The reason why I like the name Threads the most is possibly because I have
already adjusted to threads, and have used them in the past, and found them
quite simple.
I have not really used mutexes, fibers etc... and for a reason I am not
completely sure, I think the whole concept here is quite difficult to
understand. Much harder than Threads.
Many parts of ruby are much, much easier to understand (Array, String,
Hash, even Enumerators and Enumerable). I don't know if I am the only
one who has a problem with this here, but if you look at the API
examples from:
https://olivierlacan.com/posts/concurrency-in-ruby-3-with-guilds/
Then I may not be the only one who thinks this is a bit confusing and
complex.
Ideally, no matter what name is chosen, the simpler this could be, the
simpler for ruby users to use, the better. Names are important but I
think no matter which name is ultimately choosen, if it is simple then
people can use it. If the usage is too difficult then only a few may
use it.
Perhaps there could be an experimental API before ruby 3.0, no matter the
name used, so people can experiment with it and see which make the most
sense. And, if wanted, past that point, there could also be a poll (although
I am a bit sceptical of polls in general, people are not always creatures
of logic; but perhaps it may help to see which names are better, and
then pick the best name from e. g. the top three or something, or at the
least narrow it down. The reason why I think a specific API may be important,
on top of it being ideally simple, is because people need to somehow use
code as well, in order to refer to the idea through code - no matter if the
name is Guilds or Isolates or any other name. This is why I think an experimental
API that is encouraged by the core team, may be helpful.).
Anyway, feel free to make any comment related to the name(s) itself. API
usage is very important too, no matter who proposed which name, IMO.
Olivier also proposed this, on the blog entry:
I'd encourage the Ruby core team to release this new feature under an
opt-in experimental flag so that the Ruby community can participate in
testing.
I think this could ideally be done with ruby 2.7 this year; an experimental
flag to try out some APIs or so, to see how people may want to use it. The
"final" name can be finalized in 2020, for example, perhaps a bit before
3.0 is released.
PS: I think when a name has been chosen, or at the latest when ruby 3.0
is released, this issue here can be closed.
It is only meant to give ideas and thoughts behind the name(s) really, so
past that point it is no longer that important.
Updated by 
Updated by 
Updated by