Hacker News Reader

wellpaston SQLite (with WAL) doesn't do `fsync` on each commit under default settings

Of course it will because same programmers don’t ack their customers until their (distributed, replicated) db says ack.

wellpaston SQLite (with WAL) doesn't do `fsync` on each commit under default settings

I knew I shouldn’t have said crypto, but it is why I said queued. I knew a pedant was going to nitpick. Probably subconsciously was inviting it. I think my point still stands.

wellpaston SQLite (with WAL) doesn't do `fsync` on each commit under default settings

Wouldn’t it depend on use case?

If the app confirms to me my crypto transaction has been reliably queued, I probably don’t want to hear that it was unqueued because a node using SQLite in the cluster had died at an inconvenient specific time.

wellpaston Architecting large software projects [video]

I’m just making the point that most software dev work is not novel.

You’re either making a productivity app where CRUD and UX are pretty well known patterns.

Or a scalable web system - also very well tried territory.

Or analytics and data processing - again well trod.

If you’re not a good pattern matcher you might think every UI framework, or your next API abstraction, is some next general theory of relativity.

But otherwise the major novelty in most software project pursuits is going to be the context, people, and industry your building it into not the tech

wellpaston Architecting large software projects [video]

I had the same reaction.

I’m eager to find someone who has managed to abstract expertise.

I’m 25 years into repeatedly building large software systems. I was thinking, look here maybe someone’s managed to codify what I do.

Nope.

To your point, everything is contextual. If you try to apply a suite of rules the systems (which extend far outside of the bounds of a software subsystem deployment) will mock you by burying your efforts leaving no intentional outcome.

Everything is systems thinking and every seat & context is different. You have to navigate mostly with realtime navigations based on long- and hard- earned muscle memory.

wellpaston Architecting large software projects [video]

The majority of people work in that world. Even the majority of startups, where you’d expect to find the novel pursuits, are building glorified spreadsheets.

wellpaston Ask HN: What are you working on? (July 2025)

Thank you!

wellpaston Show HN: Tiny logic and number games I built for my kids

This is great. I've been working on a social site where the content users post and scroll through are microgames (<500kb). My kids are my biggest users so far. My daughter loves this pill sorting game, for example:

https://xelly.games/game/b7eba4db-dc4b-4cfe-8420-3e42e494e52...

wellpaston Ask HN: What are you working on? (July 2025)

I’m working on a social site where users post (and “fork”) “micro games” (<500kb) instead of tweets

https://xelly.games

wellpaston Mill: A better build tool for Java, Scala, and Kotlin

I agree 100%.

I've been around for a while, I've used many different build systems for JVM based builds (Java, Hybrid Java/Clojure, Scala) and Maven is by far the simplest most solid.

The basic reason is it's commitment to being declarative.

