This article is for you if you either:
I started learning Haskell a couple of years ago. Usually when I learn a programming languages past the “Let’s see what it does different” stage, I do so because there is a concrete use-case - a project I want to contribute to. With Haskell it was different. My primary motivation to learn Haskell wasn’t a concrete use-case, but instead I had the impression studying the language would be worth it just for the sake of learning. It does many things different than most other mainstream languages and I wanted to become familiar with concepts I hadn’t seen before. (Spoiler: It was worth it)
Writing a couple of iterations of “Hello World” applications wasn’t going to get me far, and utilizing it in a project at work also wasn’t an option, so I started using it for my ad-hoc scripts or utility scripts. Previously Python was my go-to language for such things, but Haskell ended up replacing it. In this article I will go through some of the reasons.
In this article we’ll take a look at the circuit breaker mechanism in CrateDB. CrateDB uses circuit breakers to prevent a node from running out of memory or stalling due to high garbage collection load.
In this post we’ll look at how CrateDB distributes GROUP BY queries. This is the fourth post in a series about CrateDB internals.
I assume that you’ve read the first and second post of the series. You may also be interested in the third post, but it is not necessary to read it to follow this article.
This is the third post in a series about CrateDB internals. This time I’ll introduce the Query Then Fetch execution strategy. Similar to the previous posts, this focuses on the distribution aspect.
This is the second post of a series about CrateDB internals. In the first post I introduced relational algebra, the optimizer and outlined how the execution works on a very high level. In this post I’ll explore the execution of a simple SELECT statement in more detail. This post focuses on the distribution aspect of the query execution.
This post is the first of a series that explains how CrateDB executes queries. This first post focuses on the optimizer, logical plan and execution plan.
Over the last couple of years I’ve developed an intuition that shallow functions can be problematic and here I’d like to share some thoughts on why that is the case.
In this post I’ll show you the basic building blocks of a completion plugin for Neovim.
Two scenarios that may sound familiar:
You’re in an office space and there is this one person who always asks questions that they could answer on their own by spending two minutes using Google DuckDuckGo. He feels super productive because he’s getting answers quickly, but the senior who has to answer starts getting annoyed by all the micro interruptions. It makes it hard for her to focus.
A new person joins a team, and they hardly ask any questions. Instead, they spend hours trying to figure out everything on their own.