weebull

I found that they didn't want to call tools in the same way as other models, and it led to bare tool calls in the response.

...or...just hear me out now...we could limit it in the harness.

Don't give it shell access, just predefined tools.

Two different philosophical approaches with Zig and Rust.

- Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can.

- Rust: let's make the compiler the guardian of what is safe to do. Unless the developer hits the escape hatch, we will disallow behaviour to keep the developer safe. To allow the compiler to reason about safety we will have an intricate type system which will contain concepts like lifetimes and data mobility. This will get complex sometimes so we will have a macro system to hide that complexity.

Zig is a lot simpler than Rust, but I think it asks more of it's developer.

Clock rate isn't the only factor. A design can be power hungry at a low clock rate if designed badly, and if it it is... you're never getting that think running fast.

All of those things are solved with modern extensions. It's like comparing pre-MMX x86 code with modern x86. Misaligned loads and stores are Zicclsm, bit manipulation is Zb[abcs], atomic memory operations are made mandatory in Ziccamoa.

All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appropriately before making comparisons.

Wtf‽ I didn't know that was possible.

> Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI?

That's what happens when you vibe code your app.

Given that Mandarin has many forms of "yes", isn't the problem that all those forms map on to our singular "yes". For a native speaker "yeeeessss" means something very different to "yes", but they would use a different word.

Knowing which is being spoken or heard is going to be hard.

How about we leave "...shoring" alone?

> Question: Did photoshop kill photography? Because honestly, this AI discussion to me sounds very much like the discussion back then.

It killed an aspect of it. The film processing in the darkroom. Even before digital cameras were ubiquitous it was standard to get a scan before doing any processing digitally. Chemical processing was reduced the minimum necessary.

> Why you think the net was born? > Porn porn porn

My biggest complaint is there's no way to name a signal because a wire isn't a thing. You instance gates and give those names, but wires are anonymous connections between gate pins.

I think this is backwards. Knowing that a signal is the clock, reset, data valid, adder result is far more important than the gate that drove it. The gates barely need names. Sadly, I think starting with that concept leads to a rather different language.

I think it's more likely you become a danger for others. A safe space for malware

If you're using dlopen(), you're just reimplementing the dynamic linker.

As Blair got most institutionalised to the world of politics he became more and more authoritarian. Starmer appears to be listening to Blair who is now even worse than he was as PM.

Labour generally has a "paternalistic authoritarianism" to they way they govern, but this is dialed to 11.

> "We don't need destructors, defer/errdefer is enough" is Zig's stance, and it was mostly OK.

There's more than that. Zig has leak detecting memory allocators as well, but they only detect the leak if it happens. Nobody had a reliable reproduction method until recently.

A 50-ish MB build time dependency that doesn't need any special privileges or installation to run? That's over engineering? A binary release of just CMake is bigger than all of Zig.

There's one area I wish we did differently which I think is a hang-over from big-endian. It's the order of bytes when we write out hex dumps of memory.

You'll always get something like this:

``` 00000000 : 00 01 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

On a big-endian machine, when you wrote 0x1234 to address 0x0000000 you got:

``` 00000000 : 12 34 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

On a little-endian machine you have to either do mental gymnastics to reorder the bytes, or set the item size to match your data item size.

``` 00000000 : 34 12 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

If we wrote the bytes with the LS byte on the right (just as we do for bits) then it wouldn't be an issue.

``` 00000000 : 07 06 05 04 03 02 12 34 00000008 : 0F 0E 0D 0C 0B 0A 09 08 ```

> - we have authentication everywhere in our stack, so I've started including the user id on every log line. This makes getting a holistic view of what a user experienced much easier.

Depends on the service, but tracking everything a user does may not be an option in terms of data retention laws

> Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does.

Not like Rust does, no, but that's the point. It brings both non-nullable pointers and bounded pointers (slices). They solve a lot of problem by themselves. Tracking allocations is still a manual process, but with `defer` semantics there are many fewer foot guns.

> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

The jump from 2 to 3 is smaller than the jump from 1 to 2, but I generally agree.

It is intended for release builds. The ReleaseSafe target will keep the checks. ReleaseFast and ReleaseSmall will remove the checks, but those aren't the recommended release modes for general software. Only for when performance or size are critical.

And hardware access. You absolutely can't write a hardware driver without unsafe.

I personally feel the Zig is a much better fit to the kernel. It's C interoperability is far better than Rust's, it has a lower barrier to entry for existing C devs and it doesn't have the constraints the Rust does. All whilst still bringing a lot of the advantages.

...to the extent I could see it pushing Rust out of the kernel in the long run. Rust feels like a sledgehammer to me where the kernel is concerned.

It's problem right now is that it's not stable enough. Language changes still happen, so it's the wrong time to try.

So if you're writing a device driver in rust...

- Hardware access is unsafe - Kernel interface is unsafe

How much remains in the layer in-between that's actually safe?

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`.

In my mind, the reasoning for rust in this situation seems flawed.

Learn rust to a level where all cross language implications are understood, which includes all `unsafe` behaviour (...because you're interfacing with C).

Yes it does.

That just highlights that the way people are interpreting the word `master` is wrong. You've named your most important branch "teacher".

I hope you never come across a repo that has an old out-of-date `master` branch, because they moved to using `main` in a bad way.

Master of Puppets -- Metallica

To be fair, the song is about control and the abuse of power.

I'm also wondering what payload people want. There's already an error handling trace (similar but different to a normal stack trace) that captures the how the error propagates up to the point it's being handled so shows you exactly where the initial point was.