i have tried variations of this many time, it personally doesn't work for me. the word flashes into my brain, and i can keep up with "reading" at high wpm's, but the whole sentence doesn't register. i am not seeing the forest because of all the trees.
Despite stated otherwise in the post, this is a personal attack.
Anyway, let's try to discuss something more technical: I predict Zig will lose steam, and in 2027, will lose relevance:
1) It's hardcore Anti-AI
2) It's moved to Codeberg
3) It doesn't have the momentum to sustain the disadvantages of these two decisions
The project will in max 2 years make a blog post, not admitting to their mistakes, telling themselves that Zig is a success, despite the industry having moved on.
They don't have a goal of becoming a popular language, though and will continue to work on it as long as there are donations.
They don't care about being mainstream and there are niche companies who appreciate Zig and donate.
> I'm hustling. I'm playing the game. I'm doing what it takes to make this thing mainstream and a viable, practical choice for individuals and companies. If you talk shit about Zig in public, I'm going to fight back. But I respect you. I see you. I understand you. I don't hate you. I would literally buy you a drink.
Reminds me of another language that I used to know...
For real though, if your goal as a language isn't to become popular then why should anyone learn it? Why should anyone spend their limited time building libraries in it when the language isn't likely to grow (and thus is more likely to disappear)?
To be honest, I'm also leaning this way, especially because of the hardcore anti-AI stance, so much that Zig will close security vulnerability issues on Codeberg if you mention that they were found with LLMs. I don't think that this is a good approach.
I also think Zig has a rough road ahead, but not because of AI or moving to codeberg. No, it's because Andrew isn't really a BDFL. He's at best a DFL. The project is already mostly closed off to external contributors.
It kind of reminds me of Elm in a way. Though I'm not expecting 6 years of drought just yet.
Linus attacked bad software, Andrew attacks the Thiel Fellowship, VC Foundings, and AI. There's little or no Linus there, pointing fingers at, and even when he does, he points at code he neither uses nor maintains. Linus don't give a shit about other people projects and businesses.
It's a conflict of core values, and you've demonstrated it here.
You have defined success (for a project, and possibly a person too) as solely 'relevance'.
Jarred would agree with you wholeheartedly, I imagine.
Andrew would ask you to leave.
It's okay to have different values and part ways.
It's not wise, however, to project your personal values onto other people, and judge them on those fabricated merits. You'll end up frustrated and confused more often than not.
Judge their choice of values. Judge them on their alignment with their chosen values.
As an example, Andrew doesn't like Jarred's chosen 'Silicon Valley' values, but thinks that Jarred aligns himself well with those values. This feels as a personal attack to you who also holds those values. And on some level, a person intimating you core values suck couldn't be more personal.
I have never once in my life cared about where a programming language kept its source and I think if anyone is using that as a basis for decision-making, they are truly a moron.
I don't care if it's on GitHub at all, it's not hard to work with any arbitrary git remote. CVS would be a weird choice, but it wouldn't be a dealbreaker on its own. Fossil or some other modern alternative VCS wouldn't be a red flag or weird at all.
But I wasn't talking about contributing to the language, which is a weird standard to use here since Zig isn't interested in outside contributors. I was talking about choosing a programming language for use for some professional or personal project. I don't give a fig what version control solutions the team chooses to use if the language is good and solves my problems, and I would consider it very strange if someone tried to argue that I shouldn't use some language because they put their code on a non-Microsoft owned server.
I generally agree with you that choosing something based on where it's hosted is dumb. I still think there could be an impact wrt a network effect.
The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.
I agree. It's possible in the future a project hosted on codeberg is a silent "stamp of quality". Though, I still think there could be impact wrt a network effect.
What I assume you mean is not the network effect, where more users of a product makes the product more valuable. That's still true for Zig as more users increase the ecosystem, funding potential etc. regardless of where the compiler source lives.
I think you mean to say something like barrier to entry for contributors? Where having to sign up for a new service will discourage some engagement with the core repo.
One funny thing is that if you go on codeberg and want to submit a PR to Zig, you can't. Because Zig's too big for Codeberg, and you're over your free quota, so you can't push your update to your fork.
Yes there are ways around it if you have patience, but what the heck!!
Worth noting that while it's absolutely unfortunate that we're hitting this Forgejo design flaw, AGit honestly is just a better workflow, and I (Zig core team member here, full push access to the upstream repo) have started using it for pretty much all of my PRs. There are a couple of small things I'd like to see improved about Forgejo's implementation of AGit, but IMO it fundamentally makes so much more sense than the two-step push-then-PR workflow (especially if you're an external contributor who would also need a first step of "fork the repo").
Your prediction is extremely short sighted, and I can only guess it is because of your extreme pro-AI stance, as well as not being part of the open-source community.
I do hope they keep their stance and philosophy though it is not the easiest with a BDFL governance. I do not have predictions though, it seems silly to try and do so when it will be a random chance outcome
Nothing against Pro AI but their stance on wanting to write code by hand is not bad either. AI does over complicate things and there's a lot of slop. For a systems programing language, AI doesn't sound like a right fit. I'm personally tempted to reduce the dependency on AI. IMO, after a while, the overall productivity plateaus.
Not every project needs "steam", "momentum", and "moving with the industry". This is the Silicon Valley mentality post is talking about. All of this is VC versus hackers. One side only cares about productivity and profits, other only cares about technical elegance and perfection.
If you bothered to actually learn just a little bit about the Zig project, you'll know that they are doing ok. They never cared about introducing new features at a fast speed, having lots of contributors, or getting corporate sponsorship, if that's not already obvious from the article. In fact, they intentionally keep a distance from all of that to make the project more sustainable and less prone to the whims of corporations.
Well thats why his prediction is interesting. Hes saying they wont be ok in a couple of years. Of course theyll be there, programming languages dont really die but theyll be a shell of what was once believed to be their potential, a superior replacement for C
Jurata | Software Engineer (Frontend/Fullstack) | Zurich, Switzerland | ONSITE | Full-time
Jurata is a LegalTech startup building an online one-stop shop for legal, accounting, and tax services. We help thousands of SMEs get fast, affordable access to professional support. Heavy focus on automation and AI.
We're looking for versatile engineers who thrive in a TypeScript environment and enjoy owning features end-to-end.
What you'll do:
Build and maintain Next.js frontends
Migrate legacy apps from no-code tools (WeWeb/Retool)
Deliver fullstack features (backend: Nest.js, Python)
Own problems from idea through release and monitoring
TypeScript and Next.js experience
Strong eye for design (you can build beautiful UIs without a Figma file)
You actively use AI coding tools (Cursor, Windsurf, etc.)
Builder mindset, comfortable working autonomously
Benefits: 25 vacation days, ESOP, free gym membership, team lunches, central Zurich office with snacks and drinks.
EU/EFTA citizenship required (or willingness to relocate to Zurich).
Apply: https://join.com/companies/jurata/15604453-fullstack-softwar... (mention HN)
i tried posting some of my articles here, but the didn't really get much interaction. however, someone else posted probably my most controversial article, and i'm happy to see that it had a nice discussion around it: source: https://news.ycombinator.com/item?id=46412578
interesting, the notation also implies 2005 and 2010 A.D and not B.C, or maybe the notation is about exactly A.D? either way, interesting choice if it was intentional. we say “year 515” without disambiguation right
i don't write shorthand -- i type really fast on my keyboard, summarizing what everyone said. i've had compliments about how efficient i am at doing this, so i imagine it's not a widespread skill. i believe this to be very trainable though, thus my post.
The Restate model depends on a long-running external orchestrator to do the "pushing". However, that comes with downsides--you have to operate that orchestrator and its data store in production (and it's a single point of failure) and you have to rearchitect your application around it.
DBOS implements a simpler library-based architecture where each of your processes independently "pulls" from a database queue. To make this work in a serverless setting, we recommend using a cron to periodically launch serverless workers that run for as long as there are workflows in the queue. If a worker times out, the next will automatically resume its workflows from their last completed step. This Github discussion has more details: https://github.com/dbos-inc/dbos-transact-ts/issues/1115
reply