2
points
YuukiRey
Joined 789 karma
- Are we looking at different charts? What I see right now on a 5 day view is:
- Nvidia -11%
- Palantir -16%
- Oracle -11%
- Meta -5%
With some very quick and extremely cursory napkin maths I do get in the 800 billion range, which the original article mentioned. I guess the linked article rounded it up to make it more sensational.
- > I have seen what people are capable of doing when their tools get out of the way, and they are free to just create. This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
I think this is a fallacy. If you approach the question of how these people achieve the things they do with a bias towards tooling then you'll come to the conclusion that it plays a big role in their success.
In reality, many of these folks start with a very strong drive to achieve something and then the rest sort of follows. If you want to be a world class musician, start practicing an instrument. Ideally fall in love with music. The rigorous and meticulous practice routine comes later.
In other words: you can have the world's best tooling that gets out of the way, but you're still as unmotivated to do anything as before.
I think it's a cool idea and it sounds like a fun and creative endeavor. I don't want to talk it down. But I also wouldn't want folks to get the, in my opinion, misguided impression that "tooling -> success" is the correct order.
- I find it a bit strange when people write about themselves in third person on their own website (see footer and about).
Anyway, the article seems very Amazon centric since I have no idea what an L6 or an L7 is. I get that they’re career ladder steps but that’s it.
And having testimonials about yourself on your own website…
The whole website feels like I clicked on an Ad for a person.
- This is a really insightful post. I created a Vim color scheme that uses even fewer colors than his but I didn’t realize that you might want to express nesting through varying lightness levels. I also didn’t realize that using HSLuv and making all lightness uniform might actually hurt the scheme.
- I can highly recommend a recent series of podcasts by The Economist on precisely this topic https://www.economist.com/podcasts/2025/02/06/1-pigs-in-a-ba...
- Okay fair point, the various *Scripts predates my entry into the developer workforce somewhat.
But just in the repos at work I deal with: yarn, npm, pnpm, bun, NextJS, biome, Prettier, ESlint, Vite, Vitest, Jest, Turbopack and esbuild. At least those are the things I remember right now. They all have their idiosyncracies and issues. They all require learning slightly different configs. Nothing is compatible with anything else. I can't take one library and `npm link` it into another because their toolchains are completely different. Then you have the whole topic of exporting TS vs. JS, different module types, module resolution, custom module resolution rules to accomodate for how some outdated plugin somewhere works.
And this really is just the tip of the iceberg.
I wish these folks the best and I hope I'm wrong and in a few years all of this is replaced by `vite lint` and `vite build`. But my past experience tells me that I'll simple add one more word to this list.
- Lets assume Vite+ ends up working super well. Then projects using it could very well end up being a delight to work with. But that's a big IF. They'd have to resist the urge to integrate with the many other parts of JS and basically say no to a lot of requests.
But many projects won't adopt it. There are so many competitors all with their own little ecosystems. So in the end, I'll still have to fix all the issues I fix right now PLUS the issues that Vite+ will add on its own.
The only chance I see for something like this actually working is if something like Node/NPM decided to add a default formatter, linter, and so on.
- No it's not out of date. It's very much the reality. Every new tool is just one more thing added on top. When I have to do something in a JS/TS repo at work it's always a surprise which epoch of JS hype stuff I find. Today I fix ESLint warnings, tomorrow it's Biome errors, then I need to figure out how to override dependencies in pnpm, but oh no there's a some bug in Bun now. Did I forget the 10249120491412e12 config options of Jest? Ah no wait, this one is Vitest.
For NextJS, do you remember the runtime used for middlewares? What was this swc thing again?
It never ends. Every year new things are added and they never really replace anything, it's just one more thing to learn and maintain.
If every technology causes exactly 1 issue per week then you quickly spend 50% of your time fixing bugs that have absolutely zero to do with what your company is actually doing.
---- EDIT
And it doesn't even stop at issues. Every one of those technologies regularly goes through breaking changes. In the process, plugins are deprecated, new ones have completely different APIs. You want to upgrade one thing for a security fix, then you're forced to upgrade 10 other things and it spirals out of control and you've spent entire work days just sifting through change logs to change `excludeFile` to `excludedFile` to `includeGlob` to `fileFilter` to `streamBouncer` to I don't know what.
- It's hard for me to give a blanket answer to this. I tend to mostly work on services that offer GraphQL APIs these days, and not so much on client side rendering. For APIs I stick with Go because it's what I'm most familiar with. But I'd also be happy to work on a Django or FastAPI service. Anything is fine really, as long as it's mostly boring technology.
If I had to create something that has a UI I'd just go with a bog standard server rendered multi page app, built using really boring technology as well. If you like Javascript and friends, go with Express. Nowadays you can run Typescript files directly and the built-in test runner is quite capable.
If a single page application makes sense, then go with vanilla React. For a highly interactive application that's potentially behind a log in anyway, you probably don't need React Server Components.
- I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts.
Next.js is easily the worst technology I've ever used.
- I share examples of LLM fails on our company Slack and every week LLMs do the opposite of what I tell them.
I say capture logs without overriding console methods -> they override console methods.
YOU ARE NOT ALLOWED TO CHANGE THE TESTS -> test changed
Or they insert various sleep calls into a test to work around race conditions.
This is all from Claude Sonnet 4.
- 99% of the time it is consumption without ever utilizing the knowledge for any creative endeavor . And without application the knowledge will quickly fade and you’ll find yourself watching the same 10min video on statistics 101 for the 3rd time, because you keep forgetting.
It’s still mindless consumption if you don’t interact with the material in any meaningful way (follow up questions, application, try to refute it, evaluate a hypothesis you had before watching it, …)
- I suggest taking a closer look at section 5 ("V. Shifting Priorities and Social Influences"), which starts on page 24 for alternative explanations.
The preceding section does mention studies that show a cause and effect relationship between e.g., income and fertility, but the effect is surprisingly small. The authors conclude the section with:
> “Pro-natal incentives do work: more money does yield more babies… But it takes a lot of money. Truth be told, trying to boost birth rates to replacement rate purely through cash incentives is prohibitively costly.”
- I don't think that's the implication.
So far I've only skimmed the paper, but here's an interesting quote:
> Among respondents of a 2018 survey conducted for the New York Times, the desire to “have more leisure time” is offered as the leading reason for not having children among adults who...
If your assumption is that economic reasons cause the decline in fertility rates, it's tempting (and natural!) to view every alternative explanation in the context of economics. In other words: all alternative explanations are symptoms of economic problems, so the root cause remains money.
But quotes like this can also be interpreted as people changing their priorities regardless of income and worries about housing. Maybe, freed of traditional role models, people would rather watch Netflix all day long in their single person household.
- Fascinating topic. I personally suspect that it has more to do with attitude and life style priorities rather than economics. But I remember reading a very recent article in the Economist that argued that birth rates declined mostly in low income families, which would contradict that.
> Underpinning these policies is an assumption that poorer women are more likely to respond to incentives to have more children. Indeed, their fertility rates do seem more elastic than those of professional women. Whereas the fertility rates of older, college-educated women have remained fairly steady over the past six decades, most of the collapse in fertility in America and Britain since 1980 stems from younger and poorer women having fewer children, particularly from unplanned pregnancies.
https://www.economist.com/leaders/2025/06/19/why-magas-pro-n...
Just like with many of these topics, most sources seem to contradict each other.
- 2 points
- Adding fuel to the fire. I'm extremely disappointed to see such an inflammatory article on fly.io. I wouldn't want this on my personal blog, let alone on my employers, but I guess they're fine with it.
I've been using Zed and Claude Sonnet 4 (and sometimes trying Opus) heavily over the past weeks. For small edits where I have lots of unit tests, the results were great. So great that they worry me with regards to job security. For exploring a new programming domain it was also somewhat useful. I work a lot with the Typescript compiler API right now, and it has almost no documentation. Since the AI can see into every GitHub repository out there, it's much better, and more efficient, at learning APIs based on code from other folks. On the other hand it means I don't do that job, and I am forced to rely 100% on how the AI presents the Typescript compiler API to me. Are there better methods I could use? Who knows.
Where it's abysmal is code architecture. Sometimes it's almost comical: it adds an if statement to handle one highly specific edge case in a program that only makes sense if it solves the general case. This didn't happen often thought.
The hardest part was to force it to reuse existing code from the same file. My use case is transforming a Typescript AST into a GraphQL AST. The code is one big switch statement with lots of recursive calls. The AI would often add 300 lines of code that duplicate some logic which already exists somewhere else.
In the end I rewrote the whole thing from scratch. At around 900 lines of code the AI was starting to really struggle. When I wanted to take over, I realized that I didn't have the in-depth knowledge to do so. And trying to understand the code the AI had written proved futile.
Ultimately that's on me, I should have been more diligent reviewing the dozens of 300 line of code changes the AI throws at me over the course of a day. But I wasn't, because reviewing is really, really hard. For many reasons. And AI makes it even harder.
Am I therefore nuts? I find this whole article extremely one sided. Surely, based on the sheer amount of both positive and negative press, the answer is somewhere in the middle.
- I don’t see the similarity. Since hooks aren’t actually passed to, or injected into components, there’s no way to evaluate the same hooks in different ways.
I can’t have a hook that talks to a real API in one environment but to a fake one in another. I’d have to use Jest style mocking, which is more like monkey patching.
From the point of view of a React end user, there’s also no list of effects that I can access. I can’t see which effects or hooks a component carries around, which ones weren’t yet evaluated, and so on.
And enthusiast cases like this are often quite expensive and not easy to get. Then you need to think about thermals, and find hardware that actually fits.
You can approach it form another angle and treat it more like a NUC and get a SoC but then you're probably not going to get close in terms of gaming performance.
So long story short: I disagree that it would be straight forward to build something like this on your own, at the same price point.