• how do I build a binary, including on CI (build server pipelines)?
• how do I write and run tests?
• how to mock during tests?
• how to debug code with a line-by-line debugger?
• how to describe/document a project for publication?
• where to read the hyperspec like it’s not 1992 anymore?
• which tools are used for all that?

Even though most answers can be found, at least on a surface level, either on the wonderful Common Lisp Cookbook or on the Common Lisp Docs website, they normally don’t go very deep on these topics and ends up leaving me scouring the Internet for answers.

The Cookbook is so good that I keep a local PDF open all the time while doing anything in Common Lisp. The authors were generous enough to publish it as a free PDF, and you have the option to pay for the EPUB version. If you’re learning Common Lisp, the Common Lisp Docs linked above has an extremely good tutorial, highly recommended!

For that reason, I decided to write a few notes on how I did all these things on my latest Common Lisp project.

I expect to update this as I find out more, so don’t be surprised if I change something later!

I hope this will help my future self and also perhaps you, the reader, who also enjoys Common Lisp but can’t really find things easily online. Hopefully, now it will be a tiny bit easier!

The most common super-power (ok, maybe not a super-power, but a non-trivial feature) given as an example is generics, but there are many more.

In this post, I decided to have a look at that in more detail and compare Zig’s approach with what some other languages can offer. Zig uses comptime for things that look a little bit like macros from Lisp or Rust, templates from C++ and D, and code generation via annotation processors from Java and Kotlin! Are those alternatives anywhere near as powerful? Or easy to use?

I will investigate that by looking at some Zig examples from Loris Cro (Zig evangelist)’s What is Zig’s Comptime and Scott Redig’s Zig’s Comptime is Bonkers Good.

I only know relatively few languages, so apologies if I didn’t include your favourite one (do let me know if your language has even nicer solutions)… specifically, I don’t know much C++, so be warned that while I am aware C++ has constexpr (I guess that’s the closest thing to comptime), I won’t even try to compare that with comptime in this post!

I have recently decided to play around with a few niche languages in the “system programming” realm. Having been programming for many years in higher level programming languages such as Java, Dart and Kotlin (and tried many, many others at the same level, or higher), I feel like I need to expand my horizons as for certain kinds of applications, these languages are just not the best tool for the job.

In this blog post, I want to focus on the D Programming Language because that’s the one that called my attention a bit more than the others, after some initial experimentation.

I also mocked around a bit with Zig and Nim but didn’t feel like they were the right language for me, at least for now (they’re really cool anyway, do check them out!).

Of course, I had already looked into the king of this space, Rust… but Rust, while being a genius language in many ways, doesn’t really make me excited about writing code - to the contrary, the thought of spending weekends battling with the borrow checker fills me with dread. I would absolutely use Rust in a working context (and have done so) due to its safety guarantees (not just memory safety but specially resource- and thread-safety it provides) and outstanding performance (both in terms of low memory consumption and raw speed), but for hobby projects, thanks but… I just don’t see that happening (I already abandoned a few Rust projects halfway through, I’m afraid).

Nim goes a bit too far towards the other end, in my opinion, as it’s a very playful language where I felt that safety is considered less important than speed and, well, joy. So if you like that (it’s also very fast, creates tiny binaries and uses very little memory) it may be just the language for you.

Zig has a lot of promise, but it just doesn’t feel ready at the moment. It’s also turning out to be quite verbose and difficult to use correctly despite its focus on simplicity.

D seems like a good balance. It looks familiar while having some very interesting features. It’s been around long enough that it’s no longer trying to find itself and changing every 6 months.

In this post, I’d like to share what I learned, with a focus on an unusual aspect of the language, its metaprogramming capabilities, and on another feature that very few languages include, despite its importance and obiquity in modern programming practices: unit testing.

I’ve wanted to automate my home for a long time… having a background in industrial automation and software development, it felt like I was in a great position to be an early adopter.

However, every time I looked into it, I quickly gave up because of two main problems:

• the sheer complexity of it all.
• prices.

The complexity seems to be intentional on the part of most vendors. They tend to not make it clear whether their products work with any controller (if you’re completely new to home automation, don’t worry, we’ll see soon what this means), which software can be used, which devices are compatible with what…