I understand why programmers want imperative (we're programmers) but it's just the wrong choice for a build system.

I've worked on many OSS projects. I've never pulled a Maven-based project that didn't immediately build and immediately load into my IDE. However for imperative based build systems (Gradle, Ant, now Mill) it's almost inevitable that you won't be able to get the build to work right away or pulled into your IDE in a sensible way (as IDEs cannot read imperative statemetns).

I've created many many build with Maven with many many different demands (polygot codebase, weird deployment artifacts, weird testing runtime needs, etc etc) and Maven has never let me down. Yes, in some cases I've had to write my own plugin but it was good that I had to do that; it forced me to ensure I really needed to -- the Maven plugin ecosystem is already great and covers 90+% of use cases of builds.

I've met a lot of Maven naysayers and the disdain is almost always either some weird aversion to XML (such a trivial reason to choose a worser build system) and/or because the programmer never took the time to understand the rather simple Maven runtime semantics and architecture.

wellpaston My Family and the Flood

Mobile notifications is a terrible solution to this

Need ground alert sirens or something that would be taken seriously

wellpaston AI slows down open source developers. Peter Naur can teach us why

The fact that the devs thought the AI saved them time is no surprise to me… at least at this point in my career.

Developers (people?) in general for some reason just simply cannot see time. It’s why so many people don’t believe in estimation.

What I don’t understand is why. Is this like a general human brain limitation (like not being able to visualize four dimensions, or how some folks don’t have an internal monologue)?

Or is this more psychodynamic or emotional?

It’s been super clear and interesting to me how developers I work with want to believe AI (code generation) is saving them time when it’s clearly obviously not.

Is it just the hope that one day it will? Is it fetishization of AI?

Why in an industry that so requires clarity of thinking and expression (computer processors don’t like ambiguity), can we be so bad at talking about, thinking about… time?

Don’t get me started on the static type enthusiasts who think their strong type system (another seeming fetish) is saving them time.

wellpaston Ask HN: What Are You Working On? (June 2025)

https://xelly.games

Scrollable social network where the user generated content is microgames.

wellpaston The age of average (2023)

You can’t poll people to say what they want in an art piece. They’re not artists.

You have to show them the options. Wow them with a masterpiece. See what they pay for, not what they describe they want.

If determining what people wanted in art was just a matter of polling them, then Hollywood economics would look much different.

wellpaston No such thing as exactly-once delivery

In streaming apps, the data is not only stored in memory, and failures are inevitable.

A common streaming app will consume from a distributed log (Kafka, Kinesis) and only commit offsets if/when the data from the last offset to the next committed offset is fully processed in exactly-once semantics.

When delivering to the destination, the same story can hold. If the delivery destination returns a failure, then it may or may not have committed the write, but the streaming app will ensure either that the correct (exactly-once) value will be eventually flushed, or will retry computing the tally.

This will give you eventually consistent exactly-once semantics unless you allow the destination system (or any system) to remain in outage forever. But then of course if that's true, then you won't get any semantics, exactly-once, at-least-once, or otherwise.

wellpaston No such thing as exactly-once delivery

A typical delivery target is a data store or cache. Writing to such a delivery can be construed of as a “side effect”. But if you accept eventual consistency, achieving exactly once semantics is possible.

Eg a streaming framework will let you tally an exactly once counter. You can flush the value of that tally to a data store. External observers will see an eventually consistent exactly-once-delivery result.

wellpaston No such thing as exactly-once delivery

is there a real difference between delivery and processing?

In a streaming app framework (like Flink or Beam, or Kafka Streams), I can get an experience of exactly once "processing" by reverting to checkpoints on failure and re-processing.

But what's the difference between doing this within the internal stores of a streaming app or coordinating a similar checkpointing/recovery/"exactly-once" mechanism with an external "delivery destination"?

wellpaston Web components are okay

What’s missing in his point and examples about “performance isn’t everything” (aria properties, forEach, …) is that these are cases where you could optimize later when and if needed. Using forEach is a fluid coding choice at the time but if for any reason you need to optimize to a for loop you can with minimal fanfare. But buying into web components is more of a one-way door and harder to iterate optimizations, and that’s the problem.

wellpaston We removed advertising cookies, here's what happened

Presumably that's a first-party cookie you're persisting not a cross-site third-party cookie, so wholly different standards apply for your case.

wellpaston You are never taught how to build quality software

> 'If we don't do it now, development efforts (and therefore also costs) will be up 15% in 4 months.'

Yeah you won't get to a point where you'll have a valid-enough metric to make this point.

I was at a startup once. The two founders said "don't write unit tests". I wasn't going to argue with them. I understood what they really meant. We've been too slow, we need to ship as fast as possible. I shipped fast and I shipped quality (ie low defects and outages). I wrote unit tests. They didn't need to know. They just needed the outcome.

The elephant in the room in all of these conversations is that you walk into any software development shop and they just don't how to ship both fast and at quality. No matter how much an organization or team tries to revisit/refactor their dev process year-to-year, they're still shipping too slow and mediocre quality.

The truth is there isn't a magic formula. It's an individual craft that gets you there. It's a team sport. And the context is different enough everywhere you go, yeah, sure, some lightweight processes might abstract across the universe but very little bang for those bucks. Far beyond any other facet of things, you really just have to have a good team with experience and the right value-system/value-delivery-focused wisdom.

wellpaston Unified versus Split Diff

> For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas, but mostly just doing general review, as if I am writing the code. I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code.

This is spot on. In fact, I think modern code review practices over emphasize the historical path to the code at the expensive of lost quality of the present code and code architecture.

"Minimizing diffs" is a feature of modern code and PR practices, whether it's explicit or tacitly something the developers do. Optimizing for minimizing diffs discourages the continuous refactoring that code bases require to stay solid, sound, and visibly correct.

wellpaston Ask HN: Show me your half baked project

https://www.chronos-desk.com/

Local-first personal task management with estimation.

wellpaston I don’t buy “duplication is cheaper than the wrong abstraction” (2021)

To talk about “duplication is cheaper than the wrong abstraction” without invoking "dependencies" at all (and their costs) means the entire premise has been missed.

Another tell:

> Don’t try to make one thing act like two things. Instead, separate it into two things.

If abstractions were so easily split like this, then the advice wouldn't hold. But they never are. Abstractions immediately accumulate dependencies making it near impossible to split them, as we all learn after living in anything other than toy code bases.

This is the hallmark of a junior (ie someone who has not been to battle much) is making de-duplicating code a priority and not understanding the cost of dependencies.

wellpaston Whom the gods would destroy, they first give real-time analytics (2013)

And… near real-time with high uptime is relatively more costly to build / maintain / deploy / operate than batch — so save your org the cost!

wellpaston Accidentally Load Bearing

What I've learned from decades of software development: ANY and every component or capability you build into your system, incidentally or explicitly, will immediately (ie tomorrow) become "Accidentally Load Bearing".

Dependencies flow in and onto new components like water. This is a fundamental law.

Even secret interfaces, etc that you think no one could find or touch will be found and fondled and depended upon.

This is why the correct view is that all software is a liability and we should write as little of it as possible, just the minimal that is needed to get the dollars and nothing more.

wellpaston Responding to “Are bugs and slow delivery ok?”

Well said — and yes.

It’s definitely market dynamics, but I think something could change those market dynamics.

Maybe a craftsmen’s guild that unionizes skilled software practitioners.

wellpaston Responding to “Are bugs and slow delivery ok?”

This is called software philistinism.

There are many blog posts like this one that deny (often deride) the value of software craftmanship, including the skillset of planning.

They almost always have this same conclusiveness to them as well ("she was right"), with no tangible backing other than personal anecdata ("everyone sucked who I worked with, so everyone must suck").

If you zoom out, the reality is that people in the software industry are spoiled AF. A majority of practitioners get paid a ridiculous amount and get away with murder.

It is true that current market dynamics give people in this industry pretty much zero incentive to get good at the craft. So people don't and then to rhetorically justify their philistinism, they write blog posts like this.

It is also true that many businesses get away with writing absolutely shitty software and stay in business because of these dynamics. But that doesn't make it "ok" and doesn't say anything about the enormous amount lost to such apathy.

wellpaston Writing as a form of thinking

Because writing, like exercise, really is a boon. It would be strange to go on about its deleterious effects. It'd seem like looking for an indirect excuse to not engage in something that's challenging and good for you.

wellpaston The rule says, “No vehicles in the park”

But the ambulance DOES break the rule. Clearly and unambiguously.

But breaking rules like this in cases of emergency is the correct thing to do.

This is where the moderation difficulty comes in.

wellpaston Turning Joe Rogan down was the right thing to do

100%. For COVID and other topics there is an unfortunately common mindset of "the public isn't smart enough to sort out truth and make up their own mind" which is patently incorrect and dangerous, really, because the people that tend to espouse this are either the experts that want to be deferred to or people willing to defer to experts out of fear or laziness or inability to contend with ambiguity.