wild_egg

You're thinking of outbound port limits. Inbound connections all come in on the same port and there's no port-related limits there.

The real limits are going to be on hardware. If we want 40M concurrent connections, the server will need a few hundred to a few thousand gigabytes of memory.

Grug is simply the narrator's name. He's speaking in the third person.

Meant to be some generic "caveman" name/character.

There's an argument to be made that this gap is actually highlighting design issues rather than AI limitations.

It's entirely possible to have a 100k LOC system be made up of effective a couple hundred 500 line programs that are composed together to great effect.

That's incredibly rare but I did once work for a company who had such a system and it was a dream to work in. I have to think AIs are making a massive impact there.

The mac one is pretty limited. I paid for a similar tool as above and the LLM backing makes the output so much better. All my industry specific jargon gets captured perfectly whereas the Apple dictation just made up nonsense.

It's not ambiguous though. The behaviour is very clearly defined in the language spec.

https://go.dev/ref/spec#Selectors

As far as language specs go, Go's is really quite concise and I strongly encourage everyone I onboard to spend an afternoon reading it end to end at some point in their first couple weeks.

This is exactly how I've been using it the last couple years and it's incredibly nice.

The thing I'm stuck on is that, yes, the proof is correct.

But what guarantees do I have that the proof or theorem is actually representative of the program I'm trying to specify?

And beyond that, what guarantees are there that the resulting end program actually adheres to either the specs or what has been proven?

Like it seems the goal here is `English -> Lean -> Code in whatever language` instead of just `English -> Code` but there's no way to be certain the translation step on either side of Lean has actually been done correctly.

I've done a lot of experiments around this so far this year and theorem provers can certainly help provide LLMs with more context but there is no tooling to actually verify that the resulting Python fully covers the corresponding Lean that was fed in.

No dog in this race but, as an outsider, it's always seemed really odd that some countries (Japan sticks out) are allowed to prioritize cultural preservation but European countries are not.

Didn't RC drop DHH from RailsConf because of his views? Seems weird to think they're collaborate on a coup or whatever is being suggested here.

The copyright holder is free to grant use under any license they like to whoever they like.

It's rare but I've seen a number of projects over the years that have a hard copyleft license along with a line in the readme like "Want to use this with a different license? Send me an email and we'll sort it out"

You're right that immediate mode is great and makes life so much easier but for most use cases, React is very much a "retained mode" framework. If all of the valuable state in your app has its source of truth on the server (majority of apps), then retaining any of it in React state soup is unnecessary complexity.

People like to bring up how terrible it was to do vanilla.js in the old days but completely ignore that we are not, in fact, still in the old days. Native browser APIs are so much more powerful now and a ton of the pain that React was made to solve is even now handled declaratively with some simple HTML and CSS. No hacked out JS required.

Lots of packages out there using SIMD for lots of things.

You can always drop into straight assembly if you need to as well. Go's assembler DX is quite nice after you get used to it.

I mean, it is just plain text inside some XML tags. It'd be weirder if they treated it like text in a photo

I have a bunch of homegrown CLI tools in my $PATH that are only described in the CLAUDE.md file. My subagents use these tools perfectly as if they have full instructions on their use but no such instructions are in the subagent prompts.

This should not be possible if they don't have CLAUDE.md in their context.

My main agent prompt always has a complete ban on the main agent doing any work themselves. All work is done by subagents which they coordinate.

I've been doing this for 2-3 months now on projects upwards of 200k lines and the results have been incredible.

I'm very confused how so many of us can have such completely different experiences with these tools.

It's kind of funny but the "concept design" as described is actually just well-designed OOP.

If your OOP code is a soup if Nouns, you and your AIs are all going to have a bad time.

We're talking about a $2.5T company. Literally every example in this thread is already negligible to Amazon already without circuit breakers.

Implementing that functionality across AWS would cost orders of magnitude more than just simply refunding random $100k charges.

> Advances in the browser standards are slowly removing the need for most client side JS altogether

I probably wasn't clear enough when I said this.

If you're talking about waterfall requests in module loading, you've missed what I said and are likely sending orders of magnitude more JS to clients than you need to.

It's really worthwhile looking at all the new features in browsers over the last 5-10 years and asking yourself if you really can't do what you need just with vanilla HTML and CSS at this point. You can always sprinkle in a bit of JS to fill in some gaps if needed. My team usually has a 2-300 line JS file in each project. No bundlers or modules ever required at that scale.

Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards.

Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit.

Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the time.

Browser standards have come a long way in filling the holes that caused react to be written in the first place.

They had a 56 hour "quality degradation" event last week but things seem to be back to normal now. Been running it all day and getting great results again.

I know that's anecdotal but anecdotes are basically all we have with these things

You know, it's ok to say that you're out of your element and don't have direct experience with the thing you're commenting on.

SQLite is easily the best scaling DB tech I've used. I've moved all my postgres workloads over to it and the gains have been incredible.

It's not a panacea and not the best in all cases but it's a very sane default that I recommend everyone start with and only complicate their stack with an external DB when they they start hitting real limits (often never happens)

It only freezes your application if you've misconfigured it.

Lisp was absolutely meant to be used that way.

The workflow for long running lisp images is really unclear to me. It's so trivial for the code in the image to get out of sync with what's on disk.

Are there good tools that I'm overlooking for exploring the current image state? Smalltalk has that built-in but in CL I'm regularly loading my system into a fresh SBCL at least every couple days just because, at some point, some state is not what I expect it to be and I have no idea how to reconcile it.

What? Why are you backing up the WAL?

    sqlite3 source_database.db ".backup backup_database.db"

Now the WAL content is rolled into your new backup file. Stick a timestamp in the backup file name and run this as a cron job every N minutes and you have all the recovery you need. Another one-liner to sync to S3 and you're all set.

Edit: And just to clarify, that command can be run on a live DB as it's being used by your app server. SQLite handles external concurrent readers just fine.

Didn't we just have the opposite conversation?

https://news.ycombinator.com/item?id=44909599

> "dealing with WAL"

What's there to deal with? You turn it on with a pragma and forget about it.

It hasn't been promoted that way for over a decade at this point.

I mean Rails also makes it easy to accidentally nest further queries inside your `find_each` block and end up with the same problem.

Your team can have rules and patterns in place to mitigate it but I'd never say "Rails makes this easy to avoid".

CL is strongly typed but not statically typed. The compiler generally doesn't complain ahead of time that your function is going to do math on a string because it was called incorrectly. Typically a runtime condition will be signalled when it hits that point and you can sort it out from there.

Coalton moves that to the compilation step so you get an error back the instant you send the form to the REPL.

I asked about "worse", not "home-grown".

Anyways you have a false equivalency there. Something being "less developed" doesn't automatically make it "worse". On the contrary, projects with larger active development effort generally trend to enshittification whereas smaller projects can stay focused on solving their core use cases.

For a macOS-specific example, see https://x.com/ryolu_/status/1954598993515962707