is groq still using 6 racks to serve Llama3-70B or is that old news?

The new chip isn't out yet so that's the only thing they could be doing.

yeah but you dont have to proof check every cycle, anyways rust safety is not the slow step

Definitely not python. at least in the immediate future, context is the limiting factor, and not knowing if a function call might mutate your object is not good for context (the llm must either dangerously assume or look it up, both of which are context-expensive)

sure but it would be really weird if there wasn't one

Look at SpaceXs filing. There is one but it is super short. I was just pointing out that 365day lockup is likely incorrect and OP doesn’t really know that until the filing is approved and becomes public.

i mean spacex filing reads more like an investor prospectus than an s-1 so, its a few standard deviations off the norm

It's in the article.

> you can implement your own version that internally checks a build-time flag, approximating C/C++ behavior

"you can specify that a pointer"

i dont think you need to specify that. the compiler can figure it out and do an optimization pass at the end.

Oh, is it not a specific keyword? I thought they were thinking of it being a keyword so you could be sure that it was restricted, in case a variable or function was exported that took in a foreign pointer.

There are going to be builtins to control this. The compiler will not do it on its own.

what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.

They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md...

which applies to contributing to the Zig project.

The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/

"Anti-AI stance" is painting it with too broad of a brush. You're definitely not breaching any CoC or whatever by using AI for your Zig projects.

And the largest Zig projects all make use of AI assistance to build software.

tigerbeetle does not, but the others do.

Yes, of course, I'm sure no developer there ever uses ai assistance...

> too broad of a brush

yes, that was my point. as domeone who uses ai extensively to write zig (and someone who has made very small non-AI cobtributions to zig in the past), rejecting ai is currently a strategically good decision for core zig.

idk, making @cImport just "@import" is an improvement imo.

`@import` that you have to configure in the build system first.

this makes porting projects gradually, file by file, rather cumbersome. now I have to rewrite quite a lot of Chocolate Doom because my port was halfway there and then @cImport got gutted... or keep going with Zig 0.16.2 until it's either 100% Zig or has little enough files that upgrading won't make my build.zig file implode in lines of code

i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?

if youre doing io, one pointer indirection seems unlikely tp be rate limiting. same for allocation (the other dynamic dispatch in zig)

It's not just I/O, it's also mutexes, condition variables, time, etc. It's not horrible, but it does add up, so calling it super efficient is a stretch.

A modern allocator with per-thread cache can satisfy some allocations in 20-30 cycles - dynamic dispatch can easily double that, even if the target is still in cache.

It's one of these things where it's extremely use case dependant - like many performance issues, you probably don't care about it - but when you do it matters.

Inderect call cost is a few cycles, if predicted. Now, you can argue, that it may be mispredicted and misprediction would cost about 20-30 cycles. But if it is mispredicted, then you are not calling into allocator often enough. And if you don't hammer it hard, then why do you care about preformance?

this was the general motivation for my project zigler:

https://github.com/E-xyza/zigler

Very cool use of Elixir! I have been considering the Fig Stack (F# + Zig) myself, so I'm excited to see Zig being paired with a Functional Language