Prices of smart devices have always been ridiculously high, at least one order of magnitude higher than their dumb counterpart. That’s understandable when a technology is still in its early days. But home automation solutions have now been around for a long time!

It’s about time smart home devices became more accessible. Well, they may still not be cheap, but finally, prices have gone down enough that I’ve finally decided to take the plunge and get myself a few smart things to start playing with!

I got a few power plugs, a motion sensor, a little button that can be programmed to do whatever, and a smart home controller to connect to it all.

A smart home controller is a hub that connects to all sensors (e.g. thermometers, power consumption meters etc.) and lets you get information about them, as well as control devices which can be controlled (e.g. turn on lights, change their colors, open/close the curtains, water the garden etc.).

I chose to buy an IKEA Dirigera to start with because at least where I am, IKEA smart things are the cheapest by far! But also because IKEA’s smart home products use Zigbee, which is a widely used protocol for home automation, so I could easily migrate to another hub (another name for the controller that manages the things) at some point, if desired (which I did, as we’ll see).

I also got a Wifi light strip from IP-Link for good measure (it’s pretty awesome!).

After learning how to use the apps (from IKEA and IP-Link), including integrating them with my Google Nest Hub, I was a little bit underwhelmed. Even though it’s really cool to be able to say “hey Google, turn on the lights in the main bedroom”, and it just works(!), there’s very little automation you can actually do beyond what’s achievable with good old dumb electronics because of all the limitations of the apps.

What I really wanted was to be able to program my home, like I can program my software, well beyond what some manufacturer’s app allows me to.

Thus started my chase for the perfect smart home software setup!

The usual smart home software people use

At first, I tried a few smart home automation servers which are normally the “obvious” choices for this kind of stuff.

OpenHAB is a Java-based server which uses OSGi for its plugin system, meaning it can load/unload plugins at runtime to support an enormous amount of add-ons for seemingly every smart home product.

Even though OpenHAB looks great, it’s a complex system. Understanding its concepts and how to configure a nice dashboard, install things, add automations is very time consuming, I believe (if I remember correctly) I spent a few days on it and only managed to get one thing connected, and didn’t really get to the point where I had a working dashboard at all.

I also looked at what is probably the most popular smart home hobbyist server, HomeAssistant. It looks pretty, has an easier setup than OpenHAB, has a neat USB Dongle that makes things even easier… but what put me off with HomeAssistant were two things: first, it’s based on Python. I have a strong aversion to Python due to its horrendous package management history (we use dozens of languages at work, guess which language is the only one that causes build issues all the time?). It’s a nice language, but for things like home automation, having build/dependencies problems is the absolute last thing I need.

The biggest problem with HomeAssistant, however, is its really overengineered setup for running on mini computers like the Raspberry Pi, which was my goal.

The recommended way to run it is with a fleet of Docker containers (and they even tell you to install their own Linux distro to make sure all the large amounts of software you’ll need is managed more easily).

Just imagine for a second, you’re automating your house to do little things like turn on a light at a certain time… perhaps open the curtains in the morning as your alarm sets off in the morning. Is the best solution we can come up with a bunch of Docker containers running on a custom Linux distro?

As with OpenHAB, this all felt way more complex and heavy than I was hoping for. And I couldn’t even find a way to use them to actually write code to perform automations the way I wanted, rather than limited visual programming tools which seem to be the standard way of doing things in this world (no, thanks!).

Raspbee 2 and deCONZ REST API

That’s when I finally found something that made sense to me: the Raspbee 2 Zigbee Gateway, which is a tiny circuit board you plug directly on the Raspberry Pi’s GIO plug (they also have a USB dongle version).

You then connect to it using either their simple web-based app (useful to set it up) or the deCONZ REST API they expose.

This is exactly what I am looking for!

Having full access to my smart things via a REST API would, after all, allow me to write code in whatever programming language I’d like.

The next challenge was to decide what stack to use to create a little web application I and my family could use to interact with the smart things… I wanted something extremely light so I could run it even on an older Raspberry Pi 2 that I had lying around with low power consumption… also the less complex, the better chances are it will still be working 10 years from now, which I think is very important for something that’ll become part of the house.

By chance, I found a solution which I didn’t expect at all (I work with Java, but wanted to avoid it as I know it’s far too memory-heavy and slow on small devices): Lua.

Why Lua?

Lua was designed to be embedded in C programs. It’s probably the lighest practical language you’ll find.

Justine’s Redbean web server, which is an αcτµαlly pδrταblε εxεcµταblε that embeds Lua and SQLite and runs on most Operating Systems (the same file!), is a mere 2.2 MB download and runs using less than 1MB of RAM.

For this reason, I considered using Lua and was delighted to find out that there was a really lightweight web server made exactly for things like this: the Mako Server.

The Mako Server is based on the Barracuda Application Server, which was designed to work on embedded devices. It supports VxWorks, QNX, Zephyr, FreeRTOS+TCP and lots of other OSs, including of course the mainstream ones, Linux/Windows/MacOS!

Mako has a special download for the Raspberry Pi which comes with support for using GPIO from Lua. I built it from source on my Pi and it only took a few seconds.

What is the most amazing is the amount of stuff packed into this tiny server: a HTTP Client, JSON/UBJSON parser, SMTP, MQTT, TLS, SQLite, and obviously, Lua and LSP (Lua Server Pages) which makes it easy to generate web content.

The result is a web server that uses less than 3MB of RAM (even including the built-in Mako, Barracuda and Lua’s complete Docs, and a code editor for changing things on the fly) while running and that I can code live.

In the rest of this blog post, I’ll show how to get started with the Mako Server, and how to use it to talk to the deCONZ API to automate any smart home setup.

As I write this in early 2023, finally, I think it has reached a level of maturity where it’s actually usable for real work, so I decided to write about my impressions using the language for something non-trivial.

Could it really be the language of the future, as its website cheekily proclaims?! What’s so revolutionary about it? Why are we not using its revolutionary ideas in other languages yet if they are so great?!

Let’s have a closer look. It really is worth it!

Introduction to the big idea

The Unison website is very cool and has a full page dedicated to explaining the big idea behind Unison. So, I highly recommend reading that before you continue. Please come back after you’re done!

In their words, here it is:

Each Unison definition is identified by a hash of its syntax tree.

Put another way, Unison code is content-addressed.

Yes, that’s very concise and may not sound terribly interesting. But this simple idea enables things you probably didn’t even think were possible.

For example, Unison does away with builds. Completely! Have you been looking for a language that has great compile times while still being strongly typed? Well, how about a language with basically zero compilation time??

It sounds outrageous, I know… I also thought it was basically bs before looking into it in more detail. But, believe me, it’s not.

Code is not stored in multiple, seemingly unrelated text files in Unison. It’s stored in an actual database. One that you can only append to, similar to a Git repository.

The reason Unison doesn’t have builds is that code is already stored in its type-checked, AST (Abstract Syntax Tree) form in that database, linked to other definitions by its hash.

If you write the same function with different names, even with different variable names and perhaps declaring bindings in different order, for example, Unison will just store one function, but add an alias to it if you really want it. It has a canonical representation for all code, which allows it to do that.

Even documentation and types are stored this way, though you may use unique type to avoid identically structured types to be considered the same.

When you change the type of a function, it only impacts other code that uses it if you explicitly use Unison refactoring capabilities to update that function everywhere it’s used (we’ll see exactly how to do that later). It’s simply impossible to commit code that wouldn’t compile. You can choose to leave the old function alone and just bind the name to a new function, or rename the old one, that’s fine too! It’s your choice.

That means there’s no version conflicts either in Unison. You can have different functions using different versions of some other function at the same time. The different versions are different hashes, and functions only refer to the hash of other functions, so there’s never a conflict.

This idea also enables easy distributed computing, after all, sending a computation, code, data and all, to another machine, is much easier when you know exactly what the code dependencies of the computation are, what the data type definitions are, and are unique and cannot conflict.

This is not an original idea

Many readers may be interjecting that this idea is an old idea: Smalltalk already had the idea of an “image” where all source code was stored instead of text files.

Other readers may remember Joe Armstrong’s famous talk, The mess we’re in, where the idea of using (unspoofable) hashes instead of names to facilitate distributed computing, among other things, is expanded at around the 36:00 mark.

However, Unison may be the first time this idea has been implemented in such a way that the full benefits described in the previous section can be fully realized. Even if it’s not, I believe it’s still a wonderful implementation of that idea, specially when combined with pure, statically typed functional programming.

They help us in so many ways it’s almost impossible for me to imagine working without one.

But all the stuff they do to help us is not free, and lately, I’ve been suffering the consequences of that. I use an under-powered MacBook Air from around 2019 as my “hobby project”, personal laptop, and running the community edition of Jetbrains’ IntelliJ IDEA, my favourite IDE, on it has been an unpleasant experience.

In this post, I wanted to pose the question: do IDEs really need to be so heavy that we can barely use one on a laptop that cost a thousand dollars just a few years ago?

As long as things work, you barely need to pay any attention to which versions of your dependencies you’re currently using (but you should, of course), so that’s understandable.

But if you want to build reliable software while keeping up with latest security patches in all of your dependencies, which requires constantly updating libraries and making sure no breaking changes have been accidentally introduced and that all libraries remain compatible with each other, then you’re in for a challenge.

While this problem exists in every programming language in existence (with perhaps one exception), some languages do it better than others.

However, in this blog post, I am going to look in detail at the Java way of handling dependencies, which is mostly based on Maven (though Apache Ivy, Gradle and Bazel are also going to make appearances).

I will also mention some other language’s and language-agnostic package managers (like Nix, for example) in order to try to identify more clearly how things are done today outside the Java world, and where things seem to be heading.

A large amount of the lowest level software that is widely used today, from the Linux kernel to curl, from git to grep, and in fact, all of the GNU Core Utils, stuff you use every day like kill, cat, cp, mkdir, rm, du, date… all of this is written in C.

Check the source code for some of these utilities here. There’s something magic about being able to read the actual C code of these little programs we use in our day-to-day without thinking how it’s probably been there for over 40 years.

While C is a simple language, actually using C properly is really, really hard. There’s very little in the way of abstractions and “safety” when compared to higher-level languages, or even more modern lower-level ones. It’s about as close to the metal, as some people like to say, as you can get without writing machine code (with the probable exception of Forth).

“C is a pretty basic language with not a lot of features. It can do anything, but it can make you work for it.” - Beej’s Guide to C Programming

For this reason, there has been a wave of languages trying to replace C with something better. C++ was probably the first one, but it was soon followed by others, like D, Rust, Nim and more recently, Odin, Vale and the one that we’ll be looking at for this blog post, Zig.

There are many more modern lower-level languages competing with C, see robertmuth/awesome-low-level-programming-languages for more.

The problem is that C is still alive and well, and it’s probably not going anywhere any time soon. There’s just too much of it out there, and some of the effort to replace all that legacy with something new (which I am sure would bring its own different set of issues with it) could be better spent elsewhere.

That’s why I think that rather than trying to replace C completely, we should be doing more to actually ensure the existing C code we rely on is wrapped into saner APIs and as well tested as possible, allowing us to integrate with all the legacy C gives us without fear.

It’s in this context that I found out that Zig embraces C instead of treating it like dirty garbage. It makes it very easy to interop with C, and the Zig compiler itself can compile C code. It might be using MSFT tactics, of course, but even if that were the case, it still gives us a nifty tool to improve test coverage and usability for the mountains of C code we will probably have laying around for a long time!

From Zig In-depth Overview:

• Zig is better at using C libraries than C is at using C libraries.
• One of the primary use cases for Zig is exporting a library with the C ABI for other programming languages to call into.
• In some ways, Zig is a better C compiler than C compilers!
• Zig is faster than C.

I know, a lot of grandiose claims that are hard to believe… but even though there’s been quite a few similarly outrageous claims from other sources in the past that turned out to be nothing other than vaporware, I don’t believe that to be the case with Zig.

I’ve tried it, and from what I can see so far, it delivers on nearly all fronts.

Including the part where it claims to be a better C compiler than any other C compiler!

