joepie91

No, your cryptocurrency cannot work

Whenever the topic of Bitcoin's energy usage comes up, there's always a flood of hastily-constructed comments by people claiming that their favourite cryptocurrency isn't like Bitcoin, that their favourite cryptocurrency is energy-efficient and scalable and whatnot.

They're wrong, and are quite possibly trying to scam you. Let's look at why.

What is a cryptocurrency anyway?

There are plenty of intricate and complex articles trying to convince you that cryptocurrencies are the future. They usually heavily use jargon and vague terms, make vague promises, and generally give you a sense that there must be something there, but you always come away from them more confused than you were before.

djspiewak

A Study in Multi-Point Deadlocks

Deadlocks are extremely difficult to reason about sometimes. We are used to thinking about them in terms of contention over shared resources, with the pair of exclusive locks being a good and relatively canonical example of this phenomenon. However, sometimes you can find yourself in deadlock scenarios which are caused not so much by an improper sequencing of exclusivity, but rather by insufficient buffer capacity!

These kinds of scenarios are a lot rarer and much more difficult to diagnose and describe, which is why I found this particular puzzle so incredibly fascinating. The following is a screenshot from Cities Skylines (I added textual markers and arrows to make things easier to follow). All vehicles pictured are stationary and unable to move, indefinitely:

Do you see the deadlock? It took me a bit to understand it, but this situation can and does arise in software resource contention where it is dramatically harder to conc

nafg

import java.sql.Types

import scala.annotation.tailrec
import scala.concurrent.Await
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.duration.Duration
import scala.meta._

import slick.dbio.DBIO
import slick.jdbc.meta.{MColumn, MQName, MTable}

Daenyth

Concurrent resource caching for cats

Motivation

cats-effect Resource is extremely handy for managing the lifecycle of stateful resources, for example database or queue connections. It gives a main interface of:

trait Resource[F[_], A] {
  /** - Acquire resource
    * - Run f
 * - guarantee that if acquire ran, release will run, even if `use` is cancelled or `f` fails

Daenyth

package teikametrics
import java.nio.charset.{Charset, StandardCharsets}

import akka.util.ByteString
import fs2.{Chunk, Pipe, RaiseThrowable, Stream}
import teikametrics.ByteEncoding._

/** Streamed bytes claiming to be encoded under `BE`
  *
  * @param chunkSize A chunk size to use for streaming operations, in order to use a consistent value and minimize array copying

Daenyth

package teikametrics

import scala.collection.SortedMap

/**
  * Immutable implementation of an LRU cache.
  *
  * @author Twitter
  *
  *  Copy pasted from the version previously in twitter-util v19.1.0 at

Daenyth

// Based on https://github.com/http4s/contrib/blob/master/aws/src/main/scala/org/http4s/contrib/aws/AwsSigner.scala

import java.util.Date

import cats.data.Kleisli
import cats.effect.{Effect, Sync}
import cats.implicits._
import fs2.Stream
import org.http4s.client.Client
import org.http4s.{Header, Request}

gvolpe

Dependency Injection in Functional Programming

There exist several DI frameworks / libraries in the Scala ecosystem. But the more functional code you write the more you'll realize there's no need to use any of them.

A few of the most claimed benefits are the following:

• Dependency Injection.
• Life cycle management.
• Dependency graph rewriting.

gvolpe

Shared State in pure Functional Programming

Newcomers to Functional Programming are often very confused about the proper way to share state without breaking purity and end up having a mix of pure and impure code that defeats the purpose of having pure FP code in the first place.

Reason why I decided to write up a beginner friendly guide :)

Use Case

We have a program that runs three computations at the same time and updates the internal state to keep track of the

djspiewak

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea