kendru

Sure, Presto/Trino has better market share, but Drill is still a useful project. I think the main issue is one of marketing - Presto has it, and Drill does not.

I honestly had no idea that Thunderbird was still around. It looks kind of... nice, actually.

I love seeing examples of people showing off a simple, purpose built solution. It's possible to do simple things quickly and with a small amount of code.

The lack of a serverless option was the only reason that I did not use Cockroach on a recent project. I am excited to see the serverless offering now, and the architectural details in the post are awesome. Nice work!

This is a useful technique. I have used it in at least one application before. One of my favorite things about it is that you can use it even when you don't own the application writing to the database!

I think those are very good points. In my opinion, the hoisting of packaging concerns from language-level and OS level was inevitable, and containers an an okay way to do that.

I am familiar with FreeBSD jails (and IMO, they are actually superior to Linux containers in most respects). My point is not so much that other systems don't have the tech to make containers work - or that OS vendors are not capable of adding containers to their kernels - but that having container technology is not the same as having a smooth devex for containerized applications.

When I started in software development, I was mostly working on monoliths. All dependencies were vendored or were expected to be dynamically linked on the system where they were deployed.

Next, I started working with Docker and languages with better package management. Dependencies were fetched in CI and were either statically linked or packaged in a container with the application I was working on. Still, these were mostly monoliths or applications with simple API boundaries and a known set of clients.

In the past few years, almost everything I have written has involved cloud services, and when I deploy an application, I do not know what other services may soon depend on the one I just wrote. This type of workflow that depends on runtime systems that I do not own - and where my app may become a runtime dependency of someone else - is what I am referring to as a "modern development workflow".

I love how the post is a demonstration of the practice it describes.

Author here. I have been developing Docker applications for years now, and while the experience is better than it used to be, it's still not great. I work for Deref, which is working on developer tooling that is more amenable to modern development workflows. We'd love to hear what pains you have with the current state of development environments.

I am so excited to see this in print! I know that this was a ton of work, and I can't wait to get a paper copy. Nice work, Bob!

Having worked with several functional programming languages, my personal experience is that Clojure seems to lean more towards the productive end of the spectrum than the pure end. There is a definite learning curve coming from JavaScript, but (as someone who currently writes more JavaScript than ClojureScript), I still find that the ClojureScript that I write ends up being simpler will a smaller code footprint than a similar JS solution.

Clojure(Script) is not for everybody, but I love it because it is very natural for me to use, and it seems to fit the way that I think better than most OO languages that encourage top-down design. I agree that security, performance and correctness are good end goals, but they are not the only goals (another one that comes to mind is maintainability), and I have found Clojure to be a good means to reach those goals.

I was not aware of cljs-bean, but it definitely looks like it's worth checking out!