Hacker Newsnew | past | comments | ask | show | jobs | submit | dnautics's commentslogin

i think the plan is to make no distinction between error and warning, but have trivial errors still build. that said i wouldn't be surprised if they push that to the end because it seems like a great ultrafilter for keeping annoying people out so they don't try to influence the language.

zig really makes it unappealing to architecture astronaut, and rust pushes you towards it. id rather my colleagues write zig

don't know if it's still on the table, but Andrew has hinted that the unused variables error may in the future still produce an executable artefact but return an nonzero return code for the compiler. And truly fatal errors would STILL produce an executable artefact too, just one that prints "sorry this compilation had a fatal error" to stdout.

actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker

https://github.com/ityonemo/clr


"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.

negative. For example bounds checking is turned on by default in Zig, which prevents classes of overflow safety errors.

I don't think you've necessarily understood the scope and impact of the borrow checker. Bounds checking is just a sane default (hygiene), not a game changer.

I mean, I'm the author of this?

https://github.com/ityonemo/clr

so yes, I understand that it's important. It doesn't need to be in the compiler though? I think it's likely the case that you also don't need to have annotations littering the language.


no. I'm a pretty skilled programmer and I definitely have to intervene and fix an architectural problem here and there, or gently chastise the LLM for doing something dumb. But there are also many cases where the LLM has seen something that i completely missed or just hammered away at a problem enough to get a solution that is correct that I would have just given up on earlier.

The clanker can produce better programs than me because it will just try shit that I would never have tried, and it can fail more times than I can in a given period of time. It has specific advantages over me.


no nulls is truly not a problem. Of all the problems I have seen, I have never seen Claude mess up with nulls in Elixir.

I'm not 100% convinced that "plugging memory error holes" was right at the compiler level.

Currently building out clr, which uses a heuristic (not formal verification) method for checking soundness of zig code, using ~"refinement types". In principle one could build a more formal version of what I'm doing.

https://github.com/ityonemo/clr


they kinda tried that and it is my understanding that it sucks. One example of "direct linear mapping":

https://pdfs.semanticscholar.org/5080/78a97f4778eee488e11032...


we should

1) pay reviewers. 2) you can't publish unless a reviewer replicates your work.

yes. It can be done.

https://www.orgsyn.org/


you'd think, and yet its like 70% on autocoderbenchmark

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: