Protty

Oops, forgot to enable DMs. The port is open now (& thanks for the support)

Ello timeline, Currently looking for work. If you need someone to sculpt computers into moving data around efficiently (databases, vms, backends, compute kernels), I'd love to chat.

@filpizlo @salty_grndpa memory-safety = no UB from memory op. Fil-C turns LLVM memory-op-UB into panics. Rust has its own lang-level memory-op-UB outside LLVM (shared-xor-mut ref liveness, strict provenance, !Unpin mut-ref aliasing). Plugging Fil-C to Rust isnt enough hence MIRI. Zig=LLVM re:UB so ok

@salty_grndpa Fil-C is completely memory safe. Rust isn’t (because unsafe). Zig isn’t (because uaf). You can make Rust and Zig memory safe by having them adopt Fil-ABI. Folks who understand memory safety know this. It’s not controversial

Now I do think that zig has lost the plot hard and it hurts because I initially like the concepts

@penberg memory safe = no UB from memory op. Fil-C: turn UB memory ops to panics for LLVM IR. Rust: safe-rust guarantees no UB, but there's still unsafe-rust that doesn't. "Rust not memory safe (enough)" prob means "unsafe-rust" since that's part of Rust.

I am catching up with memory safety discourse. Fil-C is memory safe because it turns invalid memory accesses to a runtime panic. Rust is not memory safe because it catches the same problems at compile time, unless you use explicit unsafe?

@filpizlo @dreamsofcode_io I run real rust programs; pulls in loads of crates but no C code,excluding libc ofc. AttackSurface here is unchecked mem-safety(unsafe) not security. Asked only about former for Fil-C & Rust, not special conditions(must be in prod or use C deps). "Fil-C safer" claim has asterisks

The point is, if you run a Rust program in production with Miri (which nobody does, but even if we ignore that) then the program’s attack surface includes every C dependency. And there will be many of those. Every real Rust program pulls in loads of C code. If you run a C program in production in Fil-C (something people do), then the programs’s attack surface includes only the Fil-C runtime itself. Therefore, Fil-C is safer. But this is a super pointless discussion considering that nobody runs Miri in production

I read this issue earlier this morning and kinda feel sympathetic towards Andrew. Bun’s rewrite to Rust has obviously impacted him (hence the “unlike Rust” comment). Whilst that part is petty, it does seem to be driving him to find a solution for Zig. Personally, I don’t think garbage collection is the right solution (1-6x perf impact), but even still, the fact he’s searching for one to improve Zig following one of its biggest negative events is commendable imho. Either way, will be interesting to see where he lands.

@filpizlo @dreamsofcode_io This seems unrelated to Rust itself. I thought the claim was that Fil-C was safer than (unsafe) Rust, which includes MIRI.

@kingprotty @dreamsofcode_io They’re not the same. If you have a C dependency the Fil-C does full capability tracking and checking, but Miri can’t.

@filpizlo @dreamsofcode_io They both crash the program at runtime-detected UB. Fil-C is definitely faster / more usable for prod, but does that detract from Rust having an option for similar safety guarantees?

@kingprotty @dreamsofcode_io Bad comparison. Miri is a checker. Fil-C is for production.

@filpizlo @dreamsofcode_io Rust includes MIRI; Are there edge cases that Fil-C traps against that MIRI doesnt? (esp. considering that MIRI handles data races, not just provenance races).

It’s necessary for those of us working on memory safety to pinpoint that we are doing something that isn’t like Rust, because Rust has an incomplete memory safety story while pretending to be memory safe (in the sense that internet experts will get upset if you point out Rust’s flaws). So for those of us who understand memory safety, it is 100% necessary to draw the “unlike Rust” distinction.

@protocolllo join zig discord

cc @kingprotty

I need a Zig mentor

@1_div_0 @antirez This has been my exp as well; Rigorously designing the higher-level view of the app/dataflow works, but then peek inside and it's holding locks over IO, copying megabytes worth of data accidentally, or (understandably) didnt employ some trick you know as someone more experienced

@antirez Last week I was working in a database and it coded something that was significantly less efficient than I would do. It wasn’t even a large change. If I didn’t read it, I would have never known that it was technically correct, but not what was desired. How does one deal with that?

