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.
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.
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.
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.