Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig ELF Linker Improvements Devlog

ziglang.org

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#81

Post by wolttam »

kllrnohj wrote: post #78
bpavuk wrote: post #68

Earlier quoted context omitted.

> Didn't Go already do that? no. GC pauses turn any serious systems work into hell. > Yes, and it will still only be useful [...] this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

> no. GC pauses turn any serious systems work into hell. did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter > this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui Sure, but if you're philosophically…

Because they like and are excited about Zig.

Re: Zig ELF Linker Improvements Devlog

#82

Post by tovej »

spease wrote: post #53
Mawr wrote: post #52

Earlier quoted context omitted.

> Zig, Rust, and the likes are only viable in niches where C is viable Pretty much correct, yes. > Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. Fundamentally impossible. C/Zig/Rust have 100% performance as a top goal, which has to be traded off with something else and that's always realistically going to be programmer work/effort/time. You…

> You can't have a house built 100% fast but also 100% cheap and with 100% quality. That’s essentially what technological development does, is make those tradeoffs more favorable.

No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good.

And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.

Re: Zig ELF Linker Improvements Devlog

#83

Post by vanviegen »

akazantsev wrote: post #23
bpavuk wrote: post #5

I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to…

> Kotlin of C That sounds good on paper. But as a guy who tried to learn Kotlin and only it. It comes with baggage to learn Java to use its libraries because... You know... they interact seamlessly and stuff. In the end, for a new learner, it might actually make things harder. Nothing about Zig and C here, just a bit salty from my experience with Kotlin.

Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.

Re: Zig ELF Linker Improvements Devlog

#84

Post by epolanski »

c0rruptbytes wrote: post #18

i'm not cool and hip like hacker news devs, but I've been seeing Zig a lot, is this the new cool thing on the street? no more Rust?

It's a hard-to-dislike language in the niche of systems programming.

The author is strongly biased and opinionated on his architectural and design choices, and those choices resonate with many.

Re: Zig ELF Linker Improvements Devlog

#85

Post by surajrmal »

pjmlp wrote: post #63
spease wrote: post #54

Earlier quoted context omitted.

> the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!" This is more of a meme than reality at this point.

Does not help the regulator posts on HN about having rewriten known projects into Rust, and since we are on a Zig thread, Bun.

Those rewrites happen because someone was interested in making them happen (often the maintainer). The meme is that evangelists will constantly advocate to you that your project should be rewritten.

Re: Zig ELF Linker Improvements Devlog

#86

Post by epolanski »

mihaelm wrote: post #41
dnautics wrote: post #26

Earlier quoted context omitted.

what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.

They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md... which applies to contributing to the Zig project. The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/ "Anti-AI stance" is painting it with too broad of a brush. You're definitely not…

And the largest Zig projects all make use of AI assistance to build software.

Re: Zig ELF Linker Improvements Devlog

#88

Post by pjmlp »

epolanski wrote: post #84
c0rruptbytes wrote: post #18

i'm not cool and hip like hacker news devs, but I've been seeing Zig a lot, is this the new cool thing on the street? no more Rust?

It's a hard-to-dislike language in the niche of systems programming. The author is strongly biased and opinionated on his architectural and design choices, and those choices resonate with many.

I don't like the @ all over the place and the approach to slurping source as structs for libraries.

I would faster get back to Modula-2 or Object Pascal.

Re: Zig ELF Linker Improvements Devlog

#89

Post by keithasaurus »

onlyrealcuzzo wrote: post #80
keithasaurus wrote: post #59

Earlier quoted context omitted.

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place muta…

Interesting. How do you prevent data races in concurrent code? Or do you not allow shared mutable memory?

Yeah, no shared mutable memory; coordination is done via channels.

Re: Zig ELF Linker Improvements Devlog

#90

Post by bpavuk »

kllrnohj wrote: post #78
bpavuk wrote: post #68

Earlier quoted context omitted.

> Didn't Go already do that? no. GC pauses turn any serious systems work into hell. > Yes, and it will still only be useful [...] this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

> no. GC pauses turn any serious systems work into hell. did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter > this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui Sure, but if you're philosophically…

> They were comparing

that was me comparing, please kindly read usernames next time :)

> why not just choose a language that doesn't compromise itself for those ideals in the first place?

I might want to wrap a timing-sensitive machinery into some nice UI. Rust has Tauri for that, sure, but now we are bringing npm and have zero chances of having GPU-accelerated UI without a crap-ton of fuckery which would be easier in Zig. another path for resolving that same issue is Compose Desktop + Project Panama, but then you are dealing with data marshalling, FFI boundary, and manual resource management in an environment that does not expect this.

so, here is a genius idea: why not have everything in one language? C++ already does that, much like C, but Zig does that so much better, and incremental compilation time is one of the more practical and immediate developer UX benefits it provides. Rust? good luck having shared mutable state there.

Post reply on HN