I'm really curious how you're dealing with lazy loading. Is the MCP then more like a tool-helper instead of the tools themselves?
I was trying to find out if the MCP has some sort of lazy loading feature/primitive in the works, but there seem to be a lot of disagreements about it.
Intuitively, lazy loading seems to be somewhere between a CLI and vanilla MCP. In the end, it sounds very similar to tiered/ progressive loading similar to images on low bandwidth connections.
I went through the whole article, agreeing to most of it and I was baffled by how skeptical people were in the comments here, with remarks of "follow the money". I didn't read all of it in one shot, but in breaks over the course of 2 days and when I finally got to the last paragraph I understood what people in the comments were on about.
I grew up in a culture where hustle and work was the way out of a terrible life. I've spent several years unlearning that work is not everything while living in Europe. But then, work is not everything and not all that important because some AI agents can do all* of it...
Nice try, but work is still a lot of what I derive meaning from and taking meaning from a person might not have a positive outcome: for the person and for the society.
It's interesting how quickly any discussion about immigrant/expat life in Germany becomes about language. That has to account for something.
After my tenure of 11 years in the country, my impression is that there is a deeper sense of "us" v/s "them"; the language is the most PC way to express it.
If you're in the category of "us" you don't complain about the taxes or things being closed on Sundays, because you're supposed to "understand" that there's a welfare state (which has been a myth for a while now and cracks are showing up since covid). If you're in the "us", you don't claim bureaucracy is treacherous, because the language should have equipped you to fight it. You might be in the "us", if you believe with every bit of your being that rules and regulations is the best way to ensure everyone behaves properly and everything works efficiently.
If you dare challenge (m)any of these and you don't speak German good enough, it's the language. If you speak the language, then you're not "integrated". Maybe that's immigration everywhere, but I feel in Germany, there is a rather narrow band you get to be in "acceptably".
1. Defensiveness; one could describe it as "Stockholm syndrome"
2. What outsiders don't understand about the language thing is that it's not about how much German you need to get along in daily life. That's a similar challenge everywhere in the world.
The crux is that in Germany, correct use of the language is a social status thing, more so than in other places.
Any person, whether German or foreigner, who appears to have difficulty with the language, is easily looked down upon.
The point about correct use being a status thing is such a good point, that you almost never see mentioned, but definitely feel it.
Recently I saw a discussion on Reddit where the author made a minor mistake in the title, that sounds perfectly fine and understandable to me, as a non-native speaker. They used "Mit was" instead of "womit". And more than half the comments were people pointing out the mistake and making fun of the person due to it, rather than engage in the topic that was raised in the first place.
Yes. I don’t want to invalidate people’s bad experiences, but I think it’s a more general problem and not specifically xenophobia. What you describe can happen to anybody!
The same is true for speaking English, which is considered very high status in Germany. If someone has a strong German accent, they’ll be made fun of. I always find this ironic because the people laughing usually don’t speak much better. (Not that I would care; I love people’s accents.)
I have like a dozen different german friends, and it's nothing like you say: everyone in the country curses the bureaucracy, every sunday is like "oh let's quickly get something from the shops oh no wait it's sunday uuuugh"
The taxes seem largely fine relative to the cost of living there, with people living in poorer regions at an advantage even due to the Freibetrag.
Complaining about the bureaucracy is sure everyone's favourite trauma bonding exercise, but I never hear about the solution to it. It's in the political agenda, but the solution is almost always, let's form a committee to decide the agenda of the report about it that would be 1500 pages long and be done in 72 weeks from the day of conclusion of committee's proposal. I feel the issue is the mentality towards problem solving.
Taxes are fine till Herr Merz isn't busy proposing a rug-pull on half of the things you learnt were supported here. Many of our "expat" friends faced this first hand when they lost their Kindergeld unplanned. There was a sudden hue and cry about dependents' insurance being scrapped, not sure of what's latest on it. And the English speaking, tech and finance working expats are not in poorer regions.
I don't know all Germans and maybe it is my circle, but in general I felt if I didn't mirror their hobbies, opinions, and preferences, I wasn't going to have a chance to be on the same table as them or have a heart to heart conversation with them. It's almost like it's too inefficient use of their social time and I'm pretty sure I ain't alone.
One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me.
In my life, I've never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.
Ugh, let's take a step back and make a distinction:
I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.
If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.
I shared my thoughts in the context of someone saying that one should be able to share your line of thinking when asked to. Whether "when one asked to" applies to keystroke by keystroke blockhained versioning isn't my point of discussion.
I get it, that the overall discussion is about DeltaDB. I'd say interesting concept to toy with. I'd pay more attention to "micro commits" as the idea more than the keylogger.
I think a good argument ad absurdum for this is to look at how some recipe sites give the entire genealogical history of the author and an anecdote about how their gammy met Theodore Roosevelt and he stole her pen. Three pages later I discover I need to go to the grocery store because the recipe requires sour cream. And the store is closed so I need a different recipe.
Don't fucking do that. Do something way less than halfway to that line.
OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?
Oh, I *love* those kind of people who take the time to _simplify_ and draw meaningful insights from their first draft. They take the time to ensure that they are not just putting out thoughts for the heck of it. They have gone through a learning journey and they are letting you step on it. They might even make the effort to actually articulate their intuition: "it seemed like a good idea to toy with this, because such and such usually have some connection".
Maybe this is the mathematician's lament rejigged. And I have held it for probably 20 years of my life. I try to do things differently when I write, but I have to say there are enough people who find it sub-standard. It's too imprecise or ambiguous or not clear enough for their taste. They aren't wrong. But I'm not done learning and I start building my thoughts as I go along.
"So I was thinking about #####'s Law this morning, and I realized that #######'s Theorem might apply if we do this and ignore that. Then I went up a blind alley and stopped for coffee and realized I was overcomplicating it, we don't care about negative or imaginary solutions."
They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.
I personally stumble upon many topics where I only care about the what.
In that case all the theory is just a distraction I'm just wading through to get to the point.
If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.
I like this article already because it took me to the goals of Rust for 2026. We use the language in our team, but we haven't needed to go very deep to do the stuff we need. Yet, I really enjoy witnessing the development of a language from ground up with so much community feedback.
I somehow miss noticing that in C++ and I have no idea how it is working in other domains.
My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far?
> My only gripe is that a lot of it is feeling a bit kick-starter-y
IMO the term "project goals" is quite misleading for what this actually is. A project goal is a system for one person (or a small group of people) to express that they'd like to work on something and ask for Rust project volunteers to commit ongoing time and effort to supporting them through code review, answering questions, etc. It doesn't mean that the Rust project itself has set the goal, or even necessarily endorsed it.
So it's not quite right to treat it as a formal roadmap for Rust, just a "there are some contributors interested in working on these areas".
> I somehow miss noticing that in C++ and I have no idea how it is working in other domains.
There seems to be some consensus even within the C++ ISO committee that the evolution process of that language is somewhat broken, mostly due to its size and the way it is organized.
> My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far?
Sadly, this seems to be the way things go once a technology catches on, commercially. Can't blame large donors for sponsoring only the parts they are interested in. Fortunately, considerable funding of TweedeGolf comes from (Dutch) government, I think.
In open source I guess there's two types of work:
1. features
2. maintenance
You can 'sell' new features. They cost money to create, but they solve real problems. Those problems also cost money and if that's more than the cost of creating the feature, companies are willing to put in money (generally).
Maintenance is harder. But there are now some maintainer funds! Like the one from RustNL: https://rustnl.org/maintainers/
These are broader ongoing work and backed by many orgs chipping in a little bit.
Idk if it's the best model, but at least it seems to kinda work
Which is really my issue with this type of legislation. If they had it clearly estimated it would be incredible because you can measure the impact but as it stands it could go either way.
I've never understood how their Brave Credits were supposed to work, but I liked the idea that someone wanted to try out a different model to ads how we know them for about a century.
Ads made magazines, newspaper, news, radio, tv and now internet terrible to be with and I'm honestly curious what can be done to improve the situation.
I'm in a similar camp where I'm stucking to windows for that one software: lightroom classic (or CC as they call it). I'm happy to pay for a legitimate replacement that lets me go Linux native on a laptop. I'm fine even paying for the Adobe Cancellation tax from the money I save not buying Windows.
Yes DaVinci Resolve is supported on Linux. Unfortunately the free version of DaVinci Resolve does not include H.264/H.265/AAC support on Linux due to codec licensing issues though you can transcode it elsewhere first.
Even the paid version doesn't include aac support in Linux so you have to transcode the audio from videos recorded from your phone, with ffmpeg for example, prior to opening them with resolve. That's the biggest inconvenience it has for me in Linux. And plugins can't solve that either, because apparently can only add codecs for encoding, not for decoding.
I'm so eager to try this out today after work. I heard a lot of things about Darktable, but then it didn't really feel like the alternative to Lightroom I'd hope for.
I'll be honest that it was *long ago* that I made that attempt. Plus with the new AI denoise, it seemed even harder to move away from it.
But, if there's a battle-tested, mature UI, I'm up for giving it a shot. I have done no video editing, so no clue how my experience with DaVinci Resolve is going to go. I might give Darktable another go while I'm at it. Just tend to have a bad gut feeling about it.
Some people love tinkering. I do that as my job, so I don't often have the urge to do it when I just want to get shit done.
Darktable has really improved over the last couple years. It used to have some pretty confusing workflows and lots of overlapping modules, but somehow it's been getting cleaned up and polished into something of an intuitive app. It is still different but not so overwhelmed with features that you can't figure it out
When I see someone just throwing a lot of numbers and graphs at me, I see that there are in to win an argument, and not propose an idea.
Of late, I've come across a lot of ideas from Rory Sutherland and my conclusion from listening to his ideas is that there are some people, who're obsessed with numbers, because to them it's a way to find certainty and win arguments. He calls them "Finance People" (him being a Marketing one). Here's an example
"Finance people don’t really want to make the company money over time. They just thrive on certainty and predictability. They try to make the world resemble their fantasy of perfect certainty, perfect quantification, perfect measurement.
Here’s the problem. A cost is really quantifiable and really visible. And if you cut a cost, it delivers predictable gains almost instantaneously."
> Choosing to spend three weeks on a feature that serves 2% of users is a €60,000 decision.
I'd really want to hire the Oracle of a PM/ Analyst that can give me that 2% accurately even 75% of the time, and promise nothing non-linear can come from an exercise.
As with any attempt to become more precise (see software estimation, eg. Mythical Man Month), we've long argued that we are doing it for the side effects (like breaking problems down into smaller, incremental steps).
So when you know that you are spending €60k to directly benefit small number of your users, and understand that this potentially increases your maintenance burden with up to 10 customer issues a quarter requiring 1 bug fix a month, you will want to make sure you are extracting at least equal value in specified gains, and a lot more in unspecified gains (eg. the fact that this serves your 2% of customers might mean that you'll open up to a market where this was a critical need and suddenly you grow by 25% with 22% [27/125] of your users making use of it).
You can plan for some of this, but ultimately when measuring, a lot of it will be throwing things at the wall to see what sticks according to some half-defined version of "success".
But really you conquer a market by having a deep understanding of a particular problem space, a grand vision of how to solve it, and then actually executing on both. Usually, it needs to be a problem you feel yourself to address it best!
None of his math really checks out. Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it. But how much money it can make is potentially unbounded (until it gets replaced).
So investing e.g. 10 million this year to build a product that produces maybe 2 million ARR will have armortized after 5 years if you can reduce engineering spend to zero. You can also use the same crew to build another product instead and repeat that process over and over again. That's why an engineering team is an asset.
It's also a gamble, if you invest 10 million this year and the product doesn't produce any revenue you lost the bet. You can decide to either bet again or lay everyone off.
It is incredibly hard or maybe even impossible to predict if a product or feature will be successful in driving revenue. So all his math is kinda pointless.
> Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it
This feels ludicrously backwards to me, and also contrary to what I've always seen as established wisdom - that most programming is maintenance. (Type `most programming is maintenance` into Google to find page after page of people advancing this thesis.) I suspect we have different ideas of what constitutes "maintenance".
A strict definition would be "the software is shipping but customers have encountered a bug bad enough that we will fix it". Most work is not of this type.
Most work is "the software is shipping but customers really want some new feature". Let us be clear though, even though it often is counted as maintenance, this is adding more features. If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases (once in a while it would because the new feature doesn't fit cleanly into the original architecture in a way that if you had known in advance you would have used a different architecture)
> If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases
In my experience (of primarily web dev), this is not true, and the reasons it is not true are not limited to software architecture conflicts like you describe (although they happen too). Instead the problems I usually encounter are that:
* once you have shipped something and users are relying on it, it limits the decisions you are allowed to make about what features the system should have. You may regret implementing feature X because it precludes more valuable features Y and Z, but now that X is there, the cost of ripping it out is very high due to the backlash it will cause.
* once you have shipped an application, most of the time when you add new features you are probably slightly changing at least some UI, and so you need to think about how that's going to confuse experienced users and how to address that in a way you wouldn't have to when implementing something de novo. For an internal LOB app, that might mean creating announcements and demos and internal trainings that wouldn't be necessary for greenfield work.
* the majority of professional web dev involves systems with databases, and adding features frequently involves database migrations, and sometimes figuring out how to implement those database migrations without losing data or causing downtime is difficult and complicated.
* as web applications grow their userbase, the scale of the business often introduces new problems with software performance, with viability of analysing business-relevant data from the system, or with moderation or customer support tasks associated with the system, and these problems often demand new features to keep the broader business surrounding the software afloat that weren't needed at launch.
* software that has actually launched and become embedded in existing business processes inherently tends to have many more stakeholders in the business that care about it than pre-launch software, and those stakeholders naturally want to get involved in decision-making about their tools, and that creates meeting and communication overhead - sometimes to such a degree that stakeholder management and negotiating buy-in ends up being an order of magnitude more work than actually implementing the damn feature being argued about.
To the extent that the amount of work involved in implementing a new feature is inflated by these kind of factors relative to what would have been involved in doing it de novo, I personally conceive of that as "maintenance" work; and in my experience my work on big teams at successful businesses has on average been inflated severalfold by those factors. (I also count work mandated by legal/compliance considerations that arise only after a successful launch as "maintenance". My rough conception of "software maintenance" is that the delta between "the work involved in building a product de novo with the same customer-pleasing features that ours has" and "the work we actually had to do to incrementally build the product in parallel to it being used" as "maintenance".)
Would most people agree with my broad notion of maintenance? I reckon they roughly would, but it's hard to say since people who talk about maintenance rarely attempt to define it with any precision. You give a precise but extremely narrow definition above. Wikipedia likewise gives a precise but extremely broad definition - that maintenance is "modification of software after delivery", under which definition surely over 99.999% of professional software development labour is expended on maintenance! I guess my definition puts me somewhere in the middle.
As with most things, isn't the truth somewhere in the middle? True cost/value is very hard to calculate, but we could all benefit by trying a bit harder to get closer to it.
It's all too common to frame the tension as binary: bean counters vs pampered artistes. I've seen it many times and it doesn't lead anywhere useful.
Here I think the truth is pretty far to one side. Most engineering teams work at a level of abstraction where revenue attribution is too vague and approximate to produce meaningful numbers. The company shipped 10 major features last quarter and ARR went up $1m across 4 new contracts using all of them; what is the dollar value of Feature #7? Well, each team is going to internally attribute the entire new revenue to themselves, and I don’t know what any other answer could possibly look like.
Even if you could do attribution correctly (I think you can do this partially if you are really diligent about A/B testing), that is still only one input to the equation. The other fact worth considering is the scale factor - if a team develops a widget which has some ARR value today, that same widget has a future ARR value that scales with more product adoption - no additional capital required to capture more marginal value. How do you quantify this? Because it is hard and recursive (knowing how valuable a feature will be in the future means knowing how many users you have in the future which depends on how valuable your features are as well as 100 other factors), we just factor this out and don't attempt to quantify things in dollars and euros.
You’re illustrating one of the points of TFA - a team that is equipped with the right tools to measure feature usage (or reliably correlate it to overall userbase growth, or retention) and hold that against sane guardrail metrics (product and technical) is going to outperform the team that relies on a wizardly individual PM or analyst over the long term making promises over the wall to engineering.
But surely you have to have at least an hypothesis of how software features you develop will increase revenue or decrease costs if you want to have a sustainable company?
I was trying to find out if the MCP has some sort of lazy loading feature/primitive in the works, but there seem to be a lot of disagreements about it.
Intuitively, lazy loading seems to be somewhere between a CLI and vanilla MCP. In the end, it sounds very similar to tiered/ progressive loading similar to images on low bandwidth connections.
reply