Posts

I keep thinking about this idea of a different approach to building Operating Systems. I know it's not a new idea.

I guess the core of the idea is that the programming language, its runtime, and the OS should be the same thing. You know - kind of like Emacs or generally Lisp, or Smalltalk. Where the language is the runtime, and it allows modifying itself while its running.

Maybe I'm wrong, and what do I know about anything anyway, but I think the previous attempts to make this a reality were outcompeted due to practical considerations: mostly performance and resource utilization.

You see, I am a bottom-up developer.: When I was a kid I first learned how do electric switches and transistors work, how to chain them into longer logical circuits. I was playing with writing assembler code for MOS CPU of my C64, POKEing and PEEKing bytes into addresses of memory mapped hardware registers. As a teenager, I was hacking on a Linux kernel. For me, the computer will always be only a very fast automaton, composed of circuits, capacitors, and so on, executing long sequences of tiny CPU instructions, and the job of software is to make it do something reliably and efficiently.

The new era is beginning, and the old era is ending. C and C++ as a lingua franca of systems programming are being displaced by Rust. Many will deny it, many will fight it. But I'm confident it is already happening and is inevitable to continue at accelerating pace.

As some people might now I am a vocal OOP critic. I think it is fair to say that I am on a crusade, actually. :D

Oftentimes, my long online posts explaining what is wrong with OOP meet with a No true Scotsman argument. That I am somehow pointing out to flaws in caricature of an OOP, and the correct OOP is free from these issues. To prove to myself and other people that it is not the case, I decided to go through some classic OOP books, and criticize the OOP examples in them.

My first choice is the Clean Architecture by Robert C. Martin (aka Uncle Bob). I must admit Uncle Bob is not one of my favorite software engineering gurus. But he is a reputable and experience developer, and if he was to write a caricature of OOP, then who are the people who dare to say they do it right?

Everybody does code reviews nowadays (I hope!). Research shows that it increases quality... blah, blah, blah.

But, how many times did you think about how much does it cost? Because you know ... Code Review isn't free. Code Review takes time. A developer publishes a PR, and then... what? Is there anyone readily available to review it? Other devs are busy doing their own stuff. Should the developer interrupt someone to get a fast review? Or just context switch to something else for now? I'm sure the research was not investigating this part.

Before most readers close this page enraged, shouting "Obviously, Code Review is good, you fool! It's totally worth it!" Yes, Code Review is worth it! I didn't say it isn't. I only said that it does have productivity cost and you should not ignore it. Please, while you are aware of the benefits you're getting, also acknowledge the costs you made to gain them.

I'm not just trying to be controversial and/or annoying. My point is: if you want to be good at something, you have to be mindful of both of them: benefits and costs, to maximize the former, while minimizing the later! Most of my guidelines below are going to be about minimizing the cost of Code Reviews.

This is going to be a quick overview of how I tend to write my application code. It might be a bit Rust-centric, but I apply similar methods in all programming languages I use.

I think it's an important subject and during past online discussions about learning Rust and writing code "the Rust-way", I was asked multiple times how do I do it. I don't really have a lot of time to write something longer and better structured, so please excuse anything that is confusing. You get what you pay for.

Also, I don't want to suggest this is some sacred, best way or anything like that. I think this is what I'm typically doing. A result of years of professional and Open Source work and experiences I gained during that time. I'm always happy to learn and get to know other points of view, so I'm happy to hear any feedback.

Test runners/frameworks caused me a lot of grief over the years. It's part of the reason why really appreciate how standard #Rust test runner works. As usual with Rust, core developers, and the community at very least avoided the most common misfeatures and made the right thing to be the easiest and most natural thing to do.

That's why i recently (probably too abrasively) bashed an announcement of some new Rust testing library.

I've taken some time and collected a list of feature request, misfeature rants, that I just want to share.

or: Notes on indexing blockchains

A copy of this post can be found on rust-bitcoin-indexer wiki.

Abstract: I have ventured on the quest of discovering the best way to index a blockchain. Surprisingly little has been written about it, considering that it is a common task for any organization handling blockchain-based interactions. It seems that, it is an area dominated by in-house solutions, with very little knowledge sharing. In this post, I go over the problem, ideas, discoveries, and experiences. I also describe a Bitcoin Indexer implementation that I have worked on while researching the subject: rust-bitcoin-indexer.

I expect the reader to be familiar with at least the basics of Bitcoin.

Please note that this is not scientific research and only a spare-time project. Feel free to contact me with comments: pointing out any mistakes and ideas for improvements.

or: A token (even smart one) needs a blockchain, like a fish needs a bicycle.

Image above: Tokenizing assets on a Blockchain

Abstract

In this post, I explain why I believe Blockchains are just coincidentally associated with "token economy" and smart contracts, and how in essence they are not their enablers, but actually a hindrance. Then I propose an alternative: a concept of an open, federated smart contract system, that maintains all the benefits traditionally associated with blockchain platforms like Ethereum and can practically support a global scale token-economy, without all the problems inherent to blockchain-based systems.

Today, I'm going to give a contrarian view on tests and testing in software.

From my experience, the most common view on software testing is: "Tests! Tests! Always have tests! Start with a test! End with a test! More tests - good! Less tests - bad! 100% coverage! Test everything! How can you not have tests everywhere?!" ...

... or its opposite-side tween: "Tests? Why bother? Maybe later."

Before I go any further, a note for the typical distracted reader, that is going to skim over the text, misunderstand it, and go rage over social media how stupid the author of this post is: I'm not saying that tests are bad. I'm going to focus on the bad side, but that is not the only side. Go read somewhere else about the good sides.

I am a crypto-finance enthusiast and though I am strongly skewed toward Bitcoin maximalism, I still try to follow the space looking for promising technologies and ecosystems.

One of the coins that really caught my interest was Grin

• It has no fishy business (pre-mine, dev-taxes),
• is written in #Rust (which, I think, is a perfect language for #cryptofin),
• it is based on MimbleWimble which is a very promising tech improving blockchain scalability.

It ticks all the boxes to be a reasonable altcoin.

The only problem with it is it's controversial monetary policy. Basically: one coin, every second, forever. While I don't mind the "forever" part, the problem with Grin's monetary policy is the steady and long initial inflation rate.

Code reuse in Rust

In my opinion, one of the biggest reasons why Rust is so productive is that it's a superb language for code reuse.

First, ownership and borrowing system allows exposing in the API properties that are often impossible to express in other languages. The fact that the API communicates and enforces how the resources are being created, shared and moved and destroyed, all checked at the compilation time, gives the user great confidence that they are using any API - internal or external - correctly.

Second, Rust comes with first-class built-in tooling around discovering, creating, sharing and using publicly available Open Source libraries. It's not a property unique to Rust, but it builds a powerful synergy when combined with the first point.

Third, the community (at least so far), were strongly encouraging uniformity and commonality: similar code style, similar documentation style, common core libraries, and patterns. A big chunk of this effort was achieved through great tooling like rustfmt and clippy. Thanks to this, Rust ecosystem does not feel fragmented. Jumping into a code authored by someone else does not feel like a venture into a foreign land, as it often does in other programming languages.

Together, this properties creates a language and ecosystem where code reuse is almost effortless. While in other languages it's often more tempting and more convenient to implement things yourself and avoid learning a new API, in Rust the difference between own and 3rd party code, often blurs completely. In a way, this creates a completely new quality of building your software.

Despite all these strengths, there's one problem that sticks out like a sore thumb: trust. Every additional dependency is another piece of code that could be buggy, or even malicious. And in my opinion, it's problem so serious, that is entirely blocking the untapped potential of code reuse in Rust.

The longer I do software engineering (and even things outside of it), the more confidence I have that one of the most important metrics (most important one?) in any sort of creative process is iteration time.

What do I mean by iteration time? The time between having an idea for change and getting real feedback from the real world what are the results of implementing this idea.

Worse is Better, Agile, Lean, Antifragile they can all be destiled to iteration time.

The world is an infinitely complex place. It's very very hard to predict the real results of any action. Because of that, to navigate world it's best to make small steps and collect feedback. The faster you can make these steps, the faster you use a new knowledge, to make new, better steps, which compounds very quickly.

It's a principle so powerful, that taken to extreme allows agents that literally have no understanding of anything, beat everyone.

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

-- Edsger W. Dijkstra

Maybe it's just my experience, but Object-Oriented Programming seems like a default, most common paradigm of software engineering. The one typically thought to students, featured in online material and for some reason, spontaneously applied even by people that didn't intend it.

I know how succumbing it is, and how great of an idea it seems on the surface. It took me years to break its spell, and understand clearly how horrible it is and why. Because of this perspective, I have a strong belief that it's important that people understand what is wrong with OOP, and what they should do instead.

Many people discussed problems with OOP before, and I will provide a list of my favorite articles and videos at the end of this post. Before that, I'd like to give it my own take.

I think I've discovered Rust somewhere around the year 2012. Back then it was much different language than it is today. It had green-threads, @ and ~ were used a lot, and there was even a GC.

Rust caught my attention because I was looking for a language for myself. I always considered myself "a C guy": a bottom-up developer, that first learned machine code, then learned higher level programming. And while C was my language of choice, I couldn't stand it anymore.

I was tired of how difficult it was to write a correct, robust software in C, especially:

• inability to create solid abstractions and nice APIs,
• segfaults, double checking my pointers and general lack of trust in my code,
• make and make-likes building system.

I loved the simplicity and minimalism, I loved the flexibility and control, but I couldn't stand primitivism and lack of modern features.

With time I grew more and more fond of Rust. The language kept evolving in a direction that was my personal sweet spot: a modern C. And at some point I realized I'm in love with Rust. And I still am today, after a couple of years of using it.

Just look at my github profile. It has "Rust" written all over it. And check how my contributions grew since 2013. Rust made me much more productive and enthusiastic about programming.

So let me tell you why is Rust my darling programming language.

Introduction

In this post, I will describe how I refactored quite complicated Rust codebase (rdedup) to optimize performance and utilize 100% of CPU cores.

This will serve as a documentation of rdedup.

Other reasons it might be interesting:

• I explain some details of deduplication in rdedup.
• I show an interesting approach of zero-copy data stream processing in Rust.
• I show how to optimize fsync calls.
• I share tips working on performance-oriented Rust codebase.

TL;DR

The biggest strength of #Go, IMO, was the FAD created by the fact that it is “backed by Google”. That gave Go immediate traction and bootstrapped a decently sized ecosystem. Everybody knows about it, and have a somewhat positive attitude thinking “it’s simple, fast, and easy to learn”.

I enjoy (crude but still) static typing, compiling to native code, and most of all: native-green thread, making Go quite productive for server-side code. I just had to get used to many workarounds for lack of generics, remember about avoid all the Go landmines and ignore poor expressiveness.

My favorite thing about Go, is that it produces static, native binaries. Unlike software written in Python, getting software written in Go to actually run is always painless.

However, overall, Go is a poorly designed language full of painful archaisms. It ignores multiple great ideas from programming languages research and other PL experiences.

“Go’s simplicity is syntactic. The complexity is in semantics and runtime behavior.”

Every time I write code in Go, I get the job done, but I feel deeply disappointed.