franticgecko3

How useful is this without weights?

Isn't the mote that Nvidia has is they work with studios to generate the training data from the game, then they ship a model per game?

Or is my knowledge outdated here and they're just using a single generalised model?

Generally the idea is that regions of memory that aren't being used are swapped out to disk, then other more useful things are brought into memory.

For example: you have a background program that you're not using and in the foreground you're crunching data from disk. In this scenario the most efficient use of your memory is to swap the background program out and pull the disk data into RAM.

The first field field has fallen to AI.

I wasn't convinced until the mathematics community started responding, openly, with severe distress.

What will be next?

The more we treat HuggingFace and RubyGems incidents as technological curiosities the closer we are to cementing a dangerous precedent where operators of AIs cannot be blamed.

LLMs do not desire, they hacked websites because OpenAI/Anthropic let them.

We know some of the models that hacked HF were those that hadn't gone through all training stages and were intentionally misaligned or had guardrails turned off, others were research previews.

This isn't "wow isn't it interesting LLMs do anything to achieve a goal" it's "why isn't anybody punishing these labs that are clearly acting without due care or regard".

We should be outraged and OpenAI/Anthropic should be (and in my mind, are) legally liable for the crimes they've committed thus far.

That's just so extremely difficult to believe.

Before December 2025 they were still intelligent code autocomplete or Stack Overflow bots, then they started one-shotting serious long horizon tasks. Now they've just solved a millennium prize problem.

In less than a year.

>It’s a beautiful Saturday morning with my family here in the East Bay. While I hope we have many more years, I don’t know how many more Saturdays I’ll be able to play outside with my kids in the sunshine so I’m going to make the most of the time we have.

Is there a social media training programme at Anthropic/OAI where they teach you to hint at some vague end-of-the-world scenario? They all sound the same.

>and every other app I check shows it.

Other apps have a different government?

You've been copying and pasting directly from Claude to reply to comments that ask how this works. You also realise you've been caught and are now replying in a completely different style.

You've thrown away all credibility.

OP seems to self promote this project and other similar vibe coded works every few weeks under two different HN handles.

Edit: for me this post appears on the front page of HN. OP this is mission success - add this project to your résumé and stop spamming.

Tab complete is completely broken on Firefox mobile (Android)

They have nothing to do with mathematics but everything to do with being extremely popular books.

Most people that have read a mathematics textbook have also read and enjoyed Harry Potter.

Given you have enjoyed drinking water and breathing in the past, there is a high likelihood that you will enjoy watching the Star Wars films.

I've long suspected it's got to do with office real estate.

You spent $10m or $100m on a building that's now half empty.

Either you downsize or commit to enterprise scale sunk cost fallacy and enforce RTO so your real estate investment isn't "wasted".

City centres also thrive on RTO, with high street shopping on a generational decline it's up to office workers and their employers to prop up the economy of the CBD one overpriced lunch at a time.

I've started learning (in 2025!) and using Perl lately as shell++

It's extremely stable, installed almost everywhere, and has much fewer insane idosyncrasies than shell.

I can write some Perl and confidently hand it to a colleague where it will almost certainly work on their machine.

It's a shame it's so dead, for a scripting language there's nothing else that ticks the same boxes.

I would never write systems software with it, of course

> Have a nightly job that runs unit and integ tests

Not enough IMHO.

We run all tests on developer machines and CI with -race. Always.

It's probabilistic, so every developer 'make test' and every 'git push' is coverage.

Assuming OP is in the UK, they're talking about hackney carriages which are subject to more stringent regulation than other private hire vehicles

https://en.wikipedia.org/wiki/Hackney_carriage

I think this would be similar to the medallions of yellow NYC cabs

>Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

I work at an Erlang shop.

For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.

More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.

When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.

I agree with most of your points but this one

>I find it useful for some coding tasks but think LLMs were overestimated and it will blow up like NFTs

No way. NFTs did not make any headway in "the real world": their value proposition was that their cash value was speculative, like most other Blockchain technologies, and that understandably collapsed quickly and brilliantly. Right now developers are using LLMs and they have real tangible advantages. They are more successful than NFTs already.

I'm a huge AI skeptic and I believe it's difficult to measure their usefulness while we're still in a hype bubble but I am using them every day, they don't write my prod code because they're too unreliable and sloppy, but for one shot scripts <100 lines they have saved me hours, and they've entirely replaced stack overflow for me. If the hype bubble burst today I'd still be using LLMs tomorrow. Cannot say the same for NFTs

I'm from West Yorkshire, the dialect is slowly fading. My grandfather would speak with a strong accent and with spatterings of Norse words. I notice now that, yes, dialects in the UK are becoming homogenised but there is also some American influence seeping in. The American way of pronouncing a double t as a d "better" => "bedder" is increasingly more prevalent in the UK, it's slightly saddening.

>The biggest mistake I see people make with Go channels is prematurely optimizing their code by making channels buffered. This is almost always a mistake. It seems logical. You don't want your code to block.

Thank you. I've fixed a lot of bugs in code that assumes because a channel is buffered it is non-blocking. Channels are always blocking, because they have a fixed capacity; my favorite preemptive fault-finding exercise is to go through a codebase and set all channels to be unbuffered, lo-and-behold there's deadlocks everywhere.

