Tradition demands that I write down some subjective thoughts on how my old friend F# is doing. So here we go again (for the 4th year running).

All I can really say is this: wow, what a year.

Read more...

I’ve been hacking Clojure for many years now, and I’ve been happy to rekindle my love for Emacs. The Clojure/Emacs toolchain has come a long way during this time: swank-clojure, nREPL, nrepl.el, and now Cider. The feature list is ever-growing, and every time you look, there are some new awesome shortcuts that will ‘make your day’.

Read more...

The Clojure Cookbook is part of the O’Reilly cookbook series. I’d describe this format as a ‘curated wiki in print’. The wiki analogy is especially true for this volume since its contents were contributed by some 60 different developers. It’s packed with small, bite-sized recipes for solving common problems in Clojure. This is useful for developers across the entire spectrum from beginner to expert.

The content is organized into 11 chapters, each containing a number of recipes. The chapter layout is clear and serves its purpose when looking for content. The book covers a lot of ground, from working with primitives and basic data structures to dealing with databases, writing web apps, and running Hadoop jobs. Each recipe comes with code and/or REPL examples, so it’s very easy and enlightening to ‘play along’. In contrast to other books with code snippets, the authors have made all recipes self-contained (no other projects/files need to be created and run for the examples to work), which makes it very easy to dive in at any point in the book.

Read more...

All Clojure developers swear by their REPL; it’s one of the most powerful tools in our arsenal. Coming from traditional edit/compile/launch languages, it is also a great productivity boost. The Clojure community takes non-AOT (ahead of time compilation) to the extreme. By default, we ship Clojure source code in our development and production jars and thus leave compilation to the very last minute (when the program launches). This gives us lots of power and flexibility; if you’ve ever navigated into a library in Emacs and fixed a bug, re-evaled the form and carried on working, you know what I’m talking about.

Read more...

You can’t do anything even remotely blocking inside go-blocks. This is because all the core.async go blocks share a single thread pool, with a very limited number of threads (go blocks are supposed to be CPU bound). So if you have hundreds/thousands of go blocks running concurrently, just having a few (a handful really) block – all go blocks will stop! For a more in-depth explanation see this previous post.

Read more...

One particularly annoying difference between core.async and Go is that you can’t wrap function calls with the go macro. This is due to implementation details of core.async, which can only see the body ‘inside’ the macro and not the functions it may call. This is obviously not a problem if the called function doesn’t interact with any channels, but if it does, then you might be in trouble. I’ve touched on this subject in a previous post.

Read more...

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.

Read more...

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?

Read more...

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.

Read more...