LinkedIn appears to know something.

These response suggestions are priceless!

Since I'm now actively interested in #Rust, I'll take the liberty to sometimes post n00b questions.

(Because a) this may well help others, and b) I firmly believe asking seemingly innocent questions along the way is about the best way to learn.)

One: Why do we have vec! but not str!? We've got .to_string() and String::from(). Presumably, a cleverly built macro would pick one wisely, and reading str!(...) would be very natural for someone who's used to vec!(...). So, there must be a reason, but I can't comprehend it.

Two: Is there a way to install and pre-build dependencies? I want a build Docker container for my unit tests. Ideally, I'll update it nightly, so that Github actions that run my tests would just docker pull from ghrc the most recent { Rust toolchain + basic pre-cloned and pre-built } modules.

For this "two" to work I need my Dockerfile with the build container to do something like cargo install (?) and cargo prebuild (?) for a bunch of [dependencies] from multiple Cargo.toml files. I've tried that, and Cargo gives me trouble, primarily because it can't "just" download & install packages without the "main binary". I dare say, npm install has never given me this vibe as long as package.json is there. So there absolutely must be something I'm doing wrong.

Hints, anyone? Thanks in advance!

PS: I'm a two-spaces indent guy (and 120 characters line width). Is this totally frowned upon, or would a non-insignificant share of Rust lovers be okay with this?

One thought that keeps coming back to me is why don't we have effective activists for mindful and conscious use of CPU and GPU cycles planet-wide.

For example, who do do have are animal rights activists. They are quite visible. A lot of products, say, cosmetics, are no longer tested on animals. "Fur" and "leather" apparel is increasingly made of, well, mostly fungi.

And this is not to mention vegetarians and vegans, whose ideas are growing in presence, and their presence can be seen and felt, including in measurable numbers.

A couple years back I recall seeing a coordinated campaign arguing that total Bitcoin power consumption is comparable to a mid-sized development country. There was a good counter-argument that Bitcoin should be compared not to an RDBMS that can handle a comparable number of transactions per second, but to the entire global bureaucratic machine that powers cross-continent payments. So, that campaign quietly died out, for better or for worse.

Ah, and the CO2 emission arguments. I remember it how ~15 years ago Google was quite literally forced to release a report that using search daily is equivalent to some one or two extra loads of laundry annually. The narrative of CO2 emission and its connection to technology was quietly dropped too, as evident from the story of Jeff Dean's intern. She was terminated for releasing the paper — which Google had to retract later on — which talked about the environmental impact of ML/AI models. (That's when Jeff Dean lost my respect for not stepping up to protect her, or at least the position of intellectual honesty, btw — it would be a different conversation though.)

One idea I do like is the "challenge" that one is committed to only eating the animals they have slaughtered and cooked themselves. This generally resulted in people who take such a challenge to become vegetarian, or at least pescaterian — which is well within the desired outcomes range, to the best of my understanding.

And here we come to Peloton-like ideas. What if one can pledge to only use the CPU/GPU power they have produced with their own muscles?

You could have a pedal-operated generator at home. Or you could "buy" gym credits, as in, in order to run your home computer, or a laptop, for this many hours per week, you need to [dead]lift this much.

And when you are using CPU- or GPU-intensive services, they are counted extra. Such services would include gaming, and, well, conversational AI agents, such as ChatGPT.

The end goal is to make people more aware of how much power, in raw kilowatt-hours, is being wasted by our civilization daily.

Personally, I'd love to see a hashtag, something along the lines of "CPU cycles matter". And, while we're on this note: quite a lion share of the web is run on PHP; can we please stop this madness some time soon?

Obviously, this is the nerd in me speaking. There's neither social and political will, nor the need to introduce measures such as what I'm outlining above. However, the geek in me would be quite happy if we do.

After all, don't we all want performant, reliable, non-bloated software services instead of, well, today's state of the art?

This post will have two stories and then an unexpected conclusion.

