awesan

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.

I understand the goal of the spec. In my experience once some spec document gets adapted widely enough, there's a strong incentive to add new features to it, which renderers would then be compelled to implement. Before you know it, MD is a complicated spec that doesn't serve its original purpose.

In this case a few minor edge cases is really not a big deal compared to that (in my opinion).

It happened a bit differently; Atwood and friends simply came out with a standard document and called it "standard markdown", which Gruber then refused to endorse. Eventually after the series of blog posts and some back and forth they renamed the project "CommonMark", which it is still called today.

I am not sure (of course), but I think Atwood simply thought standardizing this format was so obviously valuable that he didn't consider Gruber might not want to work with him. In retrospect it's kind of nice that it didn't happen, it really keeps everyone incentivized to keep the format simple.

I feel like no one serious uses the uncle Bob style of programming anymore (where each line is extracted into its own method). This was a thing for a while but anyone who's tried to fix bugs in a codebase like that knows exactly what this article is talking about. It's a constant frustration of pressing the "go to definition" key over and over, and going back and forth between separate pieces that run in sequence.

I don't know how that book ever got as big as it did, all you have to do is try it to know that it's very annoying and does not help readability at all.

People have forgotten this, but he did the same with Windows Phone for a while at the very start of his time as CEO. His motto was "cloud first, mobile first" where cloud meant Azure and mobile meant Windows Phone. After some time he gave up and they pivoted into the direction he is now well known for, which was to focus on good developer tooling regardless of OS.

It definitely depends but it's useful for me. In general I find AI pretty useful when you can do a guided search in which you are personally able to discard bad paths quickly before they start polluting the context too much. I have pretty beginner linux skills but I'm quite technical overall and have a decent BS detector, so it's been useful for me.