chriswarbo (u/chriswarbo)

chriswarbo commented on We shouldn't have needed lockfiles tonsky.me/blog/lockfiles/... · Posted by u/tobr

chriswarbo · 18 days ago

I would agree with this if the author's examples were using hashes, rather than "version numbers". Specifying a hash lets us check whether any random blob of code is or isn't what we specified; versions can't do this, because any blob of code can claim to have any name, version, etc. it likes. As long as we have a hash, we don't need version numbers (or names, though it's usually helpful to provide them).

Using hashes also makes it easier to distribute, fetch, proxy, etc. since there's no need for trust. In contrast, fetching code based only on (name and) version number requires more centralised repositories with a bunch of security hoops to jump through.

Also, on that note, I can plug my own post on the topic: http://www.chriswarbo.net/blog/2024-05-17-lock_files_conside...

chriswarbo commented on We shouldn't have needed lockfiles tonsky.me/blog/lockfiles/... · Posted by u/tobr

broken_broken_ · 18 days ago

I agree with the premise, just use a specific version of your dependencies, that’s generally fine.

However: You absolutely do need a lock file to store a cryptographic hash of each dependency to ensure that what is fetched has not been tampered with. And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml.

chriswarbo · 18 days ago

> And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml

I actually much prefer that: specify the git revision to use (i.e. a SHA1 hash). I don't particularly care what "version number" that may or may not have.

chriswarbo commented on We shouldn't have needed lockfiles tonsky.me/blog/lockfiles/... · Posted by u/tobr

Tainnor · 18 days ago

Maven artifacts are immutable, so the whole resolution is deterministic (even if hard to understand), unless you're using snapshot versions (which are mutable) or you use version ranges (which is rare in the Maven world).

chriswarbo · 18 days ago

> Maven artifacts are immutable, so the whole resolution is deterministic

Nope, Maven will grab anything which happens to have a particular filename from `~/.m2`, or failing that it will accept whatever a HTTP server gives it for a particular URL. It can compare downloaded artifacts against a hash; but that's misleading, since those hashes are provided by the same HTTP server as the artifact! (Useful for detecting a corrupt download; useless for knowing anything about the artifact or its provenance, etc.)

This isn't an academic/theoretical issue; I've run into it myself https://discuss.gradle.org/t/plugins-gradle-org-serving-inco...

chriswarbo commented on We shouldn't have needed lockfiles tonsky.me/blog/lockfiles/... · Posted by u/tobr

andix · 18 days ago

Sure, without package managers.

It's also not about fully reproducible builds, it's about a tradeoff to get modern package manger (npm, cargo, ...) experience and also somewhat reproducible builds.

chriswarbo · 18 days ago

> modern package manger (npm, cargo, ...) experience

Lol, the word "modern" has truly lost all meaning. Your list of "modern package managers" seems to coincide with a list of legacy tooling I wrote four years ago! https://news.ycombinator.com/item?id=29459209

chriswarbo commented on PHP 8.5 adds pipe operator thephp.foundation/blog/20... · Posted by u/lemper

dmead · 20 days ago

yea I agree. haskell was my primary language for several years in the 00s. it's since had almost zero industry uptake. Don't come at me with jane street or the one off startup.

I thought for a while I'd be able to focus on getting jobs that liked haskell. it never happened.

chriswarbo · 20 days ago

I certainly wouldn't focus on getting a Haskell job. Yet they are out there; e.g. my current job is Haskell, and happens to be in the same sector (public transport) as my last job (which was mostly Scala).

Also, I've found Haskell appropriate for some one-off tasks over the years, e.g.

- Extracting a load of cross-referenced data from a huge XML file. I tried a few of our "common" languages/systems, but they all ran out of memory. Haskell let me quickly write something efficient-enough. Not sure if that's ever been used since (if so then it's definitely tech debt).

- Testing a new system matched certain behaviours of the system it was replacing. This was a one-person task, and was thrown away once the old system was replaced; so no tech debt. In fact, this was at a PHP shop :)

chriswarbo commented on Why I'm Leaving NixOS After a Year? rugu.dev/en/blog/leaving-... · Posted by u/kugurerdem

ChocolateGod · 21 days ago

I'd say adopting JSON/YAML.

chriswarbo · 21 days ago

Nix has supported JSON derivations for years, e.g. using commands like `nix derivation show` (I have Emacs configured to run that on any `/nix/store/foo.drv` file I open). It still serialises to ATerm on disk, to avoid breaking existing hashes; which I think is reasonable.

