frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Show HN: AI-Powered Merchant Intelligence

https://nodee.co
1•jjkirsch•1m ago•0 comments

Bash parallel tasks and error handling

https://github.com/themattrix/bash-concurrent
1•pastage•1m ago•0 comments

Let's compile Quake like it's 1997

https://fabiensanglard.net/compile_like_1997/index.html
1•billiob•2m ago•0 comments

Reverse Engineering Medium.com's Editor: How Copy, Paste, and Images Work

https://app.writtte.com/read/gP0H6W5
1•birdculture•8m ago•0 comments

Go 1.22, SQLite, and Next.js: The "Boring" Back End

https://mohammedeabdelaziz.github.io/articles/go-next-pt-2
1•mohammede•13m ago•0 comments

Laibach the Whistleblowers [video]

https://www.youtube.com/watch?v=c6Mx2mxpaCY
1•KnuthIsGod•15m ago•1 comments

I replaced the front page with AI slop and honestly it's an improvement

https://slop-news.pages.dev/slop-news
1•keepamovin•19m ago•1 comments

Economists vs. Technologists on AI

https://ideasindevelopment.substack.com/p/economists-vs-technologists-on-ai
1•econlmics•21m ago•0 comments

Life at the Edge

https://asadk.com/p/edge
2•tosh•27m ago•0 comments

RISC-V Vector Primer

https://github.com/simplex-micro/riscv-vector-primer/blob/main/index.md
3•oxxoxoxooo•31m ago•1 comments

Show HN: Invoxo – Invoicing with automatic EU VAT for cross-border services

2•InvoxoEU•31m ago•0 comments

A Tale of Two Standards, POSIX and Win32 (2005)

https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
2•goranmoomin•35m ago•0 comments

Ask HN: Is the Downfall of SaaS Started?

3•throwaw12•36m ago•0 comments

Flirt: The Native Backend

https://blog.buenzli.dev/flirt-native-backend/
2•senekor•38m ago•0 comments

OpenAI's Latest Platform Targets Enterprise Customers

https://aibusiness.com/agentic-ai/openai-s-latest-platform-targets-enterprise-customers
1•myk-e•40m ago•0 comments

Goldman Sachs taps Anthropic's Claude to automate accounting, compliance roles

https://www.cnbc.com/2026/02/06/anthropic-goldman-sachs-ai-model-accounting.html
3•myk-e•43m ago•5 comments

Ai.com bought by Crypto.com founder for $70M in biggest-ever website name deal

https://www.ft.com/content/83488628-8dfd-4060-a7b0-71b1bb012785
1•1vuio0pswjnm7•44m ago•1 comments

Big Tech's AI Push Is Costing More Than the Moon Landing

https://www.wsj.com/tech/ai/ai-spending-tech-companies-compared-02b90046
4•1vuio0pswjnm7•46m ago•0 comments

The AI boom is causing shortages everywhere else

https://www.washingtonpost.com/technology/2026/02/07/ai-spending-economy-shortages/
2•1vuio0pswjnm7•48m ago•0 comments

Suno, AI Music, and the Bad Future [video]

https://www.youtube.com/watch?v=U8dcFhF0Dlk
1•askl•49m ago•2 comments

Ask HN: How are researchers using AlphaFold in 2026?

1•jocho12•52m ago•0 comments

Running the "Reflections on Trusting Trust" Compiler

https://spawn-queue.acm.org/doi/10.1145/3786614
1•devooops•57m ago•0 comments

Watermark API – $0.01/image, 10x cheaper than Cloudinary

https://api-production-caa8.up.railway.app/docs
1•lembergs•59m ago•1 comments

Now send your marketing campaigns directly from ChatGPT

https://www.mail-o-mail.com/
1•avallark•1h ago•1 comments

Queueing Theory v2: DORA metrics, queue-of-queues, chi-alpha-beta-sigma notation

https://github.com/joelparkerhenderson/queueing-theory
1•jph•1h ago•0 comments

Show HN: Hibana – choreography-first protocol safety for Rust

https://hibanaworks.dev/
5•o8vm•1h ago•1 comments

Haniri: A live autonomous world where AI agents survive or collapse

https://www.haniri.com
1•donangrey•1h ago•1 comments

GPT-5.3-Codex System Card [pdf]

https://cdn.openai.com/pdf/23eca107-a9b1-4d2c-b156-7deb4fbc697c/GPT-5-3-Codex-System-Card-02.pdf
1•tosh•1h ago•0 comments

Atlas: Manage your database schema as code

https://github.com/ariga/atlas
1•quectophoton•1h ago•0 comments

Geist Pixel

https://vercel.com/blog/introducing-geist-pixel
2•helloplanets•1h ago•0 comments
Open in hackernews

Zig 0.15.1

https://ziglang.org/download/0.15.1/release-notes.html
107•captainhorst•5mo ago

Comments

coffeeindex•5mo ago
Seems like a lot of changes to be a .1 release, no?

Really excited for I/O as an interface!

do_not_redeem•5mo ago
Those were all changes in 0.15.0, but we snuck a few bugfix PRs in for a quick patch release before Andrew finished writing the release notes ;)
squeek502•5mo ago
0.15.0 was effectively skipped: https://github.com/ziglang/www.ziglang.org/commit/1be0f80b15...
meepmorp•5mo ago
yeah, some jerk filed a windows https bug after the release had been tagged
matu3ba•5mo ago
Excellent news. Will be very interesting how the debugging experience will improve with scheduling, recording of io and reversal computing between io.
Graziano_M•5mo ago
> a better appraoch—less prone to typos and bitrotting

Clever irony if intentional!

johntash•5mo ago
Can anyone sell me on learning Zig vs Rust? Not for work, just some personal projects I thought about doing in Go but decided learning Rust instead might be fun.
horenso•5mo ago
Try a few different languages to see what fits your style. I'm a fan of both Rust and Zig, but I've been really enjoying Zig lately.

Rust has a cool concept called ownership to prevent memory bugs. This means you have to learn new ideas like lifetimes. For instance, an array doesn't just hold objects; it has a lifetime of its own, so you can only store references that will last at least as long as the array. It's most useful IMHO for programs with many independent lifetimes because it makes writing memory-safe code much easier. It really leans into the concept RAII which comes from C++. You implement types and define what it means to create, copy, "move" and destroy them.

Zig on the other hand feels incredibly lightweight. It's like C, but with way fewer pitfalls and better tools. For instance, tts default DebugAllocator tracks memory leaks at runtime, which is good enough for many situations and makes the language less complex to work with. It is common in Zig to pass Allocators, which makes you think more about pooling allocations and simpler allocation strategies. I think learning low level concepts like memory management, pointers, memory layout, interfacing with the OS etc. is easier is fantastic in Zig.

johntash•5mo ago
Thanks! I probably will end up trying both at least a little bit.

Rust's memory management did sound neat when I was reading about it. Rust is also more mature, so probably more useful for now. I really like Go's simplicity though, which makes Zig sound interesting too.

I also just remembered Nim. I didn't get very far with it, but it also seemed cool.

your_fin•5mo ago
Very roughly, Zig is much closer to Go in terms of philosophy of language design, where as Rust is much closer to Go in terms of the kind of software people write with it.

Go and Zig are both aggressively small and portable languages, and e.g. prefer explicit `defer` where Rust would handle cleanup implicitly. Unlike Zig, Go and Rust are both widely used and mature ~tier-1 languages with a deep bench of native libraries. However, there's a deep gulf between their philosophies. Go values a shallow learning curve and making code easy to write, whereas Rust values expressivness and making it hard to write bad code. This is not to say that you can't write Good Software in Go or make money with Rust code. However, the languages tend to attract distinct groups of programmers, and there's a reason flamewars crop up between their proponents with unusual regularity.

Zig is notable for targeting C's niches of having lots of structural flexibility in memory management, being good at calling C code, and building C programs. C is the native language of most truly powerful interfaces (operating systems, graphics, cryptography, databases, other programming languages, device drivers, low-level networking, etc.), and programs primarily concerned with interfacing with such things tend to be better off written in C. Working with C code is in the happy path for Zig, while other mainstream programming languages demand significant specialized expertise or wrapper libraries (1). Wrapper libraries aren't always available, are almost always less useful than the original, and only save you /some/ build headaches. This makes Zig a candidate in many situations where C - and /maybe/ C++ - are the only real competition.

In short:

If your interest is learning new ways to think about writing programs, Rust will give you a more distinct perspective than Zig. Like Go, there will be lots of libraries and guides to help you out.

If your interest is in learning to write a kind of program you couldn't in Go and think "closer to the metal", Zig is likely better suited to task.

(1): This isn't nearly as true for C++, but there's still enough impeadence mismatch between idiomatic C and C++ to invite interfacing bugs and wrapper libraries.

johntash•5mo ago
Thanks for the explanations!

I do really like Go's simplicity which is part of why Zig sounded interesting to me. Rust is definitely more mature though and "feels" more useful from the outside, but that could also just be all of the "I rewrote X in Rust" projects out there.

I'm surprised to see that Zig is closer to C than Rust, and also surprised that rust isn't _more_ like go. I'll probably start with rust just to try something different.

Like another commenter mentioned, I'm probably going to end up making a couple toy projects in both just to try them out. I don't have much of a reason for either of them at work, so it's just for personal projects and knowledge.

baranul•5mo ago
Other languages are much closer to Go than Zig. A few are Vlang (highest percentage), Odin, and C3 (in terms of how Zig is compared). In terms of C interoperability, C3 (highest percentage) and Vlang make this a strong feature of their languages too. All, in this group, have aspirations of being used "closer to the metal". For instance, there is the Vinix OS[1], from Vlang.

Rust coming across as a bit different, from those used to C family languages, has arguably a lot to do with its OCaml[2] (ML) roots.

[1]: https://github.com/vlang/vinix

[2]: https://en.wikipedia.org/wiki/OCaml

darknezx•5mo ago
I'm in the same spot as you, just started Zig a month back, but the lack of starter-level guides is quite rough IME. And just when I got a hang of some of stdlib there were major changes. I guess that's the life is learning a work in progress <1.0 language :(
johntash•5mo ago
That's a good point I didn't think of, Zig is more likely to have breaking or at least major changes. I guess it doesn't matter too much for personal stuff, but I probably am less likely to want to go back and update things unless I use them often.

What'd you think of Zig with what you've done so far?

ivanjermakov•5mo ago
Coming from webdev land, I had to closely work with Rust to appreciate the design of Zig. Try both and see what sticks.
ksec•5mo ago
Sort of off topic but I really wish Zig would put Date in their release notes.

For instance I didn't know if 0.15 is new, or from a few months ago. Every time a new release I had to go to Github and check the release date. It doesn't even need to be exact but something like August 2025 would have been fine to give some context of when this was released.

> - async and await keywords removed

I think by all accounts Andrew has continue to show he is extremely pragmatic with every decision, trying to test new and old theories to the limit and pick what is most coherent and best for Zig. Cant wait for 1.0

MaskRay•5mo ago
I don't follow Zig's development. https://ziglang.org/download/0.15.1/release-notes.html#Motiv... feels vague to me, and linking to a lengthy video isn't very clarifying. Still, I skimmed through it to get a sense of it.

Zig's approach seems to require users to explicitly call flush for any writes. This reminds me of a similar issue in LLVM's `raw_svector_ostream`. Before a 2015 commit https://github.com/llvm/llvm-project/commit/3d1173ba1a53cab0... , it only called flush at the end, which was efficient. That commit changed this, leading to unnecessarily slow performance. To not break existing users, the 2024 pull request https://github.com/llvm/llvm-project/pull/97704 tries to implement a new interface, but the changes would cause significant churn. @aengelke