awesan

Databases traditionally have a "zero bugs" mindset; which is probably a good thing since they are obviously very critical components. Not to say that all bugs get fixed, of course but the mindset is different from average commercial product companies.

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.

What a strange thing to publish.. just don't use it if you don't like it? What is this even attempting to do?

The obvious reason is that most file formats used by writers, accountants, etc. are binary files which do not very much benefit from git.

Seems like you need an account just to try it.

In Zig, dividing by 0 does not panic unless you decide that it should or go out of your way to use unsafe primitives [1]. Same for trying to allocate more memory than is available. The general difference is as follows (IMO):

Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such as Odin, Jai, etc.) allow anything by default, but surface the fact that issues can occur in its API design. In practice the result is the same, but Rust needs to be much more complex both to do the proving and to allow the developers to ignore its rules.

[1]: https://ziglang.org/documentation/0.15.2/std/#std.math.divEx...

IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc.

Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.

I am sorry about that. What I am saying is that it's hard to trust the content given the context. And more so these articles are extremely verbose with a lot of BS in them, so it makes getting to the "content" a lot more work for me.

In any case I had one paragraph about the content and one side-note about the writing style. Every single reply except one focused on the side-note, including you.

It's nice that people are taking this up, and one of the main benefits of open source in the first place. I have my doubts that this will succeed if it's just one guy, but maybe it takes on new life this way and I would never discourage people from trying to add value to this world.

That said I increasingly have a very strong distaste of these AI generated articles. They are long and tedious to read and it really makes me doubt that what is written there is actually true at all. I much prefer a worse written but to the point article.

In general if you have the (IMO sensible) approach of taking as few dependencies as possible and not treating them like a black box, then for any error you can simply look at the call stack and figure out the problem from reading the code during development.

Outside of that, error codes are useful for debugging code that is running on other people's machines (i.e. in production) for and for reporting reasons.

I'm kind of on the same journey, a bit less far along. One thing I have observed is that I am constantly running out of tokens in claude. I guess this is not an issue for a wealthy person like Mitchell but it does significantly hamper my ability to experiment.

I have done the monte carlo thing in practice with a team and it works well under some conditions.

The most important is that the team needs to actually use the task board (or whatever data source you use to get your inputs) to track their work actively. It cannot be an afterthought that gets looked at every now and then, it actually needs to be something the team uses.

My current team kind of doesn't like task boards because people tend to work in small groups on projects where they can keep that stuff in their own heads. This requires some more communication but that happens naturally anyway. They are still productive, but this kind of forecasting doesn't work then.

I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.

It does make sense to highlight, because this kind of statistic is a very strong indicator that the market is not competitive. This is not a normal kind of profit margin and basically everyone except for Apple would benefit from them lowering the margins.

In normal markets there are competitors who force each other to keep reasonable profit margins and to improve their product as opposed to milking other people's hard work at the expense of the consumer.

If the AI generated most of the code based on these prompts, it's definitely valuable to review the prompts before even looking at the code. Especially in the case where contributions come from a wide range of devs at different experience levels.

At a minimum it will help you to be skeptical at specific parts of the diff so you can look at those more closely in your review. But it can inform test scenarios etc.

A lot of Dutch government and government adjacent services run on Microsoft Azure as well. Which is not the same level of concern, but it does mean the US government has access to that data.