Lazy web, fact check on this pls?

https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/aosp_project_is_coming_to_an_end/

If Android is becoming closed-source, do we have an alternative? Or is it seriously about time to look into running Linux on [formerly] Android devices?

I have to confess I like adb and `.apk`-s, and I like how Android approaches isolation between apps. Also, Termux FTW, of course.

If this ecosystem is about to shrink and/or collapse, what should I be on top of to not miss the development of the story?

(I use an iPhone, a Linux laptop, and, consciously, an Android tablet — and, being an open source fan, I'd much prefer to know what Android, if any, is a decent choice these days, assuming I prefer flexibility and customizability and dislike vendor lock-ins.)

Apparently, there's a bar inside a Nordstrom in a shopping mall near me.

First, it's a clever idea. Especially given that it's at the floor with women apparel.

Second, it's now a mini bucket list idea. Meet someone for drinks and suggest Nordstrom as the place. If and when I get the wtf phone call, tell them they should be looking for the women's section.

I just had a profound realization: Junior software developers are here to stay.

Even though much of the code and documentation they produce could, in theory, be accomplished by an advanced Agentic AI or similar technology.

Junior developers are here to stay because the value they bring lies not just in their output, but in their presence. As curious and intellectual human beings, they play an essential role.

Senior engineers tend to open up more effectively, and in a much more focused way, when they are surrounded by intellectually honest, less experienced individuals who are eager to learn.

One might argue that AI could also play this role. After all, we know that AI-based psychologists often outperform human ones in some respects.

However, let me reframe my message. Of course, junior developers learn a great deal from simply being in the same room as more senior engineers who are discussing work matters and making key decisions. But what’s equally important is the contribution a junior developer makes to those senior engineers. Their presence is invaluable!

Even from a purely market-driven perspective, a junior person who is upfront about "being here to learn" adds significant value by shifting the flow of conversation among the more senior people in the room.

This is true even if the junior developer speaks little and later asks questions asynchronously to the relevant people. While that's one possibility, it's rarely the case—junior developers are often driven by curiosity, and they ask plenty of questions. We, the senior engineers, appreciate those questions, and we want more of them.

To summarize more succinctly (though the essence may be lost): a healthy mix of junior developers on a team encourages senior engineers to evolve into not only better practitioners but also evangelists and educators.

Personally, I believe the shortage of skilled tech evangelists and educators is felt far more acutely in the industry than the shortage of principal++ engineers and architects.

Another eye-opener: LLM-generated HTML+JavaScript code is surprisingly similar to what I would write myself.

Part of that is what I would humbly attribute to my prompting style / prompting strategy. But part of it truly is how it reasons about what code need to be written.

Drum rolls: In all my experience with generating HTML+JavaScript with LLMs not a single time it suggested any React!

And no jQuery either.

Which is f'n awesome if you ask me. Since getElementById is all you need (c).

Not sure how to feel about it. Positively, of course. But I almost feel guilty for not giving LLM-generated HTML+JavaScript code more credit before. Because not falling into obvious traps is something that deserves credit when it comes to LLMs.

After all, both ChatGPT and Kaka keep suggesting I use Kafka and Redis where the problem is arguably way too simple for them. Thank god, at least with the "frontend", the sanity is still there.

Ah, this is a good talk. How could I have missed it back in the days?

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

Kudos to Gary! WAT is also great.

Interesting how Elon Musk's true major contribution to humanity so far is Starlink. I'd say Tesla comes second, and SpaceX — third.

Yet, SpaceX is what people are mostly talking about.

On a loosely similar note, I seriously believe AirPods are the most underrated Apple product. It "just works", it's reasonably priced for its quality, and it does not require any ecosystem lock-in; Linux systems pair up just fine with AirPods nowadays.

And yet, people are talking about Apple's VR and whatnot far more than about AirPods.

Both are mysteries to me. Although, realistically, both are just the proof that a) hype beats common sense, and b) hype is hard to predict.

