News for hackers. Stuff that matters.

throwawaymaths

Re:Why we built Lightpanda in Zig on Friday December 05, 2025 @08:29PM (#46169666)
too many features. tryhard vibe
Re:Cloudflare outage on December 5, 2025 on Friday December 05, 2025 @10:41AM (#46162749)
this time in lua. cloudflare can't catch a break
Re:Django 6 Released on Thursday December 04, 2025 @10:57PM (#46156709)
> As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.

i have the exact opposite experience. its far better to have llms start from scratch than use batteries that are just slightly the wrong shape... the llm will run circles and hallucinate nonexistent solutions.

that said, i have had a lot of success having llms write opinionated (my opinions) packages that are shaped in the way that llms like (very little indirection, breadcrumbs to follow for code paths etc), and then have the llm write its own documentation.

Re:Thoughts on Go vs. Rust vs. Zig on Thursday December 04, 2025 @09:46PM (#46156313)
have you ever deployed an erlamg system?

the biggest bugbear for concurrent systems is mutable shared data. by inherently being distributable you basically "give up on that" so for concurrent erlang systems you ~mostly don't even try.

if for no other reason than that erlang is saner than go for concurrency

like goroutines aren't inherently cancellable, so you see go programmers build out the kludgey context to handle those situations and debugging can get very tricky

Re:Thoughts on Go vs. Rust vs. Zig on Thursday December 04, 2025 @09:40PM (#46156270)
ironically with zig most of the things that violate expectations are keywords. so you run head first into a whole ton of them when you first start (but at least it doesn't compile) and then it you have a very solid mental model of whats going on.
Re:Thoughts on Go vs. Rust vs. Zig on Thursday December 04, 2025 @09:37PM (#46156249)
yeah, its a better c, but like wouldnt it be nice if c had stadardized fat pointers so that if you move from project to project you don't have to triple check the semantics? for example and like say 50+ "learnings" from 40 years c that are canonized and first class in the language + stdlib
Re:Thoughts on Go vs. Rust vs. Zig on Thursday December 04, 2025 @07:03PM (#46155088)
and you can have good races too (where the order doesnt matter)
Re:Thoughts on Go vs. Rust vs. Zig on Thursday December 04, 2025 @06:14PM (#46154567)
'const expected = [_]u32{ 123, 67, 89, 99 };'

constant array with u32, and let the compiler figure out how many of em there are (i reserve the right to change it in the future)

Re:Django 6 Released on Thursday December 04, 2025 @05:32PM (#46154087)
why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy
Re:Zig's new plan for asynchronous programs on Wednesday December 03, 2025 @09:17AM (#46134730)
> suspend/resume

special @asyncSuspend and @asyncResume builtins, they will be the low level detail you can build an evented io with.

new Io is an abstraction over the higher level details that are common between sync, threaded, and evented, so you shouldn't expect the suspension mechanism to be in it.

IDK being able to produce a good product in a corpo environment sure sounds like a competency issue.

> how hard it is for top performers to make change

then you're not a top performer anymore?

seems pretty straightforward

> they must be stupid

one can be not stupid and still not competent

Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @10:43PM (#46130068)
i am not familiar with rust and i gave up on python async years ago so i have no frame of reference here. but im really not sure why theres a need to distinguish between tasks and non tasks?

importantly in zig the execution isnt just limited to #1 and #2. if the caller of this function initiated a #3 before all of this it could also get run stuffed in that .await, for example.

Re:Anthropic acquires Bun on Tuesday December 02, 2025 @09:26PM (#46129580)
i haven't. do people still use the "class" keyword?
Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @09:04PM (#46129466)
the io isnt a single resource? it's a module grouping together a pile of code. and you can swap out implementations. the io modules should be responsible for handing out many failable resources, and synchronization is going to be up to the io module code, and thats whether or not it's globalized or passed.
Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @08:49PM (#46129362)
i mean not really? it absolutely does nothing to segregate stateful impurity into a type theoretically stateless token
Re:Anthropic acquires Bun on Tuesday December 02, 2025 @05:44PM (#46127978)
run code anywhere hamstrung by 90s syntax and hidden code indirections
Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @05:42PM (#46127962)
how do you "fail to obtain the token"?
Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @05:39PM (#46127932)
is it not the case that in zig, the execution happens in a_future.await?

I presume that:

io.async 1 stores in io "hey please work on this"

io.async 2 stores in io "hey also please work on this"

in the case where io is evented with some "provided event loop":

await #1 runs through both 1 and 2 interleavedly, and if 2 finishes before 1, it puts a pin on it, and then returns a_result when 1 is completed.

await #2 "no-executions" if 1 finished after 2, but if there is still work to be done for 2, then it keeps going until the results for 2 are all in.

There's no "task that's running somewere mysteriously" unless you pick threaded io, in which case, yeah, io.async actually kicks shit off, and if the cpu takes a big fat nap on the calling thread between the asyncs and the awaits, progress might have been made (which wouldn't be the case if you were evented).

Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @05:26PM (#46127803)
Pretty sure the Zig team is aware of this and has plans to fix it before they re-release async.
Re:Zig's new plan for asynchronous programs on Tuesday December 02, 2025 @05:25PM (#46127793)
1) zig's io is not a viral effect type, you can in principle declare a global io variable and use it everywhere that any library calls for it. Not best practice for a library writer, but if you're building an app, do what you want.

2) There are two things here, there is function coloring and the function coloring problem. The function coloring problem is five things:

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

1. Every function has a color.

2. The way you call a function depends on its color.

3. You can only call a red function from within another red function.

4. Red functions are more painful to call.

5. Some core library functions are red.

You'll have some convincing to do that zig's plan satisfies 4. It's almost certain that it won't satisfy 5.

It's open to debate if zig's plan will work at all, of course.

Re:Migrating the main Zig repository from GitHub to Codeberg on Friday November 28, 2025 @09:30PM (#46084767)
it is what it is. i didnt write it, i was surprised when i read it too.

> This document contains the rules that govern these spaces only:

> The ziglang organization on Codeberg

> #zig IRC channel on Libera.chat

> Zig project development Zulip chat

Aside from the Chernobyl part, that's basically Andromeda strain
Re:Migrating the main Zig repository from GitHub to Codeberg on Thursday November 27, 2025 @02:09AM (#46066566)
The website is not covered by the CoC, so they are not in abeyance
Re:Migrating the main Zig repository from GitHub to Codeberg on Thursday November 27, 2025 @02:08AM (#46066562)
read the CoC carefully, it says which spaces are governed by it. the website does not seem to be. that's deliberate, the CoC only applies to "working" spaces.
Re:Migrating the main Zig repository from GitHub to Codeberg on Thursday November 27, 2025 @02:06AM (#46066551)
coc says this:

> This document contains the rules that govern these spaces only:

> The ziglang organization on Codeberg

> #zig IRC channel on Libera.chat

> Zig project development Zulip chat

doesnt seem to include the zig page!!

so no, it does not violate CoC

also to remember that thorium is the dominant radioactive byproduct of "rare" earth metal refinement; so they're probably isolating large amounts of it so might as well figure out something to do with it.
Re:Heretic: Automatic censorship removal for language models on Wednesday November 19, 2025 @05:54PM (#45986444)
that makes no sense at all.
Re:Only three kinds of AI products work on Sunday November 16, 2025 @03:31PM (#45948143)
I think there's a space for something that wraps an llm (especially multimodal) to do something that's halfway to agentic. Yes you could do it yourself but it's not worth it to you to figure out prompts etc, especially when someone has already optimized it. Plus, it could go from 100 clicks and 10 minutes in front of chatgpt to zero clicks, automated ingest, and get an email when the results is baked.

A good example I saw recently was stripping ads from podcasts.

Re:Heretic: Automatic censorship removal for language models on Sunday November 16, 2025 @12:24PM (#45946747)
Yes, you can also achieve this, presumably less efficiently, with Lora training.
Re:Heretic: Automatic censorship removal for language models on Sunday November 16, 2025 @12:23PM (#45946732)
That is not the case.

Older »