frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Animated AI

https://animatedai.github.io/
131•frozenseven•4d ago•13 comments

A faster heart for F-Droid

https://f-droid.org/2025/12/30/a-faster-heart-for-f-droid.html
369•kasabali•13h ago•157 comments

Readings in Database Systems (5th Edition)

http://www.redbook.io/
79•teleforce•6h ago•5 comments

FediMeteo: A €4 FreeBSD VPS Became a Global Weather Service

https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-s...
281•birdculture•12h ago•66 comments

Show HN: 22 GB of Hacker News in SQLite

https://hackerbook.dosaygo.com
483•keepamovin•15h ago•158 comments

Odin: Moving Towards a New "core:OS"

https://odin-lang.org/news/moving-towards-a-new-core-os/
40•ksec•5d ago•10 comments

A Vulnerability in Libsodium

https://00f.net/2025/12/30/libsodium-vulnerability/
262•raggi•14h ago•34 comments

Honey's Dieselgate: Detecting and tricking testers

https://vptdigital.com/blog/honey-detecting-testers/
196•AkshatJ27•10h ago•59 comments

What If Heavy Files Felt Heavy?

https://www.shiveesh.com/thoughts-and-ideas/what-if-heavy-files-actually-felt-heavy
43•shiveeshfotedar•5d ago•23 comments

Google Opal

https://opal.google/landing/
97•gmays•4h ago•49 comments

Loss32: Let's Build a Win32/Linux

https://loss32.org/
269•akka47•1d ago•348 comments

Electrolysis can solve one of our biggest contamination problems

https://ethz.ch/en/news-and-events/eth-news/news/2025/11/electrolysis-can-solve-one-of-our-bigges...
147•PaulHoule•14h ago•41 comments

OpenAI's cash burn will be one of the big bubble questions of 2026

https://www.economist.com/leaders/2025/12/30/openais-cash-burn-will-be-one-of-the-big-bubble-ques...
312•1vuio0pswjnm7•10h ago•427 comments

Sabotaging Bitcoin

https://blog.dshr.org/2025/12/sabotaging-bitcoin.html
137•zdw•11h ago•86 comments

Zpdf: PDF text extraction in Zig

https://github.com/Lulzx/zpdf
169•lulzx•12h ago•64 comments

Non-Zero-Sum Games

https://nonzerosum.games/
366•8organicbits•20h ago•178 comments

LLVM AI tool policy: human in the loop

https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-human-in-the-loop/89159
179•pertymcpert•5h ago•81 comments

Tixl: Open-source realtime motion graphics

https://github.com/tixl3d/tixl
3•nateb2022•4d ago•0 comments

Toro: Deploy Applications as Unikernels

https://github.com/torokernel/torokernel
129•ignoramous•15h ago•110 comments

Escaping containment: A security analysis of FreeBSD jails [video]

https://media.ccc.de/v/39c3-escaping-containment-a-security-analysis-of-freebsd-jails
85•todsacerdoti•12h ago•2 comments

Mitsubishi Diatone D-160 (1985)

https://audio-database.com/MITSUBISHI-DIATONE/diatonesp/d-160-e.html
39•anigbrowl•2d ago•17 comments

No strcpy either

https://daniel.haxx.se/blog/2025/12/29/no-strcpy-either/
190•firesteelrain•18h ago•106 comments

Git analytics that works across GitHub, GitLab, and Bitbucket

13•akhnid•1d ago•7 comments

The British empire's resilient subsea telegraph network

https://subseacables.blogspot.com/2025/12/the-british-empires-resilient-subsea.html
188•giuliomagnifico•18h ago•47 comments

Times New American: A Tale of Two Fonts

https://hsu.cy/2025/12/times-new-american/
249•firexcy•19h ago•143 comments

Five Years of Tinygrad

https://geohot.github.io//blog/jekyll/update/2025/12/29/five-years-of-tinygrad.html
222•iyaja•1d ago•107 comments