Story one. When I moved to Switzerland, and bought a car there, I learned that as an Eastern European I would need to pay more for insurance. Since, based on the statistics acquired in the counter, Eastern Europeans make worse accidents.

This made perfect sense to me. For as long as I lived in Switzerland. And it never occurred to me that such a policy violates any rights of yours truly, or is anyhow oppressive.

Story two. While I understand many programing languages, I am now learning Rust. Naturally, as a C++ guy, I am well aware of all the holy wars surrounding the language.

My personal take is that the average level of a software engineer is generally mediocre. Therefore, counting on great products to be shipped by great teams is optimistic at best. Programming languages have to be safe enough so that an inexperienced developer can not accidentally commit code that breaks the software for millions of users.

Therefore, languages that promote defensive coding are a big deal in my book. And, while I believe that personally I am capable of using C++ the right way, it just is not the right tool for new projects in 2025. Since performance is high on my list, I'm not looking into Java or Golang, and thus Rust is my next tool of choice.

Now to the unexpected conclusion part.

Some ten years ago in California I was seriously accused of being an X-ist, as I argued that it is only rational that the "where one is from" signal is used as an input to calculate insurance premiums. My conversation partner sincerely believed that I do not respect our Southern neighbors by merely assuming, in my head, that it is remotely possible that the "country of origin" signal can be used to determine how much one should pay for their insurance.

(Ironic, isn’t it, as I was among the first to argue that if we truly want to help minorities in tech in the Bay Area, we should start by making it easier to be a Mexican in IT, not to be a Woman in IT. But I digress.)

Logically, from first principles, I cannot possibly be X-ist on the subject. Since I was on the receiving end of such treatment for several years, and I never had any moral issues with that.

Nonetheless, my otherwise intelligent conversation partner was blinded by the fact that I was, in their mind, "repeating right-wing propaganda".

Similar sentiment applies to Rust story. As a fan of Haskell and of strong typing, when it comes to the C vs. Rust debate, the topic of memory safety comes up often. "Thanks to" the absence of memory safety, we are literally still discovering bugs and security holes in code written decades ago.

Just because C and C++ are designed so that being able to shoot oneself in the foot is a privilege to honor, not an issue to collectively work around.

You might see where I am coming with this. In certain C and C++ circles, casually bringing up memory safety as the term is viewed as "propaganda", as such "framing" brings the "narrative" from "the other side" into the conversation.

Hear me out, I have an important point to make. Labeling something as a 'narrative" or "propaganda" is not necessarily bad. Narratives are, in fact, often the best way to cut to the point. And, propaganda, of course, is about finding and amplifying the narratives that stick.

No narrative can be nuanced. On most important topics, the true outlook of the world is far richer, and boxing your conversation partner down to some narrative would generally be a straw-man, not a steel-man argument.

So ... don't pigeonhole people maybe?

Personally, I would even go further and argue that being able to clearly articulate the area of disagreement before diving into nuances is a great way to conduct the conversation.

Too bad that many otherwise deep people are easily blinded by narratives these days. If anything, I wish more of us could let go of stereotypes and talk about potentially uncomfortable topics with an open mind. So that the goal of getting to the truth, not defending one's ego and identity, is ultimately reached.

The lightning talks event from this week's SysDesignMeetup is out: https://tinyurl.com/sdm-lightningtalks-feb2025

It has three lightning talks.

• By David Archuleta, on Wasm and perfomant code in both the browser and node.js,

• By me, on Source-of-Truth, and how it relates to "learning to count", and

• By Alex Kantsevoi, on using etcd to perform leader elections and achieve consensus.

I'd say it's good content, although I'm still getting used to using the Mac and recording the screen from it. Enjoy!

Is there some offline downloadable version of Leetcode et. al.? Or maybe some other online judge?

Basically, since I'm learning Rust, I'd love to solve a ~hundred easy-to-medium problems. That's my way of making sure I understand the basics of the language well enough to proceed.

Since I'm a vim user who hates inefficiency, going back and forth to the Web interface is just too much trouble.