If that is the biggest mistake, then the second biggest mistake is attempting to increase performance of an application by increasing channel sizes.

A channel is a pipe connecting two workers, if you make the pipe wider the workers do not process their work any faster, it makes them more tolerant of jitter and that's it. I cringe when I see a channel buffer with a size greater than ~100 - it's a a telltale sign of a misguided optimization or finger waving session. I've seen some channels sized at 100k for "performance" reasons, where the consumer is pushing out to the network, say 1ms for processing and network egress. Are you really expecting the consumer to block for 100 seconds, or did you just think bigger number = faster?

> How often are you reaching 10^14 goroutines accessing a shared resource on a single process in production? We mostly use short-lived small AWS spot instances so I never see anything like that.

I apologize, that should've said 2^14, each sub-benchmark is a doubling of goroutines.

2^14 is 16000, which for contention of a shared resource is quite a reasonable order of magnitude.

> Since CSP is mentioned, how much would this apply to most applications anyway? If I write a small server program, I probably won't want to write it on paper first. With one possible exception I never heard of anyone writing programs based on CSP (calculations?)

CSP is really in the realm of formal methods. No you wouldn't formulate your server program as CSP, but if you were writing software for a medical device, perhaps.

This is the FDR4 model checker for CSP, it's a functional programming language that implements CSP semantics and may be used to assert (by exhaustion, IIRC) the correctness of your CSP model.

https://cocotec.io/fdr/

I believe I'm in the minority of Go developers that have studied CSP, I fell into Go by accident and only took a CSP course at university because it was interesting, however I do give credit to studying CSP for my successes with Go.

I have replied to another comment with more details: the channel mutex is not the same one that sync.Mutex is using.

The article that the OP article references does not show the code for their benchmark, but I must assume it's not using a large number of goroutines.

> Do you have any benchmarks for the pattern you described where channels are more efficient?

https://go.dev/play/p/qXwMJoKxylT

go test -bench=.* -run=^$ -benchtime=1x

Since my critique of the OP is that it's a contrived example, I should mention so is this: the mutex version should be a sync.Atomic and the channel version should have one channel per goroutine if you were attempting to write a performant concurrent counter, both of those alternatives would have low or zero lock contention. In production code, I would be using sync.Atomic, of course.

On my 8c16t machine, the inflection point is around 2^14 goroutines - after which the mutex version becomes drastically slower; this is where I believe it starts frequently entering `lockSlow`. I encourage you to run this for yourself.

> Do you have any more details about this? Why isn’t sync.Mutex implemented with that same mutex channels use?

Why? Designing and implementing concurrent runtimes has not made its way onto my CV yet; hopefully a lurking Go contributor can comment.

The channel mutex: https://go.dev/src/runtime/chan.go

Is not the same mutex as a sync.Mutex: https://go.dev/src/internal/sync/mutex.go

If I had to guess, the channel mutex may be specialised since it protects only enqueuing or dequeuing onto a simple buffer. A sync.Mutex is a general construct that can protect any kind of critical region.

> What is the rule of thumb your Go shop uses for when to use channels vs mutexes?

Rule of thumb: if it feels like a Kafka use case but within the bounds of the local program, it's probably a good bet.

If the communication pattern is passing streams of work where goroutines have an acyclic communication dependency graph, then it's a no brainer: channels will be performant and a deadlock will be hard to introduce.

If you are using channels to protect shared memory, and you can squint and see a badly implemented Mutex or WaitGroup or Atomic; then you shouldn't be using channels.

Channels shine where goroutines are just pulling new work from a stream of work items. At least in my line of work, that is about 80% of the cases where a synchronization primitive is used.

And implying I don't understand toy examples and responding with this is apparently above the bar for serious discussion.

I'd like to refute the 'channels are slow' part of this article.

If you run a microbenchmark which seems like what has been done, then channels look slow.

If you try the contention with thousands of goroutines on a high core count machine, there is a significant inflection point where channels start outperforming sync.Mutex

The reason is that sync.Mutex, if left to wait long enough will enter a slow code path and if memory serves, will call out to a kernel futex. The channel will not do this because the mutex that a channel is built with is exists in the go runtime - that's the special sauce the author is complaining doesn't exist but didn't try hard enough to seek it out.

Anecdotally, we have ~2m lines of Go and use channels extensively in a message passing style. We do not use channels to increment a shared number, because that's ridiculous and the author is disingenuous in their contrived example. No serious Go shop is using a channel for that.

If you write an Erlang function in C you can actually call a function that lets the scheduler know you are willing to yield.

I'm worried readers of this article will be horrified and believe this kind of DIY error handling is necessary in Go.

The author has attempted to fix their unidiomatic error handling with an even more unidiomatic error framework.

New Go users: most of the time returning an error without checking its value or adding extra context is the right thing to do

Why are technologists trying so hard to make themselves redundant?

This is like the Luddites themselves creating milling machines, eager for the foreman to show them the door.

What gives?

I'm not a graybeard, I'm 28 and I've been using Emacs since I was 15. In that time, in my circle, I've seen notepad++, sublime, atom etc. all come and go. Of course everyone at work uses VS Code, in 2 years it will be New Editor by XYZ Corp.

Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?