In this post, I will be building a C project with the Zig compiler and build system, testing the C code with Zig’s native testing system, and finally, giving a taste of what brand new, fresh Zig code looks like.

All sample code in this blog post can be found in this GitHub repo. See the commits.

Given how Java has had, since Java 9, a System.Logger right in the standard library, I decided to investigate whether that has the potential to change things, or whether it’s just another logging API in a growing list of options on the JVM.

But before we get to that, let’s discuss how we got ourselves in this situation.

Note: This is a follow-up blog post to Revenge of Lisp - Learning Common Lisp to beat Java and Rust on a phone encoding problem. Please read that blog post first for context.

In the previous Part of this blog post, I introduced basic Common Lisp to non-Lispers and discussed the phone number encoding problem, as well as Peter Norvig’s quick implementation of a solution in CL - which are the basis for this post.

We also saw that the CL code had very competitive performance, running faster than Java and Rust for the most part, while consuming much less memory than Java, and not very far from Rust’s nearly optimal memory usage.

However, the Java and Rust implementations were, as CL’s, written without much thought given to performance, after all the description of the original study which introduced the problem asked participants to focus on correctness and readability, not performance.

Besides that, there were some problems with the benchmark, as it was originally meant only for a quick comparison between the languages, not as a formal proof of relative performance. In any case, if we’re going to mention performance, I acknowledge that some improvements are required in order to avoid misleading the reader, so I spent quite some time thinking about it, and designing a few changes to both how the benchmarks are run and to how programs should be implemented in order to get a more accurate picture of how each language really performs.

In this post, I will discuss these improvements, then focus on the Common Lisp implementation and the available techniques for making it run faster. As with my previous Rust blog posts, I will show how each modification affects the performance of the code. The objective is to get the fastest implementation possible, and having optimised Java and Rust implementations to compare against is a motivator to keep going until there really isn’t anything else that can be tried!

Do you think Common Lisp can run as fast as well-optimised Rust? Read on if you want to find out.

It all started when I was reading, funnily enough, a blog post about another, much more hyped, language called Julia. The post was titled Julia and the reincarnation of Lisp, and in it the author lamented that despite his love for Common Lisp, it’d never become popular, so he was now trying Julia instead as it may become mainstream soon.

Anyway, what called my attention the most was not Julia (I’ve seen this promise of a new language that is as fast as C and as easy as Python a few too many times to believe it), but all the Lisp prasing, including by taking a jab at poor Java, of all things:

I wondered how they could be so certain of that (and why they thought they needed to create something else anyway if Lisp was so great). As someone who’s written a lot of Java code, I would love to use a language that takes much less time write things in… so, I followed the linked article, which led me to discovering a few papers written in the late 1990’s and early 2000’s comparing Java with Common Lisp and other popular languages of the time. That made me think that, 20 years later, it would be a good idea to revisit the topic and compare Lisp with modern Java (those papers used Java 1 and 1.2!) and other newer languages like Rust to see whether the results of the old papers (which generally lauded Lisp while slamming Java) still held today.

I ended up slightly obsessed with doing that for the last few months and wrote a few articles about what I found out, including Revising Prechelt’s paper…

Common Lisp - a brief history and introduction for non-Lispers

Common Lisp, henceforth CL, is actually an ANSI standard. It does not have only a single compiler implementation, far from it, there are lots of implementations, both free and commercial.

In this post, I am going to use the most prominent and performant (I believe) free implementation today, SBCL.

Lisp is a big family of languages with a long tradition. The first Lisp was described already in 1958 by John McCarthy. Today, there are arguably three main languages in the Lisp family tree: Common Lisp, the result of an unification effort in 1994 which resulted in the Common Lisp’s ANSI standard… Scheme, which today has spawned many dialects such as Racket and GNU Guile (most notably used in GNU Guix), and Clojure, which was created by Rich Hickey based on his frustrations with both Java and the existing Lisp implementations at the time.

Even though Clojure might be a more obvious choice for someone, like me, who is used to working with the JVM, I actually wanted to try using something else with a lighter runtime and great performance.

If you’re new to Rust, it may be worthwhile looking at those posts first.