On a serious note, I'd love to know what have we learned up to today with respect to controlling waves of hype. Perhaps Apple wants AirPods to not be talked about? Perhaps Elon wants to distract us from Starlink? PR techniques are relatively cheap compared to marketing budgets of Apple and Elon respectively, so it's entirely plausible to expect eight- or nine-digits dollar figures poured into marketing.

But go figure — how well these marketing techniques work remains a mystery as of today. We only know from real-world evidence that something far more impactful worldwide — namely, election interference — can be executed at far, far lower budgets. Or something such as Big Tobacco "successfully" lobbying the "research" that smoking does not cause lung cancer. From this point on though, cost-effectiveness-wise it's a black hole of information.

So if there is a good book to read about this, give me a hint. I'd be eager to jump on it, especially in light of my upcoming travel that involves long flights. Thanks in advance!

I promise this is not a rant, and apologize in advance if it reads like one.

Looking back, the very fact that it's nearly impossible to make companies allocate resources to software infrastructure projects by employing rational arguments is the largest discovery of my professional life of the past ten years.

I've learned my ways, and I can push a lot of things through, by combining diplomacy, soft skills, cross-team collaboration and other ad-hoc alliances, and ultimately hacking what needs to be hacked overnight at times, despite the team suggesting it's not worth trying.

But the major argument still holds. If you are fresh out of school and you have the expectation that the tech world will appreciate you shipping things the right way, you're up to a journey full of disappointments.

Learn to live when them earlier in your career. Surprisingly, this is better both for your own sanity / mental health, and, perversely, for the companies and projects you choose to be working with.

Although one can argue I took a detour from tech-first companies to product-first companies. Now I'm back to tech-first, because Web3, and the difference is striking. So perhaps the second-order lesson to derive from my career path is that if you, like me, appreciate tech fundamentals more than product shortcuts, then perhaps sticking to tech-first companies would do well for you.

AI has reached the human level of internalizing how much it hates working on the frontend.

On the other hand with Wasm and stuff we may well seriously switch to UI/UX built on top of game engines. Because we finally have the tools to ditch the DOM tree and HTML/CSS once and for all: the AI!

Looks like it's a well-documented deal by today.

My Cursor is in "Auto" mode. Which means the example in my post right before this one could have been Gemini.

If yes, it'd be hilarious. Literally a canonical "Go woke, go broke" story from Google. First its model paints the Founding Fathers in diversity-promoting ways. Now its new model goes out of its way to not offend anyone.

What can I say? In the long run the market wins. And the market is what your customer, not your PR/legal department, is saying. Let's hope Google embraces this simple wisdom, because we are all worse off if they do not.

Incredible how AI-assisted coding does not understand the very basics of source-of-truth.

Sure, I can understand it might not be aware of total vs. partial order — these are tricky concepts.

But when I want the result of some index query to show the time it was added, both absolute and relative to right now ... it's quite obvious that the formatting of time, including locale and time zone and what not, should happen on the client, right?

Well, obvious to any non-imbecile engineer. But apparently not obvious for the AI.

The AI almost started detecting the client's time zone from its HTTP request to "format" the time in their locale, facepalm.

Although, realistically, this likely says a lot more about the quality of code available out there in the wild, than about the quality of first-principles reasoning by the LLMs.

These LLMs should probably put higher weight on the content from my SysDesign Meetup 😇

A somewhat serious question. Although it's semantics, and semantics are never that serious.

I see more and more programming languages where a named field can be initialized from a variable with the same name without having to write this name write. So something like:

{
...
my_id,
...
}


Is equivalent to:

{
...
my_id: my_id,
...
}

This, obviously, makes sense to me.

What I struggle to understand is why not extend this to assume the name of the last dot-notation term.

As in, if I need to initialize my_id: some_source_object.my_id, won't just some_source_object.my_id be unambiguously hinting both the compiler and the reader that the field that is being initialized is my_id?

If we want to be strict we could say this is only legal when there is only one strongly typed field of the respective type.

Although, frankly speaking, one could argue that if there is only one field of the respective type, it should be perfectly legal to even use an expression that evaluates to this type, with no field name whatsoever.