Professional software developers don't vibe, they control

https://arxiv.org/abs/2512.14012
158•dpflan•12h ago•188 comments

L1TF Reloaded

https://github.com/ThijsRay/l1tf_reloaded
22•Fnoord•5h ago•0 comments

Approachable Swift Concurrency

https://fuckingapproachableswiftconcurrency.com/en/
164•wrxd•19h ago•85 comments

What Happened to Abit Motherboards

https://dfarq.homeip.net/what-happened-to-abit-motherboards/
112•zdw•17h ago•71 comments
Open in hackernews

Odin: Moving Towards a New "core:OS"

https://odin-lang.org/news/moving-towards-a-new-core-os/
39•ksec•5d ago

Comments

MangoToupe•1h ago
Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Charitably, is this aimed at c/zig heads?
BigJono•1h ago
I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
messe•34m ago
> All procedures that returned allocated memory will require an explicit allocator to be passed

All procedures in core/os. Odin isn't removing the allocator from implicit context in the rest of its APIs.

leecommamichael•32m ago
All you've got to do is write `context.allocator` to abide.
gethly•1h ago
I've been actively toying with Odin in past few days. As a Gopher, the syntax is partially familiar. But as it is a lower level language wiht manual-ish memory management, simple things require much more code to write and a ton of typecasting. Lack of any kind of OOP-ism, like inheritance(bad), encapsulation(ok), or methods(nobrainer), is very spartan and unpleasant in 2025, but that's just a personal preference. I don't think I ever used fully procedural language in my entire life. It requires a complete rewiring on one's brain. Which I'd say is a huge obstacle for most programmers, definitely from the younger crowd. For low-level guys, this is quite a nice and powerful tool. For everyone else, it's a bit of a head ache(even Zig has methods and interfaces). The language still lacks basic things like SQL drivers, solid HTTPS stack, websockets, and essentially anything related to web and networking(which has the bare bones functionality). As a Gopher, I am biased, but the web rules the world, so it is objective complaint. In the end, this is a solid language with great support for 2D and 3D graphics and advanced mathematics, which naturally makes it a very niche language for making games or anything to do with visual programming. Definitely try it out.
messe•37m ago
> even Zig has methods and interfaces

Zig doesn't have interfaces as a language level feature. It uses manually implemented vtables and wrapper methods.

You can do the same in Odin with wrapper functions around a vtable.

leecommamichael•30m ago
There's even syntax-sugar for it in Odin with the `->` operator.
sidkshatriya•1h ago
I like Odin and hope for it to gain more momentum.

I have an important metric for new "systems" languages: does the language allow NULL for it's commonly used pointer type. Rust by default does not (References may _not_ be NULL). Here is where I think Odin makes a mistake.

In the linked blog post Odin mentions ^os.File which means pointer to File (somewhat like *FILE in C). Theoretically the pointer can be NULL. In practice, maybe I would need to check for NULL or maybe I would not (I would have to scan the Odin function's documentation to see what the contract is).

In Rust, if a function returns &File or &mut File or Box<File> etc. I know that it will never be NULL.

So Odin repeats the famous "billion-dollar mistake" (Tony Hoare). Zig in comparison is bit more fussy about NULL in pointers so it wins my vote.

Currently this is my biggest complaint about Odin. While Odin packages a lot of power programming idioms (and feels a bit higher level and erognomic than Zig) it makes the same mistake that Golang, C and others make regarding allowing NULL in the default pointer type.

leecommamichael•24m ago
Odin offers a Maybe(T) type which might satisfy your itch. It's sort of a compromise. Odin uses multiple-returns with a boolean "ok" value for binary failure-detection. There is actually quite a lot of syntax support for these "optional-ok" situations in Odin, and that's plenty for me. I appreciate the simplicity of handling these things as plain values. I see an argument for moving some of this into the type-system (using Maybe) when it comes to package/API boundaries, but in practice I haven't chosen to use it in Odin.