What I'd love to have is a downloadable package (or a repo to clone) with problem statements, stubs, test data + golden results, and some scripts to check the results.

So that my flow of mastering the language is a) totally uninterrupted, and b) totally offline.

What's the way to go?

Yes: LLMs objectively are quite powerful, and I figured making them part of my [neo-]vim coding flow would be a good idea. Ollama is good enough at pulling and running models.

But: I'm a big fan of local setups that do not require connectivity, send no data "outside", and are 100% usable when I'm offline. And the 42GB llama3.3 generates approximately one character per minute on my quite powerful MacBook Pro.

Here's my take on "AI taking over software engineering jobs".

I'm not even interested in expanding on that "AI can not present its case strongly enough", or that "AI can only replace mediocre engineers".

My view is that to talk about "taking over jobs" we need to first understand what does "the job" even mean.

The entire software engineering industry, monetarily speaking, is a huge bubble. It's a collection of bullshit jobs, speaking in Graeber's terms. But somehow this is the state of the art we keep living in.

We have amazing programming languages that can eliminate the vast majority of bugs. We do not code in them. We have techniques for mathematically proving the correctness of our algorithms. We hardly use them. This was and remains true for well over twenty years, and this does appear to be changing.

If you look at what the market demands talent-wise, it's still almost exclusively positions for the skills and the languages that the AI can, presumably, take over as of last year. Is hiring humans for these positions cost-ineffective? Of course. But somehow cost-effectiveness, statistically, does not play the role here.

Moreover, quite a few jobs that technology should have replaced a while back are still here. Why do we have to file our taxes? Why do airports and car rentals have check-in counters? How come ordering a ride still requires phone calls in quite a few places? Can we stop stamping passports while crossing borders, for God's sake?

Furthermore, even what could work well by today evidently does not work well at all. Even the most basic apps are broken in ways that no decent engineer would allow to make it to production.

And we seem to be content with the above.

So my position is:

1) If, less likely, software development would become a less bullshit-by-design space, I, for one, would embrace such future. Even if this makes me unemployed and unemployable. Although the latter is highly unlikely by my estimate.

2) If, more likely, the de-bullshitification of the planet will not begin to happen in the next several dozen years, then the now-glorified "AI coding assistant" is just nothing more than autocomplete enhanced by silly reference-checker against StackOverflow et. al.

Either way. If you're a junior, do not, I repeat, do not enter the field of software engineering unless you truly love to code and to design systems based on code. This was and remains true. And if you're not a junior and/or if you love what The Code can do, keep calm and carry on.

If anything, bootcamps will finally die out. Because "to break into tech" is no longer something one could reasonably count on improving their life permanently and for good. Phew, finally decent engineers around, amen.

I have a confession to make.

I am that guy who says "please" to the LLMs.

Not because I hope to increase my chance to be spared on an off chance the AI will indeed take over the world in my lifetime.

(Although these (both) would be somewhat nice.)

But because I genuinely believe that soft skills are the natural extension of hard skills. I genuinely believe that getting things done often, far too often, implies setting the team for success, which is far more "human work" than "computer work". And I believe having the proper mindset helps quite a bit.

And saying please or thank you is zero cost. In fact, it is literally negative cost. It's polite to begin with, it helps the other person to feel good, it helps their self-confidence and hormonal balance, it increases the overall productivity and output, and, most importantly, it makes everyone feel better off about both the process *and* the result.

So, I try to not overdo "thank you"-s, but giving credit where credit is due it just a great habit to develop and to keep reinforcing in myself.

Seen in this light, if the LLM's response makes sense to me, and if it genuinely deserves a compliment, I'd definitely give it one.

And my humble opinion is that the world would be better off if more of us would act this way.

PS: It's a bit like recycling.

