hresvelgr

Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.

Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.

People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work.

Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the popular notion it can't be done is backed only by incomplete anecdotes.

Should everything be written in low-level languages? No, that would be absurd. Is it a simple fact of life that not every person/team/organisation is capable of meeting certain standards of rigour? Yes. That's not to say anyone in the Bun team could not become sufficiently competent in the future. For whatever reason, current experience, incentives, and personal motivations did not make for a conducive environment to make Bun watertight in Zig.

You can just do that, and then Zig is really no less robust than Rust.

That's just it, using Zig required more rigorous engineering than the Bun team were capable of.

In the figurative sense it's highly versatile across contexts, but still replaceable. For example:

"Her optimism was load-bearing,"

versus:

"Her optimism was enduring."

Exactly the same meaning and connotation. It stands to reason that the terms with the most semantic flexibility will have preference across all contexts. So in response to:

maybe we should be learning from Claude rather than complaining.

I'd say let's not steer ourselves into regular language and keep some vivacity in our expressions.

Both points are specious. C disassembly is usually not an orthogonal translation of the structures in the code, usually due to optimisation.

In C you have loops, functions structs. All things that make no sense in assembly.

One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.

The condition that made this possible is that this task is well within frontier LLM capability and he had tokens to burn. Domain knowledge is separate to language semantics.

Except that said AI can now themselves use your software and find and fix bugs themselves, not to mention drive new features.

Anyone with sufficiently good taste in how to program effectively and architect will disagree with you on this. The short leash method is how you ensure good results when you're functioning outside of the training data. If you're even a modestly above average programmer this is afaik the only way to ensure fast, quality development with LLMs.

This again feels outdated. I think we're mving towards humans no longer needing to understand a codebase, and letting AI drive it.

I think you are perhaps unaware of a world of programming where AI is still woefully inept. I have observed very consistently in all languages with manual memory management frequent issues with handling it. Trust me, it's not as simple as sticking it in a loop with Valgrind.

I think the irony here is that LLMs are the ultimate tool for auto-didacts and people who love to learn independently, bar none. Using them to cheat is such a profound waste to me. I've beeen able to accelerate my learning thanks to LLMs, and it saddens me that the potential for this kind of personal enrichment is lost on most.

Stealing for me, but not for thee.

Ginger Bill, the Odin language developer, is openly hostile against package managers (he wrote a post called "Package Managers Are Evil") so he maintains his own wrappers of popular C libraries in vendor folder next to the compiler. That doesn't sound like a healthy ecosystem to me.

There are good reasons for this (supply chain attacks, dependency hell), and while Odin doesn't have a package manager it does have a concept of a package. There is nothing stopping anyone from downloading and adding them to a project, in fact Odin developers do this already. The Odin core library is absolutely massive and contains a lot of what you would need for most projects, vendor rounds it out. The purpose is to be batteries included so your project doesn't have to rely on as many dependencies.

I think zig is also highly opinionated but it always seemed to me that Andrew started from solid pillars

It's funny you say that, because I hold the same stance for how Odin was constructed, and the examples listed hold for Odin too. There is a lot about Odin's design that is consistent with Zig. Check it out, you might be surprised ;)

Odin on the other hand is just some developer's personal taste marketed as "Programming Done Right". So, if you disagree with any choice Bill made, you're not doing programming right.

What do you think every programming language is trying to do? Solve the issues of the author. Bill has strong opinions about programming, so he made a language and a reasonably successful one at that. Given the swathe of people who would just complain, it's refreshing when people try to instead better the world relative to their values. Say what you will, he does it because he cares.

Another language that is in a similar space to Zig that I think deserves more attention, particularly for funding is Odin. While I think Zig is a great language, there is a consistency of design and simplicity to Odin that makes low-level programming more ergonomic and enjoyable to me. While Zig boasts a lot of impressive projects, Odin was used to build the JangaFX suite[1].

[1] https://jangafx.com/

Great work, the examples look fantastic. I will say, it's misleading to put "without AI" in the title for you to then comment on your submission that you have in fact used it. While it may only be in a trivial capacity, you've still used it.

Most human editors are not given credit, why would it be any different for an LLM?

Ironically, Git is my preferred VCS. I have used Perforce Helix, Mercurial, and SVN. It is the best of the worst. I don't think anyone in the space has made a truly great product.

I see a lot of people trying to capitalize on GitHub's recent failings, and I feel like everyone trying to shoot their shot in this space is missing one key aspect: Git is a terrible TERRIBLE piece of software.

I have spent a considerable amount of time learning git, not because I wanted to, but because someone else in my team didn't and inevitably t-boned our repository with a proverbial freight train running commands they didn't understand. It is absolutely unacceptable for a program designed EXACTLY for the purpose of maintaining a history and backup of the evolution of a program to be so unwieldy and occasionally dangerous to use. We can absolutely do better than Git.

The new Toyota Prius looks better than this. I know beauty is in the eye of the beholder, but if Ferrari is being outdone on design by a common commuter vehicle it looks terrible.

This is a similar argument to "Dropbox is a feature, not a product" and it definitely rings true in this instance too. I remember the litany of applications that only supported sync through Dropbox. It had no ecosystem, it's saving grace was that no one yet was operating a service similar at that scale.

All the major AI companies are trying to manufacture their own ecosystems to become less disposable. They'll get away with it for a while, but only insofar as hardware prevents advanced use. Once we get that hardware[1] there will only be two types of AI companies: hardware manufacturers, and labs. Just like sync became trivial and ancillary, so will AI inference.

[1] https://taalas.com/the-path-to-ubiquitous-ai/

Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.

I would encourage everyone remotely interested in Zig to have a look at Odin[1]. If like me, you read that article and found yourself muttering "what the hell," then you might appreciate Odin's simplicity and design consistency.

I am definitely in the minority here, but I am not a fan of the kind of meta-programming that Zig and Rust offer, with Rust being especially atrocious. In the two decades I've been programming I can count on one hand the number of times meta-programming was an appropriate solution to a problem I had. Every time I reached for it, I got bit. There's a reason "when in doubt, use brute force" is sage advice, it may not be fast and glamorous, but it'll be a hell of a lot less opaque.

[1] https://odin-lang.org/

I think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.

There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.

I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.

If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.

[1] https://www.gingerbill.org/article/2025/09/08/package-manage...

You have better specs than I do and I'm running the same model almost twice as fast through GGUF on llama cpp. I'd try some different harnesses.

Anytype is a well-made product, but its data format is somewhat opaque and like Notion suffers from significant complexity. I switched to Obsidian last year, which while proprietary at least gives me the option to move my data somewhere else if I should need to. Anytype doesn't make it easy to get your data off its platform.

A fast, native markdown viewer for macOS built with Tauri v2, React, and markdown-it.

Since when is JavaScript native? Tauri may be using the system's web view but it's still a web view. False advertising.

a constant for every invention is my lifetime is "everyone else is only interested in puerile sex and entertainment, $LATEST_MEDIA is ruining us, 1984"

Every damaging invention in isolation isn't a big deal. The big deal is setting precedent and the accumulation.

not puerile consumption.

I agree, it's more akin to seeing how much sawdust one can put in a rice crispy before someone notices. No one wants to eat sawdust, nor is there a mindless desire to.

SDL3 doesn't support bindless resources and the plans to do so in the future are very loose[1].

[1] https://github.com/libsdl-org/SDL/issues/11148#issuecomment-...

While I agree that my view is narrow, the "best solution" in question is what we used to do, and it was fine. There are still many places that manually manage dependencies. Fundamentally automatic software versioning is an under-developed area in need of attention, and technologies like semantic versioning which are ubiquitous are closer to suggestions, and not true indicators of breaking changes. My personal view is that fully automatic dependency version management is an ongoing experiment and should be treated as such.

Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world.

Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it's no justification. Appealing to "the real world" in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs.

Automation of dependency versions was never something we needed it was always a convenience, and even that's a stretch given that dependency hell is abundant in all of these systems, and now we have supply chain attacks. While everyone is welcome to do as they please, I'm going to stick to vendoring my dependencies, statically compiling, and not blindly trusting code I haven't seen before.

Focusing on protocol and decentralisation is putting the cart before the horse. The reason why Twitter, and Reddit in particular work so well is because of sub-communities that form organically. More importantly, discovery was part of the value in using it. It's why every Mastodon community specific to one niche/subject is not very interesting, people are not one single interest, we follow someone we like for one reason, maybe it's they make cool art, then we find out they also make music too, then bam, you discover a new genre of music and the community around it. Decentralisation actively introduces friction into the most rewarding loop of the entire thing. Centralisation isn't the problem, it's just comorbid with shitty governance.

Startup punditry is a business niche being capitalised on and it's being regarded in this article like a commune of knowledge. It's mildly insightful entertainment literature, with customers. On a philosophical level it's absolute value is tainted by its existence in the market. Most things are, but it living in the context of entrepreneurial endeavours, it taints it substantially more than most.

I'm quite partial to Zed. Very snappy, and you can turn off all the AI features globally if you like.