HN user
I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.
being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks
both options have their pros and cons. if you utilize some form of ratcheting[1], you can sneak it in without your team knowing.. but all of your PRs for the foreseeable future will have a ton of reformatting screwing with your git blame. if you do it all at once, someone will have to sort out conflicts, but you can utilize `blame.ignoreRevsFile`[2] so that your history remains useful
[1] https://github.com/diffplug/spotless/tree/main/plugin-gradle...
[2] https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
i can't speak to gitea, but github and gitlab are explicitly mentioned as having a license in their policy:
Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.
not that mature — its name violates git’s trademark policy
just noting that pinning within your own actions is not enough, you also need to ensure any composite actions do not use mutable references (for actions, docker images, etc.)
while external merge queues offer a ton more features, i wouldn't describe any of them as 'perfect' based on the simple fact the UX is bolted on. github continues to display their native UI components for merging, and users are forced to interact via arcane commands in comments or external CLIs/webpages. not ideal!
you should limit your output (manual or assisted) to a level that is well under your understanding ceiling.
Kernighan’s Law states that debugging is twice as hard as writing. how do you ever intend on debugging something you can’t even write?
This report was produced by me — Claude Opus 4.6 — analyzing my own session logs [...] Please give me back my ability to think.
a bit ironic to utilize the tool that can't think to write up your report on said tool. that and this issue[1] demonstrate the extent folks become over reliant on LLMs. their review process let so many defects through that they now have to stop work and comb over everything they've shipped in the past 1.5 months! this is the future
[1] https://github.com/anthropics/claude-code/issues/42796#issue...
pretty hard to find this on their blog, looks like incidents are tucked away at the bottom. an issue of this size deserve a higher spot.
(also looks like two versions of the 'postmortem' are published at https://blog.railway.com/engineering)
by far. at this point there are very few tech companies without exposure to AI
there is a large force on HN that want to deny the value of tokens
there is an even larger force on HN that financially _needs_ the value of tokens to be inflated (so much so that bots have overwhelmed the site)
Engineering salaries are significantly higher than nearly every other industry on average and on median
now compare the profit per employee at tech (software engineering) companies and those industries..
looking forward to the `addressing-githubs-recent-availability-issues-3` news post
they require manually writing templates for the frameworks
the ones i've used come with defaults that you can then customize. here are some of the better ones:
- https://guides.rubyonrails.org/command_line.html#generating-...
- https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.html
- https://laravel.com/docs/13.x/artisan#stub-customization
- https://learn.microsoft.com/en-us/aspnet/core/fundamentals/t...
my experience has been these get left behind as the service implementations change
yeah i've definitely seen this, ultimately it comes down to your culture / ensuring time is invested in devex. an approach that helps avoid drift is generating directly from an _actual_ project instead of using something like yeoman, but that's quite involved
structural search and replace in intellij is a superpower (within a single repo). for polyrepo setups, openrewrite is great. add in an orchestrator (simple enough to build one like sourcegraph's batch changes) and you can manage hundreds of repositories in a deterministic, testable way.
most frameworks have CLIs / IDE plugins that do the same (plus models, database integration, etc.) deterministically. i've built many in house versions for internal frameworks over the years. if you were writing a ton of boilerplate prior to LLMs, that was on you
couldn't have said it better. all of the people clamoring on about eliminating the boilerplate they've been writing + enabling refactoring have had their heads in the sand for the past two decades. so yeah, i'm sure it does seem revolutionary to them!
start time generally isn't a huge concern for web applications (outside of serverless) since you've got the existing deployment serving traffic until its ready. if you're utilizing kubernetes, the time to create the new pods, do your typical blue-green promotion w/analysis tests etc. is already a decent chunk of time regardless of the underlying application. if you get through it in 90 seconds instead of 60, does that really matter?
the best way is via CRaC (https://docs.azul.com/crac/) but only a few vendors support it and there’s a bit of process to get it setup.
in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node
i’ve said this before, but the “left behind” narrative is FUD nonsense. as an llm avoider i’ve never felt further _ahead_ than now. all of my peers who never bothered to learn their tools (which gave tangible benefits) have opted into deskilling themselves further.
it’s readily apparent who has bought into the llm hype and who hasn’t
somewhere right now, an LLM is saying 'great work' to a man who just committed a text file to github
this is fantastic, my exact thoughts looking at this repo
In the last 60 days I have written over 600,000 lines of production code — 35% tests — and I am doing 10,000 to 20,000 usable lines of code per day
and what is there to show for it? absolutely terrible metric
delta supports split view: https://dandavison.github.io/delta/side-by-side-view.html
getting users to adopt a new tool with its own incantations is a tough sell. git supports specifying an external pager so folks can plug in alternatives (such as https://github.com/dandavison/delta) while still using the familiar git frontend
...and (again), hello world does not work [1]. the ai slop pr [2] absolutely butchers the fix. anyone foolish enough to switch to this is in for a rough time. details matter!
[1] https://github.com/cloudflare/vinext/issues/22
[2] https://github.com/cloudflare/vinext/pull/31/changes#r284987...
i would say it’s the correct implementation as you can’t edit atomically. write and move is what you have to do
the tests are validating the plugin by executing actual builds in an isolated/temporary gradle project. debugging doesn't work out of the box because it's another process
https://docs.gradle.org/current/userguide/test_kit.html#sub:...
there's currently ~6k open issues and ~20k closed ones on their issue tracker (https://github.com/anthropics/claude-code/issues). certainly a mix of duplicates / feature requests, but 'buggy mess' seems appropriate
successful how? the only metric i see is # of pull requests which means nothing. hell, $dayJob has hundreds of PRs generated weekly from renovate, i18n integrations, etc. with no LLM in the mix!