I am well aware that in far too many cases caring too much about which bin to toss my now-empty food container is a waste of time. I am quite vocal about this waste of time if and when asked (and sometimes proactively if I'm too pissed off about related or unrelated things).

But I'm also quite invested into making sure I understand the local custom of where these food waste containers go to. Since I firmly believe the value of these small conversations is far too positive, compared to the even-potentially-negative value of actually making sure this damn container makes it into the "right" bin.

So I do my best. Since it's a no-brainer positive sum play. Both with recycling and with saying "thank you" to the LLM.

Me learning Rust!

One thing that I’ve realized when I was today years old is that otherwise intelligent people can say “no, this is nor correct” about something that is 100% factually correct.

Even if you ask them explicitly to forget emotions and focus on facts. The facts are A, B. C, right? Well, not so easy.

Obviously, if the person respects you to keep engaging in the conversation for as long as needed (and/or if they have the intellectual integrity to want to know the truth), you’d get to them saying some “well, yes, A, B, and C are the facts, and I never denied this”.

But somehow getting to this point requires time and energy and commitment.

What’s new to me is that such behavior is not something exhibited mostly or exclusively by people incapable of reasoning. Quite intelligent folks can easily fall into this trap. Sheldon Coopers, like me, are rare.

For me personally it’s important to first and foremost even up the field by saying back that “the facts are right”. If I don’t do so right away, this is how my response would begin if you ask me again to clarify. To me, any intellectual conversation has to begin from establishing the common ground, and agreeing on facts is by far the best way to make it so.

Since this week, my understanding of the world has changed. Some of the better people do have mental blocks and/or other reasons to refuse to accept certain facts for what they are. And, evidently, this is not a disqualifier from being a smart and reasonable person overall.

(Much as I would love it to be. I’d love it for people to be taught from early age that facts matter. And I’d love it if our society was structured such that the people who make it to bigger decision-making positions are facts first, persuasion later. Alas, I believe every politician should be subject to AMA-style cross-examination on a regular basis, where they can not dodge the questions they do not like, and where they are held accountable for spreading lies and misinformation. But I digress.)

Although, oh the other hand, I’m old enough and I’ve seen enough. Perhaps I should just spend less time among people who are not willing to accept facts. Especially if it takes more than I’m willing to give it for them to establish this in our conversation.

So, basically, when dealing with me please either be comfortable with stating the facts up front, or be an interesting enough conversation partner so that we mutually enjoy the process of distilling these facts.

PS: I also have some example reference cases of when forcing the other side to accept the facts first can be legitimately considered propaganda or influence or otherwise shady. And yes, I agree it’s important to not lead with cold facts in such a situation, since it would just not make anything better. However, in my book it’s still essential that we do agree on facts up front. Openings such as “let’s look at facts first, regardless of our emotional take on them” and “let’s separate facts from judgements and focus on the facts at first” do help.

I asked ChatGPT to generate an image of how Meganezia could look like, after priming it to think about Alex Rozoff and his books.

Me like!

If you don't read Russian, a couple years back we translated — with author's blessing! — one of his books into English.

My take was and remains: Rozoff does not write well, as in, his novels are not something you can submerge yourself in, and then want to recommend to everyone. In style, he is far closer to Ayn Rand than to, say, Malcolm Gladwell. The ideas are brave and provocative though.

If you, like me, feel like the world we live in sucks at personal liberties and bureaucracy and overall non-positive-sum-ness, his books serve as decent self-therapy.

And — the picture! What's there not to like!

A good analogy to illustrate my take on AI-assisted coding is car & driver safety.

Here's a good framework I heard of a while back. While driving, the situation can be loosely mapped into four buckets depending on its safety.

Level 1: Safe. The driver is unlikely to cause an accident even if they are not paying much attention to the road.

Level 2: Moderately safe. If the driver is not paying attention, and/or if they commit a major blunder, things can get ugly. In the vast majority of cases though, no danger in sight.

Level 3: Elevated risk levels. A focused driver with reasonable skills who is not panicking will likely do the right thing. An incident is far more likely than with Level 2 though.

Level 4: Critical driving conditions. A truly professional driver may be able to utilize their skills to make the situation less catastrophic.

The point is that driving safety mechanisms are designed to turn Level 3 situations into Level 2 situations.

In other words, it is acceptable, and even expected, that a decent driving safety measure will in fact make an experienced driver less effective in a critical situation. On an average, as a society we accept this status quo. In fact, we embrace it, with regulations, requirements, etc. Because for a single instance of where those safety mechanisms deal more harm than good there are literally thousands, if not more, instances of where they prevented an accident.

This is exactly what is going on with AI-assisted coding!

Level 3: Help center a <div> for a certain browser in a certain version of a certain framework. Automation can help a great deal, except the very few cases where you are an expert and you are extremely aware of what you are doing in this particular situation. So, AI assistants can turn this Level 3 problem into a Level 2 problem, where you "just" copy-paste some snippet, and it "just" works.

Level 4: Low-level kernel programming, consensus engines, memory-allocation-heavy operations, or dealing with advanced type systems. Well, you're on your own.

When we're in Level 4 territory, the "AI" would only make it worse. You're on a race track; you need a race car, not a comfortable sedan designed for an average, or even a below-average driver.

The true question is how much of our coding is Level 2 vs. Level 3 vs. Level 4. The answer probably seems to be "not much". So, any AI-assisted coding, including vibe coding, will definitely become widespread, much like a lot of people indeed do text while driving.

And we will get used to vibe-only "coders", whether we like it or not.

Will it change our industry? Of course it will. Personally, I'm looking forward to the future where the only non-expert human engineers are the people who truly want to become experts, and are working hard to make it. Everybody else — thanks for all the fish!

Is there a consensus on how to sign requests and persisted data?

To my surprise, there's no widespread standard. So here's what I came up with after thinking about it overnight.

It's a JSON with four keys: "owner", "datum", "proof", "extra". Of nice five characters each.

Owner: The public key of the signer, and also the identity of the signer.

Datum: The base64-encoded payload.

Proof: The signature for this base64-encode string.

Extra: Whatever extra data that may accompany the Datum for debug / journaling reasons, but should not be part of what is signed. (Such as the build version, IP address, OS/architecture of the signer, etc.)

This protocol makes it very clear what is signed. Also, discarding unsigned requests requires no knowledge whatsoever about what is being signed, so a trivial piece of logic on the side of the proxy / service mesh / load balancer can do this.

With this top-level standard established, we can talk about more tailored "inner" schema agreements. Such that if the base64-encoded payload is a protocol buffer in its binary format, it should have the field of type string, tag one, which is the Owner public key itself. Again, can be verified by the intermediate proxy.

This inner-level agreement allows for a trivial, generic, company-wide and language-agnostic API contract: a single function called "sign". Required the signer (private key, plus optionally the pubic key, since it's derivable from the private key), the datum, and optional extra.

I'm sure I've reinvented the wheel here. What are some industry-standard time-tested best practices to look into? Thx!

Perversely, I'm delighted to see this output.

First, it's exactly the proof that brainz are still required to write code. At least if you want it to be high-performance low-latency code.

Second, it illustrates how Rust is not easier that C++ when it comes to being able to read and understand error messages. (For C++ folks, loosely speaking, this message is literally [[nodiscard]] not satisfied; must explicitly ignore the return value of '.set(...).await?'.)

Third, it's a perfect anti-vibe-coding example. Sure, some AI models would be able to "fix" it. But by now I’m quite convinced that if and when coding in "vibe mode", one is literally three or four steps away from the code that is unsalvageable / irredeemable / deplorable / you name it.

Perhaps it's a nerd-masochist in me speaking, but I'm glad I'm learning Rust. And my fears that knowing the computer and its language inside out would be less important over time are not materializing. Understanding what's going on behind the scenes keeps proving to be important.

I have seen the future without Rust and I do not like it =)

Another simple yet serious question: How to best live with both a Mac and an Ubuntu laptop?

I have an external non-Mac keyboard. The home/end keys are broken, but, besides them, I mostly got used to "Win+C" / "Win+V". Also, my fingers are slowly learning to alternate seamlessly between two laptop keyboards, which is nice.

KVM is effectively in place. It is not, but I use a single USB-C cable to plug it into either laptop. Slowly becoming comfortable with this setup.

Also, my keyboard does have the "Win/Mac" switch, although I'm not sure it does any good.

Perhaps there exists an external keyboard that is worth looking into? Such that it'd be configurable to work the same way for Ubuntu and for the Mac? Maybe it can/should be a Mac keyboard?

Or perhaps there are Ubuntu key bindings that match Mac's? Some dotfile would be much appreciated.

Last but not least: what about the touchpad? The one on a Mac is certainly wonderful. If my external keyboard would come with a touchpad, I'd definitely want it to be a Mac one. Does it work well with Ubuntu though?

My personal take: Much like I'm committed to Rust, I am almost committed to living a nonzero part of my life with a Mac, including coding on it.

So, if a decent setup with an external keyboard that works well with both Mac and Ubuntu exists, I must try it. Otherwise, another half a year, and my fingers will get used to both =)

