weebull

The key point is, it's not language magic. It's library magic. You can write your own IO implementation if you want it to work a different way.

The human failure appears to be mistake number 3 or 4.

1. Automated system fails 2. Decision is made to run the system manually 3. Iyro train fails to move on when instructed (Comms failure?, train failure?) 4. Controller uses imprecise language when instructing following train.

To say this is totally down to 4 is to scapegoat the last link in the chain.

Honestly, to blame the controller after the automated system has failed is pretty low. The system does not run this way normally for good reasons, and whilst the controller maybe trained to handle the situation they won't be well practised at it.

The primary reason is computer failure followed by the decision to run the system manually.

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.