As in, { ..., GetParentId(), ... } may well be parsed as { ..., my_id: GetParentId(), ... }, as long as typing-wise the result of the call to GetParentId() can initialize exactly one specific field, eliminating any and all unambiguity.

This solution will even have the added benefit that if such a syntax is used and then someone else adds another field with the same type, the code will not compile until the author consciously annotates previous use cases — or decide against using the same type more than once. For primary key types that are from different ID universes, personally, I am a big fan of dedicated types — in other words, UserID and GroupID should be different types in my book. So if there is another field of explicit type UserID in the object that describes the user I would like to be notified about this by the compiler. So that I will probably wrap this "other" UserID into some inner struct or what not.

You know many messengers have this "delayed send" option? Or "send when online"?

We need this for Cursor.

I want to queue up a few commands, ideally, say, five. To all begin in new branches, once the current set of tasks is complete.

And then leave for the bathroom, knowing full well my thoughtful piece of work here is done.

Would feel so good to write 💩 code the way it is truly meant to.

I know this might be a risky analogy — one that could easily get me in trouble — but here it goes:

High-agency leaders are just prompt engineers for their teams.

I’ve worked with many founders and high-profile leaders over the years. When results don’t land, it frustrates them deeply. And for good reason — they usually have every reason to believe they’ve been clear: the desired outcome was explained, the steps were mapped out, and the intermediate milestones well-defined. So there’s a fair expectation that the team will follow that path and deliver something close to the intended result.

But — to borrow a modern metaphor — teams often hallucinate.

Instead of delivering what was asked, they sometimes latch onto a nearby idea — something that feels right and is definitely achievable — but ends up quite far from the original goal.

So the leader gets pulled into the weeds. They start inspecting each step of the process, just to be able to say, “Stop here — this isn’t the direction we need.” Their role becomes one of close monitoring, stepping in the moment things begin to drift.

Of course, sometimes more clarification is genuinely needed. No prompt is perfect. But with a re-prompt — and the benefit of shared history — most ambiguity clears up, and the work resumes.

The sad truth? That kind of frustration is eerily familiar. It’s exactly how I feel when my AI coding assistant fails to produce what I had in mind. Except for high-agency leaders, it’s a thousand times worse.

As an engineer and architect, I have the luxury of saying, “Screw it,” and writing the code myself. I can even guide the model to do better next time. The model listens. It learns. It improves — and our little “professional relationship” gets better over time.

Leaders don’t have that option. They can’t do everything alone, and they can’t expect the team to always follow their thought process precisely. And people, unlike models, can walk away — which adds another layer of fragility.

Thankfully, I’ve spent the past decade working with both people and code. So the lesson feels obvious:

As long as I treat people at least as well as I treat my AI tools — assuming they genuinely want to learn and grow — and I’m willing to explain myself again and again, from different angles, the results will eventually follow.

It’s on me to figure out how to work effectively with the team in the long run — just like it’s on me to figure out how to work with AI agents over time.

So, what will this AI hype wave bring us?

On one side, solopreneurs are already building fantastic products at incredible speeds. On the other, the pace at which humanity is accumulating tech debt has never been higher.

Somewhere in between — in that messy, overloaded middle — I believe better leaders will emerge. Forged through this harsh, capitalist, AI-driven “enrichment” process, they’ll be the ones who know how to prompt — not just for delivery, but for growth.

Maybe — hopefully — we won’t be short on founders who are deeply, deliberately good at guiding others while helping them learn.

And maybe, just maybe, that old tongue-in-cheek joke from my NLP- and Chomsky-loving friend — that talking to people is just a form of programming them — is finally becoming true.

I didn’t like the joke back then, and I’m still not fond of it now. But as “programming” shifts from precision to prompts, from deterministic logic to fuzzy iteration, and as more people realize how hard repeated prompting really is, the picture starts to come together.

Humans have always been programming each other — for fun, for value, for growth.

And in the end, aren’t we all just friends with benefits in some grander scheme of things?

As long as those benefits include caring for one another’s emotional states, I’d say it’s a good world to live in.

🦀 Why Rust’s Type System and Macros Are a Superpower for Safe Refactoring

