Guile has achieved much of what it set out to achieve, but there is much remaining to do.
There is still the old problem of bringing existing applications into a more Emacs-like experience. Guile has had some successes in this respect, but still most applications in the GNU system are without Guile integration.
Getting Guile to those applications takes an investment, the “hacktivation energy” needed to wire Guile into a program that only pays off once it is good enough to enable new kinds of behavior. This would be a great way for new hackers to contribute: take an application that you use and that you know well, think of something that it can’t yet do, and figure out a way to integrate Guile and implement that task in Guile.
With time, perhaps this exposure can reverse itself, whereby programs
can run under Guile instead of vice versa, eventually resulting in the
Emacsification of the entire GNU system. Indeed, this is the reason
for the naming of the many Guile modules that live in the ice-9
namespace, a nod to the fictional substance in Kurt Vonnegut’s
novel, Cat’s Cradle, capable of acting as a seed crystal to
crystallize the mass of software.
Implicit to this whole discussion is the idea that dynamic languages are somehow better than languages like C. While languages like C have their place, Guile’s take on this question is that yes, Scheme is more expressive than C, and more fun to write. This realization carries an imperative with it to write as much code in Scheme as possible rather than in other languages.
These days it is possible to write extensible applications almost entirely from high-level languages, through byte-code and native compilation, speed gains in the underlying hardware, and foreign call interfaces in the high-level language. Smalltalk systems are like this, as are Common Lisp-based systems. While there already are a number of pure-Guile applications out there, in the past users have still needed to drop down to C for some tasks: interfacing to system libraries that don’t have prebuilt Guile interfaces, and for some tasks requiring high performance. With the arrival of native code generation via a JIT compiler in Guile 3.0, most of these older applications can now be updated to move more C code to Scheme.
Still, even with an all-Guile application, sometimes you want to provide an opportunity for users to extend your program from a language with a syntax that is closer to C, or to Python. Another interesting idea to consider is compiling e.g. Python to Guile. It’s not that far-fetched of an idea: see for example IronPython or JRuby.
Also, there’s Emacs itself. Guile’s Emacs Lisp support has reached an excellent level of correctness, robustness, and speed. However there is still work to do to finish its integration into Emacs itself. This will give lots of exciting things to Emacs: native threads, a real object system, more sophisticated types, cleaner syntax, and access to all of the Guile extensions.
Finally, so much of the world’s computation is performed in web browsers that it makes sense to ask ourselves what the Guile-on-the-web-client story is. With the advent of WebAssembly, there may finally be a reasonable compilation target that’s present on almost all user-exposed devices. Especially with the upcoming proposals to allow for tail calls, delimited continuations, and GC-managed objects, Scheme might once again have a place in the web browser. Get to it!