djspiewak

What follows are some of my (very) rough thoughts on what we can and should do with respect to CPS transformation in Scala at the language level. I'll try to start with some motivation behind my thinking, as well as some rambling observations on the nature of the problem space, but don't expect too much coherence here. :-)

The Problem

Async programming is hard.

Okay let's actually be more specific than that. High-performance I/O is hard. Signal multiplexing is a powerful technique for achieving high(er) performance I/O, particularly network I/O, but the tradeoff is that, in order to utilize it, the user-space programming model must allow for suspension and resumption of sequential continuations (often called "fibers" or "coroutines"). Achieving this type of programming model without significant tradeoffs in usability is what is exceptionally hard.

If that wasn't bad enough though, these problems are inextricably conflated with another set of problem spaces which are, themselves, very difficult. In

djspiewak

Understanding Comparative Benchmarks

I'm going to do something that I don't normally do, which is to say I'm going to talk about comparative benchmarks. In general, I try to confine performance discussion to absolute metrics as much as possible, or comparisons to other well-defined neutral reference points. This is precisely why Cats Effect's readme mentions a comparison to a fixed thread pool, rather doing comparisons with other asynchronous runtimes like Akka or ZIO. Comparisons in general devolve very quickly into emotional marketing.

But, just once, today we're going to talk about the emotional marketing. In particular, we're going to look at Cats Effect 3 and ZIO 2. Now, for context, as of this writing ZIO 2 has released their first milestone; they have not released a final 2.0 version. This implies straight off the bat that we're comparing apples to oranges a bit, since Cats Effect 3 has been out and in production for months. However, there has been a post going around which cites various compar

getify

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

SGTGunner

Github to Discord Webhook Tutorial

In this tutorial I'll show you how to create a Github webhook that will post updates from your Github account to a channel in Discord. The steps are simple so follow along!

Create a Webhook in a Discord Channel

First you need to create a webhook in a text channel. We're assuming you have both Manage Channel and Manage Webhooks permissions!

• Go in a channel properties (Alternatively, Server Settings, Webhooks works too)

jvdp

let lessThan = https://prelude.dhall-lang.org/Natural/lessThan

let stepper = ./stepper.dhall

in  stepper.askText
      "What is your name?"
      (   λ(name : Text)
        → stepper.askNatural
            "How old are you?"
            (   λ(age : Natural)

eloots

case class NetworkSwitch(name: String) { thisSwitch =>
  case class Port(nr: Int) {
    val switch = thisSwitch
  }
  def switchPortOn(port: Port): Unit = { println(s"Switching on $port") }
}
 
def switchOffAnyPort(port: NetworkSwitch#Port): Unit =
 println(s"switching off $port on ${port.switch}")

cb372

Category theory jargon cheat sheet

A primer/refresher on the category theory concepts that most commonly crop up in conversations about Scala or FP. (Because it's embarassing when I forget this stuff!)

I'll be assuming Scalaz imports in code samples, and some of the code may be pseudo-Scala.

Functor

A functor is something that supports map.

xero

IRC Reference

Not intended as a guide for newbies, more like a "cheat sheet" for the somewhat experienced IRC user, especially one who wields some power over a channel.

The Basics

• /join #channel
  • Joins the specified channel.
• /part #channel
• Leaves the specified channel.