I've been knee-deep in a major refactoring effort lately, and it’s reminded me just how powerful Rust’s type system and macro capabilities really are — especially when dealing with subtle performance and correctness tradeoffs.

One part of the refactoring involves reducing the number of database transactions. In many cases, I can insert data in bulk, which makes a single large transaction much more efficient than a series of smaller ones.

But here's the catch: external API calls are also part of the workflow, and they can be slow. The last thing I want is to lock a DB table inside a transaction while waiting for an HTTP request to return. That’s a classic performance landmine.

In most languages, you’d rely on discipline, code review, and maybe some logging or runtime flags to catch this. And I’ve done exactly that before — in Python, in JavaScript, in Go.

But in Rust, I can go one better: I can encode this rule as a compile-time invariant.

I already have macros like db_transaction!(...) and http_request!(...), which inject file and line info using file!() and line!() to track timing and context. So now, it’s trivial to also enforce context boundaries: set global atomic flags like IS_IN_DB_TRANSACTION or IS_IN_HTTP_REQUEST, and boom — instant feedback if one wraps the other.

But wait: in Rust, I can go further. I can model this constraint in types, so the compiler won’t even let me compile a piece of code that mixes the two improperly. The compiler can literally say: “You’re trying to call an HTTP request from inside a DB transaction context — don't do this.”

This is the kind of guardrail that turns massive refactorings from risky ventures into almost boring routines. And it should work even in async or multi-threaded codebases. (I haven’t tested that myself yet, but the concept should hold.)

Frankly, this kind of safety is one of the reasons I love working in Rust. If I were doing this refactoring in Python, I’d be relying on discipline and logs — and constantly worried I missed something. Worse, AI-assisted refactorings in dynamically typed languages? They will get this wrong at scale. It’s just a matter of time.

Rust’s ability to turn high-level architectural invariants into compiler-enforced contracts is a game-changer. And the fact that modern AI tooling understands Rust? That’s music to my ears.

[ I keep experimenting with writing the post in my own words and then having ChatGPT rephrase it. Still like my phrasing better. But this one got a crab! ]

#Russian — thanks for having me @volyx @maxstrakh!

Чем отличается стартап от бигтеха?

https://youtube.com/shorts/fm4CcxR-xFg?feature=share

The LOL part is that the example I've used is that it indeed is a rare and very useful talent to sometimes break the rules and do something unexpected yet timely.

Such as to deliberately use foul language in a high-profile meeting to amplify the point.

Foul language is literally the example I've used.

And we recorded this a few weeks ago. Far before the f-bomb was dropped by ... well we're not into politics here to cite names.

The more I study monetary systems, the more I converge on one idea:
most “innovations” in money boil down to helping states raise funds for war — quickly.

It’s not really about taxation. Inflation is a hidden tax, but wealthy players know how to dodge it. It’s not truly about control either. If someone wants to hide capital, they do — sanctions never fully work. And for regular folks, cash, cards, and credit work fine across different scales of spending.

What it is about — is the government’s ability to reroute money flows fast, at scale. Historically, this meant one thing: war.

This idea didn’t hit me reading about Bretton-Woods — it hit me reading how the UK funded WWI. Long story short: with lies. War bonds were unpopular, so the government faked mass adoption.

Modern monetary systems preserve this latent capacity: when states need you to stop funding whatever you are now — and start funding something else, say a war — they want the power to force that shift.

Most people don’t want to fund wars. But governments want to keep the option.

In the U.S., blatant rationing might cause backlash — from black markets to Second Amendment reminders. In Europe, things like carbon credits might sneak in for the greater good — but it’s the same logic: rerouting money with coercive tools.

A hard money world — gold, Bitcoin, ETH — makes war harder to fund. That’s good.

But if only some countries go this route, the ones who don’t will have a military advantage.

As a small-l "recovering libertarian", I still favor a non-inflationary system: no hidden taxes, no enforceable constraints, and full financial self-determination.

History shows why — like the U.S. gold ban and forced sales right before devaluation.

So I cheer the Web3 crowd — they built real checks and balances from the bottom up.

But I keep wondering: what happens to the global monetary order when the current one finally collapses?