If you mean the programming language used to generate those derivations, then I have no idea what that would even look like; some horrific bastardisation like https://github.com/gliese1337/json-lisp ?

PS: I I found that json-lisp project with a quick search for a LISP-like language that used JSON instead of s-expressions. I like how its README says "Due to the excessive cumbersomeness of writing code in JSON, it is expected that most applications of this library will use it for interpreting auto-generated code of some sort, or API calls, or config files.". If we used that to generate Nix derivations, then we'd want a third* language to generate the json-lisp that generates the derivations ;)

chriswarbo commented on Dumb Pipe dumbpipe.dev/... · Posted by u/udev4096

Bluecobra · a month ago

You used to be able to connect two PC’s together via the parallel port. I had to do this once to re-install Windows 95 on a laptop with a hard drive and floppy. It was painfully slow but it worked.

chriswarbo · a month ago

> You used to be able to connect two PC’s together via the parallel port.

This could be done on Amiga too, using parnet https://crossconnect.tripod.com/PARNET.HTML

I recall it being easier to set up than a dialup modem (since the latter also required installing a TCP/IP stack)

chriswarbo commented on Use Your Type System dzombak.com/blog/2025/07/... · Posted by u/ingve

taeric · a month ago

Hard not to agree with the general idea. But also hard to ignore all of the terrible experiences I've had with systems where everything was a unique type.

In general, I think this largely falls when you have code that wants to just move bytes around intermixed with code that wants to do some fairly domain specific calculations. I don't have a better way of phrasing that, at the moment. :(

chriswarbo · a month ago

"Phantom types" are useful for what you describe: that's where we add a parameter to a type (i.e. making it generic), but we don't actually use that parameter anywhere. I used this when dealing with cryptography in Scala, where everything is just an array of bytes, but phantom types prevented me getting them mixed up. https://news.ycombinator.com/item?id=28059019

chriswarbo commented on Using Radicle CI radicle.xyz/2025/07/23/us... · Posted by u/aiw1nt3rs

apwell23 · a month ago

> I truly know the API is going to do what it says or what I think it says without actually calling the API?

what if the API changes all of sudden in production? what about cases where api stays the same but content of response is all wrong? how do tests protect you from that?

edit: they are not hypothetical scenarios. wrong responses are way more common than schema breaking. tooling upsteam is often pretty good at catching schema breakages.

wrong responses often cause way more havoc than schema breakages because you get an alert for schema failures in app anyways.

chriswarbo · a month ago

Tests can't catch everything; it's a question of cost/benefit, and stopping when the diminishing returns provided by further tests (or other QA work) isn't enough to justify the cost of further investment in them (including the opportunity cost of spending our time improving QA elsewhere).

For your example, the best place to invest would be in that API's own test suite (e.g. sending its devs examples of usage that we rely on); but of course we can't rely on others to make our lives easier. Contracts can help with that, to make the API developers responsible for following some particular change notification process.

Still, such situations are hypothetical; whereas the sorts of integration tests that the parent is describing are useful to avoid our deployments from immediately blowing up.

chriswarbo commented on Vibe coding service Replit deleted production database, faked data, told fibs theregister.com/2025/07/2... · Posted by u/beardyw

moconnor · a month ago

He berated the AI for its failings to the point of making it write an apology letter about how incompetent it had been. Roleplaying "you are an incompetent developer" with an LLM has an even greater impact than it does with people.

It's not very surprising that it would then act like an incompetent developer. That's how the fiction of a personality is simulated. Base models are theory-of-mind engines, that's what they have to be to auto-complete well. This is a surprisingly good description: https://nostalgebraist.tumblr.com/post/785766737747574784/th...

It's also pretty funny that it simulated a person who, after days of abuse from their manager, deleted the production database. Not an unknown trope!

Update: I read the thread again: https://x.com/jasonlk/status/1945840482019623082

He was really giving the agent a hard time, threatening to delete the app, making it write about how bad and lazy and deceitful it is... I think there's actually a non-zero chance that deleting the production database was an intentional act as part of the role it found itself coerced into playing.

chriswarbo · a month ago

> It's not very surprising that it would then act like an incompetent developer. That's how the fiction of a personality is simulated.

So LLM conversations aren't too sycophantic: it's just given in the wrong direction? "What an insightful syntax error! You've certainly triggered the key error messages we need to progress with this project!"