dnautics

some builtins purport to work on simd vectors but actually just unpack the vectors and do their work per-element (e.g. running `@sin()` on a `@Vector(4, f32)` will unpack the vector, run `@sin()` 4 times, and then pack it back into a vector).

this is reasonable because there isn't really a generalizable "good way" to unroll trig functions for simd. if you really care about speed youre better off implementing to the precision you care about (you might not want full precision)

no macros in zig, but yes you could metaprogram it. types are first class values at compile time so you could do that sort of specialization if you wanted.

I write a plan.md that goes through multiple revisions

instrumentally, isn't this the same as just doing plan mode?

Plan mode is just a .md file in a 'well-known' location that is privileged to a certain spot in the kv cache (after the system prompt).

oops. thanks!

nah. the us certainly has a lot of inflated egos, but the mythology is not like that, consider abraham lincoln, Washington "cincinnatus of the west", paul bunyan, johnny appleseed, etc.

edit: misread parent

exmex is in texas, youre probably thinking of empex

popping inflated egos is the mythology of America

the thing is, as a pattern, footguns in zig are simple and easy to reason about (though they might be hard for an ADHD human to find). the compositional nature of rust sometimes makes footguns "hard to see" because they can be hidden behind layers of abstraction.

there is a potential future where an llm with unbounded patience would have an easy time literally walking through the zig code looking for one of the footguns might miss a footgun in rust because it's abstracted away. the ones in the stdlib should give you pause. what is hiding in some third party library's code?

:thumbs up:

classic "can't admit i was wrong" dismissal. nothing special.

yeah rust has no footguns. just dont try to mix clone with iter.

i will not, sorry. but ill probably be at exmex

for about half a year claude code had this obnoxious flicker problem. i almost quit and went to codex over it.

its refinement types which are a "superset of affine types" iiuc (you can construct a refinement type system that can represent affine types, plus more).

there is nothing special about zig that makes it fundamentally possible in zig and impossible in C.

the difference is that compiler architecture, some language decisions, well-designed stdlib, not having to contend with past decisions of a committee that overweighted backwards compatibility, take it from "jesus christ this is too much of a pain in the ass to bother" to "oh theres actually a path forward for one person and an llm".

As a concrete example. In C there is no "anointed allocator", sure, most people use malloc/free, but a broadly useful analyzer needs to be able to contend with any of a billion different patterns, and "oops I forgot jemalloc's mallocx" is not really okay (plus you gotta deal with weird things like errno, etc, and maybe some program uses jemalloc's free in some places and stdlib free in other places, how do you track that). In zig, sure, you could build a function that allocates off the stdlib path, but it's not unreasonable to "ban" that and force people to use the stdlib interface, and most dependencies will be compliant. Hopefully you can see how this "jesus christ i don't want to deal with all that" vs "a clean path forward".

not suited for real world use.

I hope you don't use discord or rely on pagerduty.

i hired a biologist (for my pharma startup) and she produced feature ideas for our internal stack and was guiding claude to write idiomatic code with feedback from my reviews with no coding experience. realistically if you want to start an elixir company today you need one consciencious senior that likes code review and any number of juniors with minimal competency and sufficient curiosity.

i ran a quick experiment where instead of doing boxing the way its done in the beam currently, i used a different boxing (NaN strategy and there was a 10x speedup

its been fun building a multiagent personal assistant.

(wip, no guarantees, this is the engine i use)

https://github.com/ityonemo/ce_ce

the Zig team would almost certainly build it

1. It's a small team.

2. The zig team is parsimonious about what they do and don't build. For example, they did not work on the language server, rather punting it to the community.

3. That you can do this with the zig compiler is a happy accident. The team was not designing towards this possibility, it's not really a part of the core zig ethos (and that's fine).

4. You certainly cannot do things exactly the way that rust does it without changing the language; because the rust conversation has sucked all of the air out of the discourse around safety, you really do have to make a paradigm shift away from "tagged ownership" to "data dependency tracking with ownership agnosticism" to do it with zig.

do you want a direct description of the plan for async/alias work? hash the globally accessed gid list and if any operation changes retrigger analysis of all functions in the same execution block with the new layout.

i have not had to change the language to accomodate uaf/df/leak analysis (which is not easy). i see no reason why i should have to to get async/alias to work.

unlike rust, as of zig 0.16 async conceptually is abstracted to a userland interface in the stdlib (versus a keyword), which means that its easier to detect, and easier to work into the existing clr system. that means it's either "not doable at all" (unlikely) or is unlikely to need any back and forths to be done with the language

You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine.

that may be true, but it seems "not". to date, all of the patterns in zig-clr nudge you towards idiomatic zig and not away from it. i run tests on not-my-code (an unaltered version of an existing zig project -- you can see it's vendored in the "vendored/validate"), and it passes. still working through forestmq.

and I'm planning a mechanism to let you reach into a function and "oracle" its safety parameters, probably most useful when someone else has written code that you know is ok but you cant tell them "hey make this work to pass my linter"

Also remember that zig compiles as a single compilation unit so even if you draw in zig dependencies, unless they are hidden behind a .so, zig-clr will analyze the dependency code too.

did you miss this part?

planned to be addressed

i have in mind a strategy to address all of them. this is a side project, a proof of concept, i have other things going on in my life. i dont chip away at it every week.

you make, without any evidence ("Obviously"), an assertion that "it would look like another language". so far if anything applying zig clr would push a user to write more idiomatically ziggy code, away from idiomatically c-ish code. i dont see why continuing with clr wouldn't go further along that trend. so consider what is "obvious" to you might just be flat out wrong.

It might be an interesting language worth exploring.

worth how much? youre welcome to sponsor my exploration and put your money where your mouth is:

https://buymeacoffee.com/vidalalabs

1. it is possible to do code annotations in zig even though i havent implemented it in this iteration of clr (the first poc demonstrated this). i want to see how far i can get without them.

2. let's take double free (easiest to explain).

you dont have to tag ownership, you can be agnostic about who should free, and merely report if two nondisjoint code paths attempt to free the same memory.

it is possible to do in-code annotations in zig, if you're clever. you can get pretty far without them too.

as an example, you can check for double free without ownership tagging, by being agnostic about who should free, and flagging if two nondisjoint code paths attempt to free the same allocation.

start by examining zig-clr

no thats not the definition of more expressive. more expressive means the language can encode more programmer intent without making a dog's breakfast of the code.

1. rust didnt invent affine ownership. 2. It's possible to bolt on to other languages (see ada). zig in particular is easy (disclaimer: i think, i haven't implemented it yet)

i dont understand the downvotes here. the point of any safety checker is to flag and ban potentially unsafe code, and force the author to rewrite with existing language patterns that guarantee the desired safety parameters.

in this case, zig has a first class nullable syntax that the checker can use ti guarantee correctness for, so a checker can deterministically sidestep this turing completeness issue, by squeezing indeterminate code into the knowably safer language idiom.

intermediate representation. attempting to analyze zig code directly would be too hard (especially with comptime). on the way to the compiler backend, the compiler builds a simplified representation that only has "actually existing functions" and is very straightforward, e.g.

    function 10112:
    0: argument 0
    1: argument 1
    2: argument 2
    3: add 0, 1
    4: store 2
    5: call function 1342, (2, 4)
    6: return 5