Dealing with exceptions in go blocks/threads is different from normal Clojure core. This gotcha is very common when moving your code into core.async go blocks – all your exceptions are gone! Since the body of a go block is run on a thread pool, there’s not much we can do with an exception, thus core.async will just eat them and close the channel. That’s what happened in the second snippet in this post. The nil result occurs because the channel we read from is closed.

For the third year running, here’s my annual (and extremely subjective) review of the state of the F# language, its community and other loosely connected things. How would I sum up the noises coming from F# the last year? Pretty darn awesome. A lot of what’s been happening was on my wish-list outlined in last year’s post. What are the highlights?

tl;dr I present a new Simulant example project, testing a simple web API.

All programs are simulation tested, at least once. — Stu Halloway

Simulation testing is an interesting field that has a lot going for it. While most website/API developers write many tests at the unit level (an old Rails habit), testing and understanding a whole system is often not done. Most systems we build nowadays consist of many (mega/micro) services/databases glued together. Getting a deeper understanding of how a system actually works and being able to simulate production-like scenarios is very useful.

Stuart Sierra has done a great job with clojure.tools.namespace and the reloaded Leiningen template. If you haven’t heard about this before, please have a look at c.t.n’s readme and watch this presentation.

I have retrofitted this pattern into two rather large Clojure projects (20,000 and 5,000 lines) with several modules, and here are some of my findings.

Removing global state

The first step is to find all resources that need to be “lifecycled.” Typical examples are Jetty servers, database/message bus clients, etc. It’s common that these resources are in a (defonce server (atom ...)) form. I tend to grep for defonce and atom to find these items.

I’ve been using various Go examples and tutorials to take a deeper look into core.async. The CSP pattern is very interesting and powerful; it’s a good move for Clojure to “throw in” with Go and push this style of programming.

core.async works at the s-expression level, where some other JVM solutions (Kilim, Pulsar) do the same at the byte-code level. The main benefit of doing these transforms at the s-expression level is that they are applicable to ClojureScript, where CSP can be a very neat way out of callback hell. David has written about this.

Some time ago I wrote about Asynchronous workflows in Clojure. With the recent release and excitement of core.async, I thought it a good time to revisit that post.

While there are already some good examples and comparison-with-go posts out there, I’d like to focus on an area often misunderstood, namely async frameworks and blocking APIs (most commonly blocking IO). It’s important to understand the implications of blocking IO and its effects on ‘async code’, in this case core.async.

A simple SQL scenario;

I am proud to announce a new Scala project called “Frins.”

Frins is a practical unit-of-measure calculator DSL for Scala.

Key features:

• Tracks units of measure through all calculations, allowing you to mix units of measure transparently
• Comes with a huge database of units and conversion factors
• Inspired by the Frink project

Full source code is available on GitHub.

To whet your appetite, head straight over to the example calculations.

How Frins Came About

About a year ago, I created Frinj. With Frinj, I tried to marry some of the joys of one of my favorite programming languages (Frink) with the Clojure REPL. I was quite pleased with the results, and the response was encouraging.

Taken from edn-scala

In this post, I present some of my experiences writing a Scheme interpreter in Scala (as an external DSL) and compare it with my recent similar experiences in Clojure and F#.

Overall, the Scala solution is very similar to the F# one. Not very surprising, since the problem lends itself well to case classes / discriminated union types and pattern matching. One difference is more type declarations in Scala, due to the lack of Hindley-Milner type inference. Scala uses a “flow-based” type inferrer, which is less powerful than ML but apparently works better for OO subclasses, etc. I will look into this in a future blog post.