HN user

YuukiRey

796 karma
Posts21
Comments133
View on HN
Superpowers 6 20 days ago

I can't believe that a bunch of Markdown files now comes with a "Commercial Services" section. It feels like an elaborate GitHub Karma farm. Everything has to be commercialized and advertised.

I’m surprised by the somewhat positive comments. I thought this was just a chance for insider trading without repercussions. If I work at $corp and know the hotly anticipated whatever is announced tomorrow, I can finally cash in on that knowledge.

And the people losing their life savings on gambling now have one more tool.

But what do I know. I’m probably oblivious to what greatness those Truth Engines will enable.

Steam Machine 8 months ago

The Steam Machine is smaller than any case that would be considered mainstream in the small form factor community, at least to my knowledge. The FormD T1 is around 10L for example, and would look almost comically large compared to the Steam Machine.

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.

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.

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.

I should have been more specific here indeed. I meant more library or framework, not technology in the broader sense. My apologies.

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.