Live data from Hacker News

How I build software quickly

evanhahn.com

151–160 of 215 posts

Re: How I build software quickly

#151

Earlier quoted context omitted.

> Forget Kubernetes, Redis While I agree with you, these two are the boring tech of 2025 for me. They work extremely reliably, they have well-defined use cases where they work perfectly and we know very well where they shouldn't be used, we know their gotchas, the interest around them seems to slowly wane. Personally, I'm a huge fan of these, just because they're very stable and they do what they are supposed to do.

A lot of the conversation about "simplicity" with kubernetes ignores that there are MANY different distributions of k8s. I would argue that k3s on a vm is not too much harder to setup than a normal reverse proxy setup. And the configs are a bit easier to find on a whim when coming back after months. Obviously a full self hosted setup of k8s is pretty large task but in other forms its a competitive option in the "simp…

K8s is chock full of complexity though. Complexity that the vast majority of applications do not, and will not need

Re: How I build software quickly

#152

Earlier quoted context omitted.

A lot of the conversation about "simplicity" with kubernetes ignores that there are MANY different distributions of k8s. I would argue that k3s on a vm is not too much harder to setup than a normal reverse proxy setup. And the configs are a bit easier to find on a whim when coming back after months. Obviously a full self hosted setup of k8s is pretty large task but in other forms its a competitive option in the "simp…

Last time I tried what stumped me was getting "ReadWriteMany" volumes working. My use case was pretty straightforward, a series of processing steps with the caveat that storing the actual results in a DB would be bad due to the blobs size. So, instead, the DB is used to signal downstream consumers files are ready and instead write the files in the ReadWriteMany volumes so that downstream files can simply read them. I…

Use a bucket for this. Or if you’re in a home lab use a boring old NFS server outside k8s

Re: How I build software quickly

#153
Building software quickly seems to mostly come from having enough examples of code you've already built that you can pull from.

I recently re-made my web based notes app. Before working on this project I made a web based S3 file manager (e.g. CRUD operations in my own UI).

Instead of trying to store notes in a database or something, I just yoinked the S3 file manager code and store my notes in S3. Just a few tweaks to the UI and a few more features and now I have a notes app.

Re: How I build software quickly

#154
post #40

Earlier quoted context omitted.

I don't think anyone would advise to do everything from scratch all the time. It's mostly about libraries vs opinionated frameworks. No one in their right mind would say: just use the standard library but I've seen it online. That discourse is not helping. I think people get this miscontrued on both sides. A set of reusable, composable libraries would be the right balance in Go. So not really a "framework" either. I…

> No one in their right mind would say: just use the standard library but I've seen it online. That discourse is not helping. I would say that. The most important thing about standard library is its stability. You won't ever need to touch code that works with standard library. It's finished code. Other than bug fixes, of course. Third-party libraries is a very different thing. They gets abandoned all the time, so now…

I mean, I'm keen on a small number of dependencies too, but the smaller the scope of a package you go, I find the more likely they are to be abandoned. The Go JWT library has been forked twice because it became abandoned by the original authors, just to give an example.

Re: How I build software quickly

#155
Just one thing I'd like to throw out here after far too long in the industry: It's very hard to tell ahead of time just how users will put computers/software to use. Lots of generic, off-the-shelf HW and SW get used in ways that are ultimately 'life critical' to someone.

Something to keep in mind for design/development/testing.

Re: How I build software quickly

#156
post #61

Earlier quoted context omitted.

I have had some bad experiences with Sqlite for local desktop apps with regards to memory usage, especially on MacOs. Insert and delete a few thousands rows per hour, and over a few days your memory usage has ballooned. It seems to cause a lot of fragmentation.

What kind of memory usage are you talking about? That sounds wild. Are you keeping the entire database in memory, or are you flushing to disk? It seems wild that such a critical and pervasive piece of software would behave like that.

Keeping it in memory. After a few days, the memory usage reported by the Activity Monitor (so not the actual resident memory, but the one customers see and complain about) grows from maybe a few 10s MB to a few hundreds MBs.

But as far as I can tell, it's more an OS issue than really a Sqlite issue, simply doing malloc/free in a loop results in a similar behaviour. And Sqlite does a lot of allocations. We see a similar problem on Windows, but not as pronounced, and there we can force the OS to reclaim memory.

It's probably solvable by using a custom allocator, but at this point it's no longer plug and play the way the GP meant.

Re: How I build software quickly

#157
post #50

Earlier quoted context omitted.

I have had some bad experiences with Sqlite for local desktop apps with regards to memory usage, especially on MacOs. Insert and delete a few thousands rows per hour, and over a few days your memory usage has ballooned. It seems to cause a lot of fragmentation.

Curious to hear more about your experience, since my impression from hacking around in native Apple software is that pretty much a bunch of it is based on top of sqlite3. The Photos app is a case in point I remember off the cuff.

I think we might be using it in a slightly unusual way: collect data for a while, do one big query once in a while to aggregate/transform the data and clean everything. Rinse and repeat as it's a background app.

So lots of allocations/deallocations. If you're only storing a few key/value pairs long term, you won't have any issues.

Re: How I build software quickly

#158
post #92

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free? Having worked on some 24-hour game jams and similar, I've found completely the opposite. It's when you're in a real hurry that you really can't afford bad code. Writing better code will make it easier to get it right, wil…

There is something to this, but I'm fairly convinced that the key to writing fast clean code is to write more code. Pretty much period.

Sucks, as that is effectively arguing for rote repetition in the tasks. And it is. But, that works. Really well.

Stated differently, show me someone that can write clean code in a hurry, and you have shown me someone that has written this before.

Re: How I build software quickly

#159

Earlier quoted context omitted.

A lot of the conversation about "simplicity" with kubernetes ignores that there are MANY different distributions of k8s. I would argue that k3s on a vm is not too much harder to setup than a normal reverse proxy setup. And the configs are a bit easier to find on a whim when coming back after months. Obviously a full self hosted setup of k8s is pretty large task but in other forms its a competitive option in the "simp…

K8s is chock full of complexity though. Complexity that the vast majority of applications do not, and will not need

I only used it once forever ago, and all I remember is being very confused about pod vs service and using a lot of magic strings to get load-balancing to work. Sure I could figure it out, but didn't want to.

Re: How I build software quickly

#160

Earlier quoted context omitted.

A lot of the conversation about "simplicity" with kubernetes ignores that there are MANY different distributions of k8s. I would argue that k3s on a vm is not too much harder to setup than a normal reverse proxy setup. And the configs are a bit easier to find on a whim when coming back after months. Obviously a full self hosted setup of k8s is pretty large task but in other forms its a competitive option in the "simp…

Last time I tried what stumped me was getting "ReadWriteMany" volumes working. My use case was pretty straightforward, a series of processing steps with the caveat that storing the actual results in a DB would be bad due to the blobs size. So, instead, the DB is used to signal downstream consumers files are ready and instead write the files in the ReadWriteMany volumes so that downstream files can simply read them. I…

Ya this kind of usecase is for sure straying into the "this is more of a pain than its worth" with regards to k8s. Esp when you can just do basic nfs mounts in nix anyways.

If you are already familiar with k8s volumes and csi's its not a huge problem but if you arent its not worth learning if your goal is simple. At least in my opinion.

Post reply on HN