You can trace what's going back and forth over the wire between Claude Code and the model in use. That's going to be more insightful than their huge blob of JavaScript using React to render a terminal GUI.
This is like saying you've never worn a seatbelt and still haven't been in an accident. So you'd like to know the series of turns that led to someone else's accident.
I am saying it doesn't matter. Driving in motor vehicles is dangerous, but we still do it. It would be safer to never drive anywhere. We have decided its an acceptable risk. Someone doesn't post one car accident on hacker news where they got hit by a semi and we all collectively say "oh man, never driving again".
I think the statistics definitively prove you wrong that wearing seatbelts doesn't matter. Same goes for there being non-zero risk with skipping all permission checks in Claude Code.
People aren't saying "I'm never using Claude Code again" just like they aren't saying "I'm never driving again". That's not what the post or most of the discussion is about.
Thanks for mentioning this. I always find it unsettling when I've researched solutions for something and only find a better option from a random HN comment.
Fwiw I tried every tool imaginable a few years ago including kubb, (which I think I contributed to while testing things out)
The only mature, correct, fast option with a fixed cost (since it mostly exists at the type level meaning it doesn't scale your bundle with your API) was openapi-ts. I am not affiliated other than a previous happy user, though I did make some PRs while using it https://openapi-ts.dev/
And yes, current models are amazing at reducing time it takes to push out a feature or fix a bug. I wouldn't even consider working at a company that banned use of AI to help me write code.
PS: It's also irrelevant to whether it's AI generated or not, what matters is if it works and is secure.
There are literally users here that say that it works.
And you presume that the code hasn't been read or understood by a human. AI doesn't click merge on a PR, so it's highly likely that the code has been read by a human.
Yea that's a common theme of excuses for both Rust and Nix. Wrong though, because most anyone who can use a computer at all can learn the basics of Vim.
Seeing that flake.nix badge of complexity lets me know a project will be a nightmare to set up and will break every other week. It's usually right next to the Cargo.toml badge with 400 dependencies underneath.
To be honest I don't know what to say, you can use nix in many ways, and you don't even require to know the language.
The easiest entry-point is to just use it like a package manager, you install nix (which is just a command...) and then you have available the whole set of packages which are searchable from here: https://search.nixos.org/packages
nix-shell is just to download&add programs temporary to your PATH.
I don't feel that this is harder than something like "sudo apt install -y xxxxx" but for sure more robust and portable, and doesn't require sudo.
If at some point you want to learn the language in order to create configurations or packaging software, it may require to check a lot more documentation and examples, but for this I think it's pretty straightforward and is not harder than any other package manager like aptitude, homebrew or pacman.
Nix with Flakes never randomly break, I still have projects from 3 or 4 years ago that I can still run `nix build` and getting it running. Yes, if you try to update the `flake.lock` this may introduce breakages, but this is expected if you're pining `nixos-unstable` instead of a stable branch.
I’m not sure what you mean by “a nightmare to set up”. You install Nix on your current OS with the determinate.systems installer, and you enter `nix run github:johndoe/project-containing-a-flake-dot-nix-file` to try out the project and have the full reproducible build taken care of by Nix.
Sure, installing packages the proper way requires a little bit more setup (Home Manager, most likely, and understanding where is the list of packages and which command to build to switch configuration), but as trivial as other complex tasks most of us hackers are capable of doing (like using `jq` or Vim).
The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript.
In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once.
Let's not turn the singleton pattern into forbidden knowledge.
I was glancing around and landed on the page for the flyweight pattern.[1]
It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example.
Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.
> which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern
No, the opposite: it highlights the benefits of the flyweight pattern. The shallow copy saves memory. That's the point. You have two identical books. Rather than wasting memory with a deep copy, you make a shallow copy, where all your props point to locations in memory where values are located, and then you modify whatever is different. Now your shallow copy only consumes a small bit of extra memory.
And if those props are all primitives, then you can then modify that shallow copy, and it won't affect the original.
The point is to not make a copy at all for the shared data of the same book. That's even what the page claims is happening (but it's wrong). That's the whole point of the flyweight pattern[1]. Instead, the example returns the same book instance for the same isbn in `createBook`, then blindly copies the shared data like title, author, and isbn every time in `addBook` to a new object.
> The shallow copy saves memory....
Versus not making a copy? A shallow copy of primitives still copies them and uses additional memory. Maybe there's some low-level optimization that makes it more efficient than that, but it's not relevant here. And there isn't any deep cloning happening in the example.
Might as well get rid of the complexity and instantiate a new Book class every time. And maybe stop shallow-copying class instances into new plain objects. It works for the example but has footguns.
Conveniently, there are other patterns on the site that would help you avoid creating an amalgamation of random merged class instances and objects.
Some people appreciate a nice looking site, they just didn’t have time to spend making it look nice. Now those people have the option of doing that without a huge time commitment, so undoubtedly some of them will.
Seems like a self-inflicted problem. You can turn off Light Switch in PowerToys. I don't know what screensaver software you're using, but if it's hijacking the setting maybe consider uninstalling it.
reply