
Fibers in Guile Scheme - srean
https://github.com/wingo/fibers/wiki/Manual
======
dmix
Anyone using Guile for their projects? Any feedback on their experience with
it?

I only know Scheme from reading SICP and enjoyed Clojure but hated the
java/JVM part of it. I currently use Erlang for when I need
concurrency/performant backends. But I'm not totally satisfied with it (for
ex: the weak type system and records).

Edit: oh looks two programs I use all the time are written in Guile: GNU Make
and WeeChat
[https://en.wikipedia.org/wiki/GNU_Guile#Programs_using_Guile](https://en.wikipedia.org/wiki/GNU_Guile#Programs_using_Guile)

~~~
mkeeter
I'm using Guile for Ao, a Scheme-based tool for solid modeling:
[https://mattkeeter.com/projects/ao](https://mattkeeter.com/projects/ao)
(previous on HN at
[https://news.ycombinator.com/item?id=12319406](https://news.ycombinator.com/item?id=12319406))

It's been a generally good experience. Scheme is fun, and Guile is a fine
implementation. I'm not experienced enough to be pushing its limits – the only
unusual corner I've explored is the C FFI, which is quite nice.

My only complaint is the consistency of Guile's documentation. It's generally
of high quality, but there are corners that are completely undocumented – I've
had a few cases where I had to dig into the implementation to figure out how
to do something.

------
mpweiher
Yes!

"But if your typey spidey senses are tingling, it’s for good reason: with
promises, your whole program has to be transformed to return promises-for-
values instead of values anywhere it would block."

(Or lifted into a monad).

To me, that's the big issue with a lot of the concurrency/react abstractions
en-vogue now: you are programming indirectly, or more precisely you are
programming in a specific (async) architectural style, but trying to express
this in a call/return architectural style (that includes methods and FP
functions).

Depending on where you are, that often means your actual domain code is hidden
inside a lot of maps() or flatMaps(). The first problem is that your domain
code really should be primary, and your architectural support code as hidden
as possible. The second (but probably not last) problem is that you can easily
have multiple of these "lifts", for example another for error handling with
Maybe. At some point, it just piles up and the actual domain code is
completely swamped.

async/await is sort of the high (or low depending on your POV) point of this
approach of mapping other architectural styles to call/return: you just write
your code as normal call/return, with normal control flow, and just two little
annotations lift everything to a completely different architectural style.

On the one hand, it is truly brilliant, hiding almost all the mechanics of the
more asynchronous architectural style so that you can just keep writing
procedural code as is. On the other hand, maybe it would be better to make it
easier to express those alternate architectural styles directly in code.

This seems like another great move in the direction of the latter.

------
JohnStrange
It's not hard to come up with a working green thread system, I've done that in
a VM I'm developing for fun, but the crucial question is: _Does it distribute
the fibers over native worker threads?_

That's my problem with most scheme implementations, they are great for single-
threaded concurrency but require nasty hacks like Racket's 'places' for using
all available CPU cores. The only fast multicore scheme I'm aware of is Chez,
which has other problems, though.

Does Guile do better than Racket with that respect?

------
flukus
What's the state of other language interpreters for guile? It's one of this
things I always wanted to have a play with until I remember how much I hate
lisp.

~~~
chrisseaton
What do you mean? Other languages running on top of the Guile interpreter? Or
implementations of Guile in other languages. Why would you want to run Guile
if you don't like Lisp?

~~~
mwfunk
To the degree that open source projects have marketing, one of the things that
has historically always come up in Guile marketing is that any language can be
expressed in Guile, therefore if only every application adopted Guile as their
extension language, those apps could have any extension language they wanted.
Do you like C? Then write C and have some hypothetical Guile C front-end run
it for you. Do you like Python? Then write Python and have some hypothetical
Guile Python front-end run it for yet. Etc.

I'm not sure where that came from. Lisp advocates are (perhaps stereotypically
more than in reality) known for citing that since any language can supposedly
be easily expressed in Lisp, why isn't everyone running everything in Lisp and
simply using hypothetical Lisp front ends to their language of choice? This
line of reasoning featured heavily in Internet discussions about Guile in the
'90s. "Guile should be the universal extension language because Guile can be
any language" was a very common perception, at least among many vocal Guile
advocates.

In the last decade or so, I have not heard much along these lines WRT Guile.
But in the '90s the idea that "every language can be a Guile front-end" was
very much front and center in many stupid, pointless flamewars about why
everyone should drop what they're doing and use Guile for everything.

Just to be clear, I like Lisp very very much (and Scheme, and Guile), I'm just
super allergic to hyperbole, tribalism, and wishful thinking.

Ironically, thanks to Web Assembly, etc., Javascript may turn into the
universal backend language that Guile always claimed to be. This is ironic
because I don't think even the staunchest Javascript advocates would argue
that Javascript is a better language than Scheme in any sort of idealistic,
ivory tower sort of totally objective sense.

Javascript isn't everywhere because everyone wants to use it, rather
Javascript is everywhere because Javascript is everywhere, so that's what
everyone uses. Javascript is the programming language equivalent of people who
are famous for being famous. It has many admirable and interesting qualities,
but it was very much a language born out of necessity than design, that lives
on because it was in the right place at the right time. I say that not as a
Javascript hater (I'm not) but rather as an aspiring language historian.

~~~
chriswarbo
> Ironically, thanks to Web Assembly, etc., Javascript may turn into the
> universal backend language that Guile always claimed to be.

Would WebAssembly boost JavaScript's value as a "backend language" (I assume
you mean a compiler target, rather than a server-side language?)?

I thought the point of WebAssembly was to _stop_ people compiling to JS, by
offering an alternative standard language/bytecode which is specifically
designed to be a compiler target, rather than a human readable/writable
language.

------
dkarapetyan
What is the point of exposing a scheduler? Seems like that's another
implementation detail that should not be exposed. The user should just
instantiate some fibers and go.

~~~
srean
Scheduling algorithms are dime a dozen and the default one provided by a
runtime might not be suitable for a particular application. A user space
scheduler would let you have finer control when you need it. You may have
codepaths that are latency sensitive and those that are throughput sensitive.

~~~
dkarapetyan
That's not what this scheduler does. It simply bundles up some fibers. You
don't have control over the actual scheduling. Relevant section of
documentation

 _When a fiber would block, it suspends to the scheduler from the current
thread. The scheduler will arrange to re-start the fiber when the port or
channel becomes readable or writable, as appropriate. For ports, the scheduler
adds the file descriptor associated with the port to an epoll set. In either
case, the scheduler remembers which fibers are waiting and for what, so that
the user can inspect the state of their system.

If no scheduler has been installed in the current thread, the fiber will...
well, we don’t know yet! Either it blocks its thread, or it aborts. We don’t
know._

In fact it is pretty clear there is zero control user has over any scheduling
activity other than suspending and resuming. It is all driven by polling
events internal to the implementation.

~~~
srean
I was responding to your larger question. User space schedulers would be quite
cool, don't know of a language that offers anything over and above a priority
queue or timers.

