p1necone

On one hand, yeah, I agree.

On the other hand, using AI to trawl through all the grunt work, experiments, and well trodden areas means I can crawl up pretty close to that giants shoulder and spend way less effort myself answering the actually important questions so I can stand on it.

(This isn't supposed to sound self aggrandising - the giants whose shoulders I'm standing on aren't very tall, and they probably have bigger brothers and sisters, but the idiom was too good of a match to pass up using)

I've been kinda disappointed with the $10 plan tier of the AI assistant. It looks good at first glance - shows you that it's doing a bunch of research, you can see which sources it's looking at etc. But then when it goes to report results on anything data heavy it makes a lot of mistakes with putting figures under the wrong headers, using incorrect values etc.

The last time I used it heavily was a few months ago so it might have gotten better, and I assume the more expensive tier where you can choose which models it uses might be a bit better depending on which model you choose. I much prefer just pointing my own local agent harness at a search api at this point though.

Building really low level stuff like this with OO primitives brings with it an initial feeling of disgust... but once you get over that it is kinda neat.

There's mostly people disagreeing with me in the comments, so I'll make a concrete prediction.

I reckon 5 years from now it'll be obvious that x86 is on its way out, and 10 years from now it'll be replaced by ARM in all but narrow backwards compatibility demanded use cases.

I also predict that the survival of both Intel and ARM as big players in the market is contingent on them switching in the same timeframe. If they don't, they're dead (of course, if they try to switch and botch it, they're dead too - but baking that into a prediction feels a bit no-true-scotsman esque).

I'm hopeful that manufacturers will ship regular socketable ARM cpus just like they do with x86 now, but who knows whether that will be the case or if we'll move more towards everything being soldered on all in one solutions.

Every once ubiquitous dead technology was selling well shortly before it wasn't, so not sure what your point is here.

That's what I'm saying - I think both AMD and Intel risk becoming obsolete dinosaurs if they keep focusing on x86, which is what they seem to be doing.

The vibes I'm getting are that x86 is on its way out - apple switched, and mainstream laptops are releasing with fast snapdragon chips - I'm thinking both Intel and AMD risk becoming obsolete if they keep focusing on x86 chips.

Anyone with insight into the industry know how much institutional knowledge would be relevant still with an ISA switch?

Yeah zig was definitely a big inspiration - implementing type system stuff as comptime code execution gives you a bunch for free that would otherwise be pretty tricky to implement.

I think they are essentially dependent types, I'm just coming at it from the "idiot with a laptop who hasn't read up on type theory" direction, and trying to fit everything into the "but what if it was just another place the user can write regular code" hole.

Usually when dealing with something like 'Union(BigThing, SmallThing)' you have to allocate sizeof(BigThing + tag) in most places anyway because you need to statically know the size so that it can be a struct/array member, live on the stack etc.

The only time you can get away with only allocating the 'real' size is if you're sticking it in its own separte memory allocation and using a pointer to refer to it in the aforementioned contexts. Which, to be fair, is a sensible thing to do if BigThing is very big, as opposed to just 'on the bigger end of sane struct sizes'.

To clarify I'm talking about what you'd do in a language implementation where the actual memory layout is opaque to userspace and bit twiddling optimizations aren't making things harder to understand for everything, not what you'd do when writing handwritten C code or an api where you expect people to access the memory directly. This isn't unheard of - e.g. from my research Swift does it, some C++ stdlib implementations do it.

(Related - the rest of the bag of weird tricks that Rust and Swift and presumably other languages use to optimize enum/union layout are pretty interesting - the tag bits actually take up no extra space in many cases).

One simple but non obvious (at least to me) trick when implementing tagged unions: put the union discriminator/tag at the end, not the beginning - that way a pointer to a union is also a pointer to the value, no need to increment the pointer to point past the tag after discriminating.

> special parallel type language is a huge amount of added complexity and source of pain

This was exactly what initially motivated me to write my own language. I was spending a bunch of time writing complex types in Typescript (for SQL query builder type stuff - essentially data schema -> TS type transformation) as what was essentially just a bunch of regular boolean logic and iteration that would be simple, but because the 'type' world uses a completely different syntax to the 'value' world it gets unreadable really fast.

My language was originally basically "what if Typescripts type system treated types as first class values and let you use standard syntax for interacting with them", but I've been finding various other rabbit holes to fall into along the way.

I'd be curious as to what is undecidable as a consequence of this, that sounds like something that's going to bite me in the ass at some point.

Tangential - on the 'use [] instead of <>' advice that you referenced in the post, I wish more languages would experiment with making types first class values that just get passed in regular () braces instead.

With erased static types, you can do arbitrary operations on types-as-values at compile time and just compile the static result into the runtime code, so it doesn't even cost anything at runtime to do this. Generic functions just turn into curried functions with the type params as their first param set.

My wip language uses '()' for 'always explicit params' and '{}' for 'can be implicit params', but both types and values can be passed into both (of course inference only makes sense for statically known types/values, so 'value' params in curly braces must be known at compile time and are treated like singleton types as well as their actual value in runtime code that uses them).

I know this is tech sector funny money and we do just disregard profit and judge companies on revenue alone, but the 5.5 models that just released are quite a bit cheaper than the 5.0 tier.

I wouldn't really be surprised if better model efficiency was part of the reason for a revenue stall, but I would also expect their costs to have dropped a fair bit too (although I have no idea whether that corresponds to an actual cost reduction or if it's all tied up in hardware and land that they already bought and will need to hit more utilisation of now.)

What is Anthropic actually building with all of that AI usage. Their only public facing products are Claude Code and the models themselves, are they just churning their codebase? Are there big internal projects?

I've never really understood the opposition to self-hosting.

As long as:

* Your language is the kind of language that suits compiler development.

and

* You support compiling to C or something so that bootstrapping doesn't involve an opaque binary or compiling 30 different git commits in a row.

What are the downsides exactly?

One non-obvious reason might be that it's the only handheld console with a natively 240p height screen. This means all the 2d ui elements will remain crisp at the same size as they would be on original hardware.

I've long thought that pure desire/drive is much more important than intelligence in just about everything, including things that stereotypically require intelligence like programming, math etc.

> "Sweden's clean energy capacity is fixed"

This is a weird assumption to make. Why would you assume they wouldn't just build out more capacity as demand increases?

They certainly aren't buying electricity from Texas, this feels like a tortured argument you're just making to retroactively support whatever opinions you have on the pros or cons of clean energy.

Have you tried letting AI agents make design decisions on their own? (technical or otherwise), in my experience you still need to properly understand what you want to get good results - you would need to have a deep understanding of all the potential warts, security holes, usability issues etc - developing a CMS via AI is still a substantial project.

More detail: at current prices gold is $133k USD per kilo - at that price transport costs would be such a tiny fraction of the value of the cargo that it wouldn't make any sense to pinch pennies - you'd want to go with the absolute fastest, safest option.

Gold is heavy sure, but its $/weight value is still much higher than basically any other cargo - the plane vs ship choice would be even more weighted towards the plane with gold than with most other cargo.

That'll teach me for trusting pricing information from Google ai summaries...

>I'm sure someone will point out some spec that's better on the PS5

They're not even in the same ballpark - the PS5 is more than an order of magnitude better in GPU performance.

Despite how much it does matter, RAM is not the only thing you need for running LLMs - that N150 is not going to run anything but really tiny models at any sort of reasonable speed - certainly nothing that approaches using all of its ram. The GPU in the PS5 is ~25x faster. And if you're running games the RAM doesn't really affect performance at all once you have "enough" for a given game.

You're right that you probably could build something quite a bit faster than a PS5 for the same price though - if you can build/find everything but the GPU for ~250 USD and slap a 16gb 9060xt (~25tflops @32bit compared to the PS5 gpus ~10tflops @32bit) in it for another ~350 USD it should theoretically do a better job - the GPU in the PS5 was on par with mid-high end PC GPUs on launch, but that was like 5 years ago.

Post it note in a drawer somewhere baby

The cost of the tokens used to output a typical academic paper length document is on the order of cents, even for frontier models. The vast majority of the cost is in the discussion leading up to that final output - there's no reason someone would try to produce a shorter paper just to save tokens.

My weird take: I wish Nintendo would ship an even less powerful system.

The switch and switch 2 are both just powerful enough that developers can release straight ports of their AAA titles that were developed for other systems, but at the cost of significantly degrading framerate/framepacing, visuals, nothing ever running at native resolution etc.

I would much rather it was more like the Wii and all their previous handhelds where the performance gap between it and the other contemporaneous systems was so big that developers had to develop bespoke games for the system, and ports had to be ground up rewrites.

Everything was so much more playable, and by buying those systems you had access to an entirely different library of games to choose from, rather than the current situation where it's just the first party Nintendo titles that differ from what's available on all the other more powerful systems.

Yeah I tried to daily drive Nix at one point pre AI and the ergonomics were just not a good match for me - perhaps I should try it again.

> The only insane thing about UB is that compiler writers took what everyone understand meant "the compiler emits what it emits and you get what you get" and turned it into "since it's undefined it means it can never happen so we can delete your null check".

This is the bit that seems insane to me. Some of the behaviour of C/C++ compilers when they encounter undefined behaviour seems less like 'this is undefined, we'll just do something vaguely reasonable given the context/produce an error' and more like 'ahaha, the user has fallen into our trap, lets fuck them up'.

Hence the 'specific to C/C++' part of that sentence. 'Undefined behaviour' is a probably unavoidable part of programming language design. The way that C/C++ interpret/handle it is batshit insane.