HN user

mxey

355 karma
Posts4
Comments148
View on HN

The Compose file is written like that so you can quickly try the app without setting up extra dependencies. Usually not for production use.

Especially since in production you might want to scale the parts separately. I like to have a Postgres cluster to connect where backup is already handled, and the app then doesn’t have any persistent data, doesn’t need any network volume mounts.

Yes, initially modules used to modify the file automatically which is why I have -mod=readonly in some old pipelines.

I think the “new” way is much better.

I still run tidy in pipelines to check but that’s only for cleanup.

It only syncs go.mod with what is already being used by the build process

If dependencies are incomplete, Go will fail to compile and tell you to run go mod tidy to fix it.

Pinning to me means there is a file with all the versions as they will be used. I don’t see how “go mod tidy” modifying it is different from “bundle install” modifying it.

You literally cannot dereference an Option without acknowledging the None case. Whole categories of pager-duty incidents disappear.

This is at the very least misleading, given that you can use unwrap.

Regarding error handling: will a parser error in the config return an error that includes the name of the file that’s failed to parse? That’s the kind of useful context that I add to errors in Go.

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

That’s the opposite of clean-room. The whole point of clean-room design is that you have your software written by people who have not looked into the competing, existing implementation, to prevent any claim of plagiarism.

“Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.”

PostgreSQL shares other caches between processes so they probably could have a global plan cache if they wanted. I wonder why they don’t though.

One possible reason is that the planner configuration can be different per connection, so the plans might not transfer

This is very good to know because it means this exclusion constraint workaround is a better approach over using a SQL hash function and a btree if you want to enforce uniqueness on values too long for a btree index.

No, that’s why I said deploy. All it does is run kubectl apply and kubectl rollout status.

Only those are directly tied to the data in CUE. there’s not much advantage to running other commands with it. You can run arbitrary processes with cue cmd though.

Not sure if that’s what you mean but we have apps where all you need to deploy them to Kubernetes is run “cue cmd deploy”.

The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support.

cue cmd is nice but it’s not the reason to use CUE. The data parts are. I would still use if I had to use “cue export” to get the data out of it with a bit of shell.

I had the same thought about the idea that Safari is “behind”. My hypothesis is that features only “exist” to people if they are implemented in Chrome. If a feature exists in WebKit but not in Chrome, nobody talks about it.

Quilt was AFAIK used before Git, so you’re not wrong. But now that it’s there, it has some advantages.

I’m not arguing against replacing Quilt, but it should be more than just Git. I haven’t done Debian packaging in a long time but apparently there are some Git-based tools now?

So there’s no way to have commit messages on changes to patches? There’s also https://dep-team.pages.debian.net/deps/dep3/

People keep saying “just use Git commits” without understanding the advantages of the Quilt approach. There are tools to keep patches as Git commits that solve this, but “just Git commits” do not.

For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience.

The golang/go repo itself has various checked-in generated repo