rtpg

the comments are really not high-quality. There's a lot of words in places where only a few would be much clearer.

This isn't to say it's impossible to guide good context-aware commenting style from.an AI, but there would be much terser/usable comments on all of the weapons source for example.

The biggest problem with this stuff is, as usual, that the people guiding the AI don't know what "good" decomps etc look like IMO. AI tool usage tends to reflect ones own tastes and understanding.

I don't think they just used it for styling unfortunately, the entire thing felt like this.

Why can't people just write shorter bullet pointed lists of things and post that? Just post what you put into the AI!

Experimentally, at least one major programming language (Rust) places mutability into the type system.

Whether or not something belongs into a type system is ultimately determined by the type system. We can choose whether or not mutability is considered a part of a type.

> When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).

This is a bit too simplistic IMO. You're talking about name bindings, the article is talking more about things like interior mutability.

Rebinding a name is ... generally not a type system concern by my understanding.

This stuff reminds me of people who are full into XP and pair programming, where you end up agreeing to pull in more or less any work done by two people together. Not the worst model in the world.

I am disappointed by the "agent chat"-centric design for the future. There is important value in highlighting what's important, and jettisoning the unimportant. Written artifacts are good when they're nice and cut down. And it's not really about the sequence of events (well, most of the time)

Instead of "agent chat", I feel like a written page (that could be interacted with through agents) is a much more interesting way of working through a problem. Capture the final idea, and minimize the fluff around it.

And if nobody is going to read it anyways, why have the chat in the first place?

And of course the glib comment that I can't help but make:

> Teammates can ask the same agent why you chose a Mutex instead of an RwLock.

you know in this hypothetical neither human involved has much of any idea what is going on. Skill atrophy is real, folks! Be careful.

People rushing to throw a thing out into the world, rushing so much that they don't even bother to use it or look at it themselves.

The same people who are likely seeing tens of the same sort of pages and immediately closing them because "who cares".

I mean I guess I'm looking at this too. But at this point the most interesting projects in the world to me are ones with bad CSS.

Book covers, seeing what kinda stuff is being talked about, the general vibe of the space itself.

Lots of fun to be had wandering about, and unless you're looking at a thing where the script is really indecipherable you can kinda figure out what the topic du jour is even in foreign languages.

It's fun to look at book covers and imagine what's in the contents too.

I feel like this is close to a good idea.

What I would want to see is a version of this that lets me write an app that can write to the DB through an API, and then have a google drive-esque "host this for me" thing.

A focus on local-first really misses the point IMO. Like sure it's good it can be run locally, but really most people have a distribution problem. Be a distribution solution!

The thing I would do involves having the hosting just be available by dropping the capsule into the google drive/dropbox-y thing, and then having it be that you can just copy/paste the file to someone _and it carries over the data and everything by default_.

For a lot of people the "thing" is the app + the data. Sometimes you want to decouple them but a lot of times you don't want to.

I think it would be very rare for someone to want to share the single-file bundle just without data.

have there been any "here's a nicer wrapper API" services out there? Or is the complexity somewhat upstream of "real" complexity/differences in reporting.

> Faster GC by skipping image objects during marking

This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great

Right now the "subsidies" etc I think make the calculus really tough, but for general compute.... for example running CI just on a Mac Mini can get you real cost effective throughput compared to running CI on GH runners and whatnot.

Things get cheaper at scale but that's where the provider's margins come in!

I do think there's also an interesting idea: you buy a box like this and run it at a fixed-ish cost (well, electricity). Your demand goes up but your supply is fixed... and that back pressure means that you still have good cost control.

With cloud providers it's a _biiiiit_ too easy to just increase spend.

Sometimes it's OK for things to just be slow.

DGX Spark is a biiiiit costly but neat to hear!

Do you know what kinda throughput you’re getting on that kinda setup?

(I have a secondary problem of being “locked into” Claude Code by it being good enough for me, I’d probably need to investigate the other harnesses… my impression is other harnesses are a bit more aggressively OK with nuking your setup from orbit)

I'll take the opposite here. If someone put in frontier AI models from like .... last june I guess? in a box and let me run it with "decent" token throughput I would be happy.

