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

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

121–130 of 183 posts

Re: Zig and the design choices within

#121

Post by bsder »

lerno wrote: post #115
bsder wrote: post #103

Earlier quoted context omitted.

> The Zig compiler is not particularly fast. This really makes me question the accuracy of the rest of the article. I'm really struggling to come up with a compiler that is faster than Zig. Go, maybe? That's ... about the end of my shortlist.

Odin, Jai, C3, C.

Jai isn't open source so it is completely and totally irrelevant.

Zig builds C faster than most C compilers. You're going to have to do better than just mention it.

However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.

Re: Zig and the design choices within

#122

Post by Measter »

bsder wrote: post #106
nightpool wrote: post #31

Earlier quoted context omitted.

I can see where you're coming from, but I do think there's a fair amount of meat here. I've never used Zig, but I initially thought of it as pretty similar to other modern languages like Go and Rust, and I liked their allocator approach, but the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues tha…

> the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. That's because Zig defers a bunch of checks to runtime that Rust will force you to deal with before it will let you compile at all. That is a tradeoff. Developer velocity vs memory safety. Given that Bun s…

A segfault is not the program performing a runtime check and doing a controlled shutdown. A segfault is the OS detecting the program doing something it's not allowed to and killing it.

Re: Zig and the design choices within

#123

Post by James_K »

rvrb wrote: post #98
James_K wrote: post #49

Earlier quoted context omitted.

Creating a language which is difficult to use and dangerous is not “lending humanity to the developer”. Humans make mistakes, and a language that doesn't account for this is ignoring the humanity of its users.

Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult". Software is dangerous. Memory safety is one of a million ways it can be dangerous. A compiler barfing when it thinks you are doing something unsafe with pointers is one approach to dealing with one of the ways that code can be dangerous to execute. Zig does not ignore that particular danger, it just takes a different appro…

>Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult".

It's easy to get in a car and put your foot on the pedal, but usage entails not crashing.

>Memory safety is one of a million ways it can be dangerous.

We have the statistics on this. It is 7 out of 10 ways it is dangerous, going by proportion of CVEs, so it's likely higher in less well tested software. Your estimation was off by 5 orders of magnitude.

>leaves the developer with a little more humanity

I could care less if the developer is afforded humanity. I want to write software and I want a programming language that helps me to do that. Whatever humanity I'm sacrificing by writing in memory safe languages is more than made up for by the comparative ease of not having to worry about memory safety.

>reacting emotionally

You are reacting emotionally. You are judging programming languages by their emotional value rather than their features. “Humanity” is not a measurable feature. 70% fewer CVEs is a measurable feature.

Re: Zig and the design choices within

#124

Post by asa400 »

pron wrote: post #53
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.

What are we measuring? Lines of code? Number of programmers employed? Number of new applications started?

Rust is in: Linux, Windows, Azure, all over AWS, Amazon's Prime video, Cloudflare's proxy, Firefox, Python's `cryptography` package, Zed editor. This is just the sample I know of.

Is this low adoption?

Re: Zig and the design choices within

#125

Post by williamstein »

kennykartman wrote: post #99
anp wrote: post #6

I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’…

I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...

bun has 10x the issues matching "segfault" as deno

- deno 44: https://github.com/denoland/deno/issues?q=is%3Aissue%20state...

- bun 464: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

Re: Zig and the design choices within

#126

Post by ModernMech »

pron wrote: post #78
ModernMech wrote: post #62

Earlier quoted context omitted.

> a relatively advanced age. Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young . Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and…

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

I dunno, I think you're trying to split hairs if top 20 isn't "very popular".

But I don't think the comparison you're trying to make works, because then isn't now.

In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better. As in, you need to offer the entire feature set of the old tool plus something else compelling enough to overcome the network effects (ecosystem + years of experience + job prospects) of the prior environment.

So when C++ came on the scene, they had to compete against ~20 years of accumulated legacy systems and language history. Rust had to compete with 50 years of legacy systems and language history.

Moreover, developer expectations are a lot different today. Back then, C++ was what, a compiler and some docs? Python was an interpreter and some docs? Maybe an IRC channel? Today, it's not enough to reach 1.0, you also have to deliver a package manager, robust 3rd party library ecosystem, language server tooling, a robust community with support for new devs, etc. So timescales for language development are getting longer than they were back then.

Also, I don't know why you've chosen "very popular" as a metric. Very popular isn't something a language needs to be, it just needs to be big enough to sustain a community. Being top 20 within 10 years is certainly in that realm. You can see that other language communities have existed for longer and are much smaller. And anyway, the entire developer population today is much larger than it was back then; you can have a small percentage of all developers but still large enough to be robust. I don't know the math, maybe someone can figure it out, but I wouldn't be surprised if 1% of developers today is inflation adjusted to like 10%-20% of developers in 1996. So Rust is probably as big as it needs to be to sustain itself, it doesn't have to be a "very popular" language if that means being in the top 5 or whatever the threshold is.

Re: Zig and the design choices within

#127

Post by ModernMech »

refulgentis wrote: post #87
ModernMech wrote: post #26

Earlier quoted context omitted.

> But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. That's true but it's deeper than that -- no matter how much time goes by, there will always be people new to the language, and they will always make newbie mistakes if the language allows them to. So "just be an expert and don't write shoddy code" doesn't scale, no matter how hard you personally…

It's deeper to note people who know nothing will make the mistake, than "I, an expert, will make the mistake"? :)

Okay broader then?

Re: Zig and the design choices within

#128

Post by ModernMech »

bsder wrote: post #121
lerno wrote: post #115

Earlier quoted context omitted.

Odin, Jai, C3, C.

Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.

> Jai isn't open source so it is completely and totally irrelevant.

Worse, there's not even a compiler available. I don't even think there's even a spec.

Re: Zig and the design choices within

#129

Post by cb22 »

kennykartman wrote: post #99
anp wrote: post #6

I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’…

I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...

> I'd like to see the same stats for tigerbeetle

Actual SIGSEGVs are pretty rare, even during development. There was a pretty interesting one that affected our fuzzing infra a little bit ago: https://ziggit.dev/t/stack-probe-puzzle/10291

Almost all of the time we hit either asserts or panics or other things which trigger core dumps intentionally!

Re: Zig and the design choices within

#130

Post by kstenerud »

taylorallred wrote: post #13

I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probab…

It really comes down to a matter of opinion where the line between "nothing hidden" and convenience lies. Technically, a loop is an abstraction of convenience that hides the comparative jump underneath.
Post reply on HN