It is my belief that many devs right now are not maximizing what they can do with automatic programming because they still look at the code. Doing it makes you the bottleneck. Your time is better invested in new ideas, QA, design, and asking yourself what is your goal.

@misterclayt0n @sibaiisaac Rust isnt a "correct" language. Its a "can't cause UB in safe mode" one. You can still have race conditions, leak memory, crash, etc. If the UB cases it addresses have been your primary failure modes, then it indeed can help with correctness.

@sibaiisaac because you can't out test bad language design. the bugs mentioned by the blog post should be not be possible in a correct language

to sum it up, in Andrew's vision: > original bun was slop > slop rewrite > jarred is a bad manager and bad engineer > he's happy bun is no longer in zig tho I'm not the biggest fan of the rewrite, bun's blog post at least made some valid technical points (and somehow tried to praised zig quite a lot), which illustrated how lacking zig is, while Andrew is just being hostile for no reason at all this reading feels like a complete waste of my time

@swerverx402 @penberg Zig development/leadership != Zig community. The biggest zig users are pretty unaligned, but they still use it because it's useful.

@penberg The hostile vibes from the Zig community in general is counter productive. Sorry not sorry it’s an excellent language for AI assisted low level work whether they like it or not. The language doesnt need the purists or Bun to be excellent. It already is.

I like the Zig language, even started to build Turso with it. But the attitude towards losing Bun feels so hostile, I get the vibe like they want to remain a niche language, which is a stark contrast to C which they want to replace.

@thjonml @charliermarsh > Nobody is rewriting anything in Zig or C 👋

@charliermarsh Nobody is rewriting anything in Zig or C, and it's going to be some of the worst Rust code you can imagine... but may still be an improvement over whatever it was ported from.

Entering an era in which there will be constant posts about how someone rewrote X in Rust or Y in Zig or Z in C, and they'll have nice-looking benchmarks and graphs, but you'll have no idea if it's at all good or usable

I naturally reason/design algs in pseudocode. Turns out LLMs have no problem working with it too. Allows writing minimal boilerplate Having fun with "pseudocode -> real impl" and "paper -> pseudocode" pipelines. It makes learning & testing new concepts/optimizations much easier.

Mind boggling to me that I can make a thing faster and there's always people that ask "but why?" What kind of mentality is that? The pursuit of excellence does not need justification. Also, I find in so many cases, we can't know the impact of an improvement until we do it. For example, one I've talked about before: Ghostty's high IO throughput has enabled terminal program (emulator and TUI) fuzzing at a speed thats incomparably fast to prior solutions. This has resulted in upstream patches to resolve issues in popular projects like btop, tmux, and more. Speed enabled that anecdotally example that lifted the tides of adjacent communities that don't rely on Ghostty technology at all. I didn't predict this. Make things better because they can be better and let the results naturally play out.

@malik672_ what wrong

is crossbeam ArrayQueue one of the worst lib and api ever ? Probably the worst I've seen

@swenlei56 @valigo Its convenient & the ordering is defined in most other langs. Here, it can just happen accidently: # define F(x) f(x, x) F(*ptr++)

@valigo why would you use a side effecting operation when giving a parameter in a function call?

In C, function arguments evaluation order is unspecified. gcc evaluates them from right to left, clang - left to right. This used to be a source of tricky bugs, but now -Wall flag catches it. Every time I see things like this I wonder if there are interesting ways to exploit it

loud incorrect buzzer sound for every L3d miss

@valigo @SolidBasis Should take a look at things like ControlNet, inpainting, img2img, regional prompts, and other forms of intentional visual generation. It's not that reductionist.

@SolidBasis > because you can definitely help shape things created by AI Yeah, just like entering your opponent's moves into the Windows 7 chess bot.

Calling yourself an AI artist is like calling yourself a chess player while letting Windows 7 chess bot make your moves

@nuoji No: #Anonymous-Struct-Literals" target="_blank" rel="nofollow noopener">ziglang.org/download/0.6.0… T{} is struct literal .{} is anonymous (inferred) struct literal For zig, it's 6y old now

Is the .{ … } syntax from Jai? If so I kind of forgot about it because Zig’s using that syntax SO MUCH.