Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Parent Full thread

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.)

Lua fully supports scripting in multiple threads i.e. multiple threads can each have a Lua context that runs scripts independent of the other threads.

Within a context you can run multiple coroutines but these are all run on the same thread and are cooperative.

It doesn't natively support sharing across multiple OS threads.

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.

Lua extensions use coroutines instead of preemptive multithreading which is usually good enough.

Tcl has also fully supported this use case since about 1998.

Not really. TCL didn't allow you to use one interpreter over several threads four years ago, and iirc TCL still isn't thread safe in that regard.

Guile does this with bravura.

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.

Some major applications using Guile include: Lilypond, Gnucash, GDB, Guix.

Those are large programs, and well done in my experience with the ones I've used, but not particularly mainstream (OK, GDB is widely used).

Reply on news.ycombinator.com