awesan

It is a good default for lib code because it makes that code truly re-usable. The same is true for great C libraries, they let you provide a block of memory instead of calling malloc inside. The library should not get to decide if/when allocations should be done.

In Zig app code you don't have to pass allocators all over if you don't want to, that's your code so do what you want. But for libraries it's the right thing to do because it puts the caller in control.

The reason you have to pass allocators instead of making this implicit like in e.g. Odin, is because Zig just takes a firm stance against implicit logic, firmer than any other language I've ever used. The end result is that people who like Zig tend to like passing allocators around even in their own code.

In this context yes, but for example at my job we are using LLMs to evaluate some outputs of cheaper/simpler models and to add context to them. This gets expensive very quickly with per-token pricing and would pin our entire business on the whims of one or two providers. With self-hosted open-weight LLMs we can just operate like we always have, it's a different kind of processing but otherwise we are free to do as we please wrt compute.

So it matters a lot that these open-weight models are good enough; we would likely not be rolling out this new processing if it was fully dependent on Anthropic and OpenAI.

i dont think anyone thinks it's worth that on its own, but you need some kind of user management (entra id in this case), some kind of cloud storage (sharepoint in this case) and some kind of standard document format (docx, xlsx, pptx in this case) in any company.

of course you can do all that with open source stuff but office is just easy to buy and hard to get rid of once you have bought in. the bigger your company the harder it is to migrate.

I have some bias as a software dev/manager but at least in our org I noticed you can get a lot better value out of your tokens with some proper configuration of context and skills. Providing the latest models with good context can result in extreme savings.

After we started excessively documenting and extracting skills everyone has stopped complaining about running out of tokens, because agents stopped having to reconstruct the full context each time from scratch. Harnesses like claude code also push the model to aggressively keep this documentation in sync so there's little concern about drift.

The worst thing to do from a token usage pov is to give a model a vague open ended prompt because they are so scared to be wrong that they'll waste a ton of tokens "thinking" through the issue and verifying everything. Whereas they almost trust skills blindly and skip all this unnecessary work.

If it happens all the time and it's positive, you shouldn't need a news story to confirm it. People should just be able to think of examples.

Certainly I'm able to think of plenty of terrible results from private equity take-overs from my own personal experience as an employee or as a customer.

Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.

It's not the same thing as allowing some AI contributions under strict guidelines.

It's not strange to ban chess computers at a chess tournament, and it's equally not strange to ban AI code on a code hosting platform.

The costs involved with hosting a bunch of vibe coded stuff that no one is really invested in or cares about would undermine the mission of Codeberg, so it makes sense for them. Other code hosting platforms can go a different route.

Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.

Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".

You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.

OK, but that doesn't mean the comment I replied to is any less BS. What I pointed out is that if there was such a deep preference for short grass, you'd expect this globally. And this is simply not the case, empirically.

this is obviously bs, the lawn thing is mostly a north-american obsession. most people here in europe like shade and thus higher vegetation in their gardens.

How is using arenas complex? If anything it should make things simpler to understand to people who are not used to manual memory management.

Zig is adding native vectors including operator support, there are some recent issues/prs about this topic.

The general technique of SoA is pretty useful both in games and other applications, but of course I cannot speak to the specific use-case you are describing.

If a business legitimately needs such information to operate, isn't it borderline impossible to 100% prevent it from leaking? If the data is there, it can be compromised either by technical means or non-technical means.

The primary issues in my opinion are (1) businesses collecting and holding on to information they don't need and (2) businesses getting so large that they become prime targets by default.

In a world where pointless data collection was disincentivized and there were many small businesses instead of a few large ones, this problem would be much more localized and addressable. But of course this is a dream within a dream.

I can say at least for me at a small-ish company (~40 FTE) there has been a surge in internal productivity tools. Nothing to improve the end user product directly but a lot of tools to make processes easier and less error prone.

What would previously be janky internal dashboards or excel sheets are now actually nice to use tools. That said of course the maintenance cost of all that has yet to be discovered, and the ROI is questionable.