I think it's worth acknowledging that the power of LLMs at this point is not really so much in the smarts, but in the coordination and the surrounding harness tech. "Written english" turning into sequences of commands[0]. The whole agentic "stuff" in general. Tools + coordination is the superpower. The reasoning... it doesn't have to be _that_ good for the rest of the stuff to work. On good codebases and infra, at least.

And I say this as someone who really would rather most of this stuff disappear!

[0]: programming is obviously text to commands, but there's a loooooooot of futziness that LLM reasoning has let us remove in some flows

> GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!

Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.

I get your overall point though

Sony's WF-C510s are $70. The APPs are one thing but the base airpods I never really found to be that amazing quality-wise.

The linkbud S's are comparable in pricing tho

Is there a good forum stack that is as moddable as phpbb was back in the day? Every Discourse instance I see seems _very_ similar so I've assumed there's not much of an interesting plugin ecosystem

Reading through the paper and...

This seems to be a bit of "we're throwing a _bunch_ of inputs into this machine learning set and then pulling out outputs". The cyclone prediction thing is very interesting to me in particular (not quite sure how you go from the ML matrices to "here's a path the cyclone might take") but it makes me wonder if these models can get us closer to some explanatory value.

I imagine a lot of predictive sciences are ultimately about mixing together a bunch of inputs to attempt to decipher some output. Do we end up being able to take stuff from here and figure out some new ideas about modelling the climate as a whole?

This isn't a super serious comment (and an opportunity for someone to speak up on this) but...

I've heard some commentary in the past that 5G interferes with data measurements heavily used for weather forecasts (something about satellite measurements?)

I remember being _very_ impressed like 15 years ago about how I would have _hourly_ weather forecasts (in particular around the rain) that seemed like magic! And then things... seemed to slowly get worse (at least in Tokyo)

a couple years ago I was chatting with a friend in Kyoto. They used to live in Tokyo and had made the _exactly_ aligned comment like: "I was used to the rain forecasts being not so accurate anymore. After moving to Kyoto they seemed to be quite good! And now they're also bad here. Am I cursed?"

I looked at some 5G rollout maps and you could see Kyoto rollout happened a bit around the time frame they were complaining about....

Anyways I think for most people (at least for myself) weather forecasting seems like this odd dark magic that can't work at all, but there was a window in which it _felt_ like it was super accurate. At least in my personal experience

Maybe a decade ago there was chatter in the Purescript land about FRP in an applicative context.

There's ways you can write your code such that you _know_ that certain blocks of code are going to be unaffected by input changes, and you can then use that information to reduce the scope of changes that need to be done, with only minimal costs to expressivity.

I think with a decently smart compiler (and of course the compiler simply treating a lot of stuff in a black box way) you can totally shrink down the amount of work a client needs to do to render React components, all without changing the semantics.

Of course any performance trick might change the actual sequence of events that happen, and in particular for libs doing fancy DOM manipulation, it's easy for those to rely on React's incidental behavior in a non-spec-confirming way.

But the main point her is that you can totally get to useful improvements on a subset of your React, while still leaving the rest of your components intact

> Classical music has been institutionalized, sent to the conservatory as a relic. A small segment of society has decided the ability to perform it is worth preserving, and devotes a sliver of capital to that end: training young people, and paying a few of the best players in the biggest cities to do it professionally.

I had a whole discussion with a German friend whose husband works in opera (this was after Chalomet's "opera as a dead art" comments) and their view was mostly that this view of the world does not hold for at least chunks of Europe. To their mind, there is still both active input into this space, support in this space, and there's societal support to some degree or another.

I don't know the realities on the ground, but that annecdote did make me wonder if I simply assumed that the world of classical music wasn't as dire if you leave the States, at least in terms of job stability.

The comparison to popular music is kinda funy too... plenty of pop musicians that don't live off of their music, right? Maybe we're not generating "Taylor Swifts of Oboe"s but I feel like the measure is more about the median (or even the 90th/95th percentile?) when it comes to art, rather than the top of the top.

project literally launched yesterday... come on

Yep it's not clear, and a bit of a case-by-case thing. Fortunately most codebases only need to do this in a handful of spots so you can really "just" look at a package and find a file that probably is safe.

For example, numba._version only imports standard library stuff so is probably good enough here[0]

It would be nice to have general querying capabilities here, of course. I just think that in practice there's at least a halfway-decent workaround in almost any real situation

[0] https://github.com/numba/numba/blob/main/numba/_version.py

That's only part of the puzzle. Your program needs to branch on whether the dependency is installed or not!

"Oh you don't have optional dependency? Then do X" needs to happen at runtime right?

I think this import flow tends to be the canonical one.

I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.

I think this is a legit read about the utility.

> why should predictors be so coddled by their observers?

I suppose that in the RIM example the predictor correctly identified causes and concerns. The timelines are off. But highlighting the causes are interesting to me, as a datapoint.

If someone says "hey there's a problem here", you can somewhat independently look at the problem and validate its seriousness on your end.

Some people in this thread are like "well the value is in the prediction", but from my perspective I'm thinking "the value is in the causal analysis". Because if you merely think the timelines are wrong you can easily just change numbers around.

Obviously Zitron is not "always right", and isn't getting all causal analysis right IMO. I do think he's bringing up things though.

My glib assumption is you do that, you spend a bunch of tokens, and you end up with the same sort of mess you had the first time around.

The sort of "eternal addition" glomming of code that leads to tears on older codebases... I don't really see why agentic development avoids this. And I think there are arguments that it _accelerates_ it (but I'm pretty open to nuance on that side of the fence)

> OpenAI’s frontier-model API price fell from $30/$60 per million input/output tokens for GPT-4 to $4/$20 for GPT-5.6 Sol, alongside major capability gains.

on this specific point: tokens aren't fungible between models right? Like the argument Zitron makes is that improvements in output are due to, glibly, using more tokens to get there. We see people turn on new models and instantly use up all their tokens.

Like the actual measure is more something like "for this specific task, did it cost less now to do it than it did 3 years ago with these AI pipelines" right? The token pricing isn't actually relevant in that discussion.

Here's two possible set of predictions:

- a list of predictions that are entirely wrong, from A-to-Z, and are not even resembling what ends up happening

- a list of predictions that are wrong, but where the underlying points are in fact interesting and have some predictive value, and it's just the "last step" that is wrong

For example, one person might say "oh it's raining in Dallas therefore I should buy some TI stock". And we'll say for sake of argument that they say that even though it's nice and sunny in Dallas at the moment.

Another person says "Oh its raining a lot in Idaho and that is going to increase potato yields and therefore I will buy McDonalds stocks cuz fries will be cheaper". In this hypothetical it turns out McDonalds buys all their potatoes from ... Kansas or something instead (and it's a specific kind of potato in a completely separate market)... but Idaho potato yields _did in fact go up_.

An even more straightforward point: the iphone 3GS comes out in 2010, people are very hyped, someone looks at how RIM _still_ hasn't gotten its shit together and declares "RIM isn't going to to be able to stay profitable 18 months from now, they're gonna have their lunch eaten".

Turns out that RIM still made a healthy profit in 2010. and 2011. And 2012. 2013 was their first loss in a while... and then it wasn't until 2014 that they really got kicked in the face.

The prediction was early, overestimated how long of a tail RIM would experience, but how wrong was it? Was the prediction of some utility?

I'm saying this... it would be helpful if _some_ more AI companies flamed out. In some sense he does himself no favors by focusing on the corps with the biggest war chest instead of the various AI companies that spend a bunch to go nowhere fast and then have just disappeared.

I remember finding a test online for "left-right blindness" that had a similar kinda busted vibe. It was literally something where you look at arrows going up/down/left/right and you have to press a thing to match it.

I wish I could find it again and run it across some cohorts, because it was quite fascinating to feel my brain suffer more on the horizontal arrows.

I used the lego mindstorms environment (scratch-based) way back.

It was quite excellent, along with stuff like Clik n' Play. Basically "event driven" + "blocks so you can't have syntax errors and other silliness" was very good for me.

I was thinking about this. Would it be possible for Anubis to have a code gen process that would make every deployment of itself sufficiently unique such that it's "annoying" to work around?

I do wonder about the premise as well: are people special casing for Anubis?