Back

@korkeala

> Hello fediverse, here's my #introduction post.

Welcome to #fosstoden!

> I'm a software developer and a long time Linux/#FOSS user. I maintain packages in #Fedora, but recently been also exploring #guix.

I've been exploring #guix too, both as a user and by trying to update the #rakulang packages. It's a fascinating distro, but certainly has a learning curve.

Do you think you'll stick with it?

@codesections @korkeala

Despite being way more fluent in Ruby, Raku has become my goto language for all my command line tools (i write a lot of them). I suspect it's going to be my go-to language for WebDev too but I haven't played with Cro yet. Also, in the background I'm working on my own language and my current plan is to have it transpile to Raku.

So yes, pretty sure I'll stick with it. ;)

@masukomi

Cro is great for web applications, but really a framework for event driven or streaming type things that benefit from pipeline processing: messaging, other network applications and so forth.

You'll love it.

@jns hmm... for those tasks i feel like Elixir / Erlang would probably be a better bet. The Erlang VM is just _so ridiculously good_ at that stuff. It's like, its raison d'être.

As much as i like Raku, Elixir is also a _surprisingly_ nice language, and ... just everything to do with message queues and such is just good.

I don't know how well the Raku VM competes in messaging type tasks but i feel like it's going to be extremely hard for anyone to beat Elixir/Erlang on that front.

@masukomi

Oh yeah, I'm a big fan of RabbitMQ which is a great advert for Erlang in that area, but I didn't really mean creating a full broker in #rakulang (though it's doable and would work well,) rather the kind of service that might consume messages and do things in response.

The point was more that 'Cro' isn't just a framework for an HTTP server, but for anything with a similar processing requirement ( accept raw request, transform it into something useful, route to processor etc.)

@masukomi @jns

For example, #rakulang builds event-driven concurrency into the language at a fairly fundamental level, including by providing syntactic support.

Here's a tiny example, adapted from the cro docs, of a program that shuts itself down whenever it (asynchronously) receives a ^C stop signal:

react whenever signal(SIGINT) {
$program.stop;
exit;
}

The docs have a lot more along those lines: https://docs.raku.org/language/concurrency#Supplies

2/2

@codesections

Exactly, and if you were to take that Supply and pass it to some other component that component doesn't even need to know or care where the "events" being fed on the Supply came from; if you look under the hood of `Cro` it boils down to a pipeline of components that have a Supply as input and a Supply as output (slight over-simplification,) so e.g. a Cro service could have the Supply from `signal` as a source and the eventual "Sink" gets a message it has to deal with.

@korkeala

> I think it [#guix] has a long way to go to be used my primary laptop OS.

I'd agree with that, but I'd note that "laptop" is a pretty important word in that sentence: I'm currently using Guix as my primary *desktop* OS, and it's going pretty well.

That's because running Guix on a (fairly beefy) desktop mitigates two pain points for laptop use: I don't need wifi (sidestepping Guix's driver support), and I can more easily build from source when Guix doesn't have a binary substitute.

@codesections

Yes, thats true. I mainly use laptops, but been thinking also about a new workstation machine. That would be easier to get fully foss supported. But for now I'll keep exploring guix in a foreign distro and virtualized environments.

As a separate note, general linux systems have come quite far, everything on my newest laptop worked automatically: touchscreen, pen, fingerprint reader, wifi, webcam etc.