Introspection time.

I wanted to get intimately familiar with the Web3 space for a few years already. This plan materialized in the second half of the last year.

TL;DR of my adjusted mental model so far.

1. Technologically, Web3 is extremely mature.

Say what you want about the wave of scams and what not, it would not change hard facts. And the hard facts are: the tooling and the ecosystem of Web3 is extremely mature.

I had low expectations, and I assumed most projects and most engineers would be fluff, to say the least. I was wrong. The fraction of fluff in, say, AI/ML, LLMs/transformers, and even in cloud engineering is substantially higher.

Besides, unironically, my core "hard tech" career of the past 5+ years has to do with event sourcing, distributed consensus, CDC, large-scale correctness of data, finding best ways to abide by regulatory standards, etc. And, as quite a pleasant surprise, I am happy to report that the Web3 space (and specifically the Substrate framework I have looked into) is literally better suited to support these requirements compared to "old-school" tech shops.

2. Rust is good.

Again, take whatever position you want, but if you think Rust is a "young", "unstable" language that is "still in beta", I have bad news for you.

The reality will prevail, and the reality is that Rust is good enough to use.
Sure, it had a kick start. But I'd say in the last 5+ years Rust has matured about as much as C++ has from ... say, 2003 to 2023. As in, 4x faster. And thanks to no need to maintain backwards compatibility, Rust is a mature, shiny, mostly legacy-free tool ready to use.

One would be correct to point out that Rust is not the only game in town. But the other languages I looked into did not make the same choices. And for the domain I care about the most (high performance, low latency, durability, code correctness, maintainability by engineers of various levels, strong and well-thought-of type system), Rust is clearly ahead of the game.

If you think C/C++ is forever, I'd love to bet against you, really. Rust is coming to the Linux kernel. Binutils already have Rust implementations. If anything, I'd love to use a Rust-built kernel, with Rust-built sshd, Rust-built web servers, Rust-built loggers and file system, etc. Sure, Linux will live on — much like BSD does today — but it will either adapt or get replaced. And I'm talking about both server and desktop (and laptop) use cases.

Also, Kafka is almost one and a half million lines of code. For God's sake. I wonder how much smaller RedPanda is. And I'd love to see a Rust alternative. Bet you it's going to be better. The very architecture and the very protocol of Kafka is not something worthy of reproducing, but that's a different conversation.

~ ~ ~

To recap, the future of tech is always hard to predict. Decentralization is subject to too much scrutiny, and it is affected by non-tech global trends far too much.

Nonetheless, maturity-wise, if I keep architecting systems and writing code, I'm happy with Rust so far and I'm happy with the state of the art of decentralization so far.

Let's keep the momentum going. So that we have some sanity in the increasingly insane world where everybody and their f*cking uncle is building a yet another agentic AI framework =)