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.
Read Bootstrapping Urbit from Ethereum for details.
I find #Urbit to be one of the most interesting tech projects around and I'm happy to see another milestone. I'm not a great fan of Ethereum, but I guess for this application, it's well suited.
One of the things I love about Rust is its ownership-system. The ability to express a resource changing ownership (moving)
is a huge enabler, eg. allowing to express APIs that are impossible to misuse.
I've just a found a good example: Bulletproofs are implemented in Rust, and are using move semantics to enforce secure usage.
As a side-note: it looks to me like Rust has already become a de facto standard for #crypto world infrastructure.
#programming #crypto
Turns out the platform I'm hosting this blog on supports ActivityPub, so you should be able to subscribe to updates by just adding dpc@dpc.pw.
#test
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.
tmux-session.sh:
#!/bin/bash
# Reattach to (or spawn new if not existing) tmux session
# tmux session <session_name> [ <session_directory> ]
export STY="tmux-$1"
RC=".tmux"
if [ ! -z "$2" ]; then
RC="$2/$RC"
fi
RC="$(readlink -f "$RC")"
if ! tmux has-session -t "$1" 2>/dev/null ; then
if [ ! -z "$RC" -a -f "$RC" ] ; then
tmux new-session -d -s "$1" "tmux move-window -t 9; exec tmux source-file \"$RC\""
else
tmux new-session -d -s "$1"
fi
fi
exec tmux attach-session -t "$1"
tmux-here.sh:
#!/bin/bash
# Spawn tmux session in current directory
# use path's sha256 hash as session name
exec "$HOME/bin/tmux-session" "$(echo "$PWD" | sha256sum | awk '{ print $1 }')" "$PWD"
#shell #tool
Having a lot of RAM nowadays is relatively cheap and Linux can make a good use of it. With tools like preload most of Linux distributions are trying to proactively read things that you might want to use soon.
However if your desktop have a ridiculous amount of memory (mine has 32GB) it may take ages for these tools to make use of all that memory. And why would you pay for it and then let it just sit idle instead of working for you?
The thing is: you can do much better, because you know what you are going to use in the future.
So, as always, let’s write a tiny script under the name precache.
#!/bin/sh
exec nice -n 20 ionice -c 3 find "${1:-.}" -xdev -type f \
-exec nice -n 20 ionice -c 3 cat '{}' \; > /dev/null
Personally I keep it as $HOME/bin/precache.