We ended up with a fairly optimized code base that was able to leave behind the Java and Common Lisp implementations (though they were not as optimized - which deserves another blog post)!

So, this time let’s focus on Rust and on what Rust developers can do to make their code go fast fast!

I have received a lot of feedback after these posts, specially the latest one, hence I would like to clarify a few points that I think were not made clear enough, and respond to some criticism that I think was very unfair.

I will also go further and show even more ways of making Rust code faster!

The post was about an old study by Lutz Prechelt comparing Java to C/C++, as well as a few follow-up papers that added other languages to the comparison, including Common Lisp and a few scripting languages.

I decided to try and see if the results in those papers, which ran their studies 21 years ago, still stand or if things changed completely since then.

I couldn’t get a bunch of students, let alone professional programmers, to write programs for my “study” in multiple languages, so I did the next best thing and ported the arguably most common approach to the problem (based on code by Peter Norvig, no less) to other languages: Java, Rust, and later also Julia and Dart.

The results were shocking: Rust was one of the slowest languages! It had the lowest memory usage, but also the highest LOC (lines-of-code) if I included only the implementations of the same algorithm.

Today, I want to appease angry Rust fans and other concerned parties by showing exactly why my Rust code was so slow, and how with a few small fixes, it can outperform the other languages in the “competition”, at least in performance (and as I found out, for certain kinds of inputs only).

Thanks to the Rust fans who took a lot of their free time to show me just why my Rust code was so slow and how to fix it!

In that paper, they analysed data from a study (which was run for another paper, as we’ll see later) where participants were asked to solve a problem consisting of encoding phone numbers into a combination of digits and words from a dictionary, presumably to make it easier for humans to remember phone numbers they might want to recall later (this was in a time before mobile phones were widespread).

The same problem was later used by Ron Garret (aka Erann Gat) in his short paper, Lisp as an alternative to Java, henceforth , from the year 2000.

Both papers have been widely cited and continue to be linked to even today.

In this article, I would like to revisit these papers, analyse their methodology and conclusions, and try to find out whether anything has changed in the 21 years since those articles were published by writing my own solutions to the problem as if I, myself, had participated in one of the studies.

I wrote a solution in Java without looking into any other solutions in order to find out how my solution (and Java 16) would’ve done if it had participated.

After that, I analysed some other solutions and compared them against mine. Based on my findings and some comments by Prechelt himself in his paper, I decided to write a second Java program to match a completely different strategy that was commonly used in the more dynamic languages. I implemented the same algorithm also in Rust in order to get an idea of how a very modern systems-language would do.

That should allow us to compare modern languages more directly by using the same exact algorithm (to the extent possible), eliminating the potentially big differences that could arise from the different algorithms chosen by the programmer.

With all these features, I think it’s fair to consider Java Standard Edition, or Java SE, as a framework in its own right.

It is not to be confused with Java EE, or Java Enterprise Edition [1] (recently rebranded as Jakarta EE), which adds loads and loads of APIs against which Java programmers can create huge enterprisey things on top of JSPs and Servlets, for example.

Java EE was all the rage in the early 2000’s, but these days you’re more likely to find Java software based on things like Spring and its more streamlined version Spring Boot, or even trendier things like Micronaut and RedHat’s Quarkus (I know it must be very cool because its slogan is SUPERSONIC SUBATOMIC JAVA), both of which promise to make Java more Kubernetes/Cloud/Microservice friendly [2].

What you’re very unlikely to see is Vanilla Java being used in the real world.

This disturbs me (in a weak sense, like people flashing bare ankles on a freezing day disturb me) because I find Gradle to be one of the greatest tools available to build things. That is perhaps the result of coming to it by choice, after having suffered for years at the hands of XML-heavy tools like Ant and, later, Maven. Add to that an inevitable but unhealthy dose of bash scripts and Make files, and building software had been a tough call for me before I met Gradle.

In this post, I will try to convince you, the reader, that Gradle is, in fact, a great piece of software that can be used to build nearly any software in a quite elegant manner, despite the best efforts by plugin authors and Gradle, the company, to pile up layers upon layers of complexity and configuration options over the years in the name of pursuing infinite flexibility and, of course, ensuring newcomers’ claims at being better at any particular thing, no matter how irrelevant, shall not go unchallenged.

