It's interesting to look back on things like this with the lens of history.
Tcl has arguably been as successful as Guile, but neither has exhibited longevity; both have been in decline for many years. Emacs has switched to Guile (maybe?), and Guile has gotten a major overhaul this decade (lots of smart people with a lot of experience like Scheme, so not a big surprise), but the other "high profile" projects using it are really not very high profile at all (Guix, Gnucash, GDB, all pretty niche projects with limited user bases).
Tcl got a lot of effort put into it by pretty big companies for a while, and it's actually a pretty good language, IMHO. It has significant limits, sure, but so did Guile for a long time. And real software has been built with both.
It almost feels like a personal vendetta rather than any significant technical reason, even though it's written as though, "Obviously, we should choose the technically superior extension language that, by the way, does not yet exist in a fully usable form."
Was there a licensing beef with Tcl, as well, or is it purely that RMS just really wanted everything to use Scheme?
I am not aware of any major application using Guile - even Emacs has not switched to it. Tcl might not be in the news every day, but it is very widely used. Tcl/Tk is still a very efficient way to make a cross-platform GUI application, and it is used for scripting in applications a lot. While the syntax of Tcl can be considered "funny", still most people seem to prefer it to Lisp. (Disclaimer: I am a professional Lisp programmer)
Yeah, I think Guile has basically been a failure on that front. I didn't want to be harsh, as it seems to be a well-maintained project by smart people...but, as extension languages go, it sure isn't doing much extending in the real world.
Sadly it is probably your only choice if you want a multithreaded extension language playing nice with a multithreaded main application. For all other extension languages I know, this is a huge hack that never works well in practice.
How is Lua so popular in gaming if it can't do this? (I don't know much about Lua except it has a pretty solid niche in some industries, and gaming is one of them.)
I was reading the docs for Guile in this regard (https://www.gnu.org/software/guile/manual/html_node/Multi_00...), and even with language support, it seems like you still need to jump through some hoops to do the Right Thing in a multi-threaded program.
Seems like in any case, if I were using any of them in a threaded program, I'd want to isolate them from threads as much as possible. One of these days, in my Copious Free Time(tm), I'll take the time to actually look at an implementation to see how people have handled this problem. I wonder if any reasonably complete game engines use Guile, for comparison...
The only hoops I can see there is the regular caveats that apply to all parallel programming (don't introduce deadlocks, be careful: other threads might mutate the data you are currently using).
That applies only if you are executing guile code in parallel in the same interpreter and environment (or asynchronously accessing interpreter data) which is impossible in insert_other_embeddable_language_here.
You don't have to use embedded guile like that.
From my experience: if you want to embed a language and only need it in a single thread, it is just as easy to use lua. If you want several interpreters in isolated threads without any communication Lua is easily the simplest solution.
But if you need communication between multiple embedded language threads or interpreters you are better of with guile or TCL depending on what threading model you prefer.
Well Tcl expects you to use an interpreter for each thread and pass messages between them, which is fairly easy. In Tcl 8.6 you also have the option to use multiple coroutines within one interpreter.
This avoids the Global Interpreter Lock problem that plagues Python. How does Guile handle that?
Guile doesn't. You'd use one interpreter and isolate whatever you need to isolate in it's own module and if you need things in parallel, you can just use pthreads (guile has proper threading support and no GIL).
If you don't cross the C barrier again from your scheme code you can even use something like guile-fibers for Concurrent ML-like parallelism.
Tcl has arguably been as successful as Guile, but neither has exhibited longevity; both have been in decline for many years. Emacs has switched to Guile (maybe?), and Guile has gotten a major overhaul this decade (lots of smart people with a lot of experience like Scheme, so not a big surprise), but the other "high profile" projects using it are really not very high profile at all (Guix, Gnucash, GDB, all pretty niche projects with limited user bases).
Tcl got a lot of effort put into it by pretty big companies for a while, and it's actually a pretty good language, IMHO. It has significant limits, sure, but so did Guile for a long time. And real software has been built with both.
It almost feels like a personal vendetta rather than any significant technical reason, even though it's written as though, "Obviously, we should choose the technically superior extension language that, by the way, does not yet exist in a fully usable form."
Was there a licensing beef with Tcl, as well, or is it purely that RMS just really wanted everything to use Scheme?