To convince you, though, I need to show you how Gradle really works.

Its objective is to support easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform, according to the Project’s Home Page.

I was very excited to read about the current state of Project Loom in the State of Loom article which came up just a few days ago! The final design they have settled on is a dream-come-true for Java developers.

It will allow nearly any existing code that currently relies on the good-old Thread class for concurrency to immediately benefit with almost no changes at all, all the while making one of the hottest features of cooler and trendier languages, async/await, look like one of those regrettable it-sounded-liked-a-great-idea-at-the-time features they wish they didn’t have anymore.

It even sounds too good to be true, and whether that’s the case remains to be seen!

Luckily, State of Loom published a link to the Loom EA binaries so anyone can already take it for a spin! And that’s exactly what I did.

Here’s what I found out!

• write tests in your favourite programming language using a HTTP client.
• use a GUI tool like Postman, Swagger Inspector and its older cousin, SoapUI.

I believe that none of these approaches is ideal. Furthermore, I think that an alternative solution exists that is much better in most situations, but is still not very well-known: writing HTTP directly in a text file, with a few human-friendly conveniences added in order to make it a more pleasurable experience.

In this blog post, I will explain what I believe is the problem with the current approaches, and why HTTP files are a great alternative.

In summary, it is a low-level instruction format that’s both fast to load and to execute, perfect for handling demanding content in a web browser that JavaScript would have more difficulty handling.

Web Assembly has two formats: binary (the default) and a textual representation which is human readable.

In fact, it’s possible to write WASM by hand using the textual format.

Even though the language is stack-based (like Forth), it has some “syntax sugar” that allows for nesting instructions, making code look much more familiar to developers used to more usual languages.

For example, the following code performs the equivalent of 2 + 3:

i32.const 2
i32.const 3
i32.add

This can be also written as:

(i32.add
    (i32.const 2)
    (i32.const 3)
)

Not very different from Lisp (except for the explicit types everywhere):

(add 2 3)

The similarity between WAT (WASM Text) and Lisp is not just a coincidence! As Lisp, WAT is based on S-expressions, which are very easy to parse, something that’s a goal of WASM.

It’s really fun to try to write to WASM like this! And more than that, it’s a very good way to learn WASM, which is important for anyone writing compilers targeting it.

But the current compiler toolchain to interact with WASM is quite focused, understandably, on compiling C, C++ and Rust to WASM.

Besides, the “normal” way of running the compiled WASM is by embedding it in a HTML page and loading it on the browser.

So, if you just want to play with the textual format and quickly run the code, things are harder than they should be.

That’s why I decided to find something that could run WASM outside of the browser, and being a JVM developer, if it ran on the JVM, even better!

Doing a little research, I came across the cretz/asmble project, which can run WASM and WAT directly on the JVM by compiling to Java bytecode!

In this blog post, I will show how you can use that, as well as WASM-on-JVM Gradle Plugin I wrote, to easily play with WASM and interact with it from standard Java and Kotlin code.

But before that, let’s have a quick look at how the WASM toolchain normally works, so we understand the differences.

Flutter developers tend to love the language from what I’ve been reading lately, and I can definitely see why.

Flutter is already the 3rd most loved Framework in the StackOverflow Developer Survey 2019.

In this article, I want to show how the Dart of 2019 (version 2.4 to be exact) is actually quite an exciting language!

I’ll discuss some nice feature of the language itself, as well as some neat platform characteristics (like built-in platform-specific - like browser - testing support and hot reloading) which make developer’s lives so much easier.

By the end, I hope you’ll be as convinced as I am that Dart deserves the success it is starting to finally enjoy, and that it might be a good choice for multi-platform development at present, and even more in the future.

After all, back in 2011 when I was doing web development, people were already experimenting with that idea… for example, I was using GWT, which is a Java-based web toolkit, in 2011… surely, 8 years later, the scene should have improved a lot for Java-based web applications?

I set out to see what’s available out there. Can a backend developer who is happy to stay with the nice tooling and great ecosystem of the Java world do frontend work without jumping ship to the madness of the JS world?

Get ready to find out!