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

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

381–390 of 429 posts

Re: Zig, the Small Language

#381

Post by Graziano_M »

kristoff_it wrote: post #248
Graziano_M wrote: post #245

Earlier quoted context omitted.

Ah, I hadn't thought of that analogue, but it makes sense, then. It sort of recreates the opportunity to make the common bug, though, of allocating enough for the data but not the sentinel (or enough for the string but not the null terminator).

Not really, the sentinel is part of the type and the allocator interface in Zig is type-aware, meaning that you can't simply "forget" about sentinels. The type system will fight you.

So creating a pointer to a type with a fixed length and a sentinel and creating a new one will automatically allocate enough for the length + the sentinel? That's nice.

I'm still not sure I like the .len 'misreporting' since it would be harder to manually optimize around, e.g. packing a struct with a 8 byte + sentinel array would take 16 bytes that I might not notice if I am going by `.len`. This is all speculation, though. I need to actually play around with Zig.

Re: Zig, the Small Language

#382

Post by pron »

pjmlp wrote: post #374
pron wrote: post #370

Earlier quoted context omitted.

Sure, comptime, comptime introspection, comptime type generation, incremental compilation, basically the most important things for low-level programming.

Many low level programming languages don't have them, including C, so while a nice feature, I don't see it as a killer feature, more like a nice to have.

C doesn't have the abstraction abilities of languages like C++ while Zig does, thanks to this feature. This is more than an exponential increase in expressivity (i.e. there are Zig programs that would take exponentially more code in C).

Re: Zig, the Small Language

#383

Post by Arnavion »

tialaramex wrote: post #367
Arnavion wrote: post #251

Earlier quoted context omitted.

>1. Rust uses Zulip (ie, not Discord or Slack), The official Rust chat is on Discord. Now, to Cyberdog's point, there is an IRC channel on libera (that I'm also a part of) and it's even bigger than Zig's channel, but it's "unofficial" and they did ask for an official one. Like, Zig's channel has the advantage of being a direct line to andrewrk which you won't get from the Rust channel.

There's no equivalent to a "direct line to andrewrk" because Rust does not have this one man setup. Culturally, there's more of a "pitch in to help" and less "ask before touching". So people are mostly looking for hand-holding, "How do I?" and "Is this correct?" rather than decisions and permission.

>There's no equivalent to a "direct line to andrewrk" because Rust does not have this one man setup.

Nothing in my comment is about a "one man" setup. Core Rust devs hang out in the Discord server. They don't hang out in the IRC channel.

>Culturally, there's more of a "pitch in to help" and less "ask before touching". So people are mostly looking for hand-holding, "How do I?" and "Is this correct?" rather than decisions and permission.

I'm not sure why you're assuming that the Zig channel is about "decisions and permission", but it's not. It's about language discussion just like the Rust IRC channel and Rust Discord are.

Re: Zig, the Small Language

#384

Post by dundarious »

Ar-Curunir wrote: post #356
dundarious wrote: post #312

Earlier quoted context omitted.

The original claim was: > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perf…

I maintain Rust cryptography libraries with over 30-40k LoC, and I have never resorted to unsafe to bypass borrowck. Our code is as performant as any C impl, without the memory safety bugs. There are many such libraries in Rust.

I wouldn't expect cryptography to need much unsafe. I've never worked in the area, but I expect code mostly falls into 3 domains: parsing, "business" logic (negotiating algorithms, checking certificates/signatures the right way, etc.), and actual crypto algorithms. I see great benefit for Rust in the first two domains. In the algo domain, I don't see how memory safety adds anything as memory issues are an insignificant problem. And there are big challenges like sometimes needing constant-time impls, etc., and how to do that without always having to dip down to hand-written assembly for each target platform. No language I know of provides help in getting bitslicing right, for example.

Again, Rust is great for an awful lot of code, but we should still assess Rust's memory safety claims against the data structures code where you often need to disable the borrow checker. An awful lot of people only use safe wrappers around well-tested unsafe code, which is great, but the unsafe code is still being executed and may still have memory "unsafe"ty.

Re: Zig, the Small Language

#385

Post by chongli »

Tozen wrote: post #377
chongli wrote: post #247

Earlier quoted context omitted.

"Don't like it? Just fork it!" is a variant I see a lot in the FOSS world. It's equally pernicious in my view. Either you end up maintaining your own fork that nobody uses (and who wants to do that) or the fork is successful and half the community starts hating you for causing more fragmentation. Perhaps the most recent example of this I can think of is neovim, though in the language world python 2 vs 3 is so infamou…

I agree with a lot of this, in terms of the polarization and tribalism, which is often the result. Unfortunately, there is little that can be usually done, except use other programming languages (which are more agreeable) or fork/make your own.

Yeah, it's just really frustrating when a language like Zig comes along. It does so many things right and seems to have a really good philosophy. But then it includes some highly opinionated "features" that make it a non-starter for so many people who could otherwise benefit from it.

Re: Zig, the Small Language

#386

Post by [deleted] »

dtolnay wrote: post #314
hsn915 wrote: post #305

Earlier quoted context omitted.

Here's a hypothesis I'd like to see Rust advocate attack: In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".

https://github.com/diem/diem is 387,952 lines of Rust code across 169 crates. In total there are 3 lines of unsafe code, which is less then 0.001% (1 thousandth of 1%).

[deleted]

Re: Zig, the Small Language

#387

Post by [deleted] »

pron wrote: post #382
pjmlp wrote: post #374

Earlier quoted context omitted.

Many low level programming languages don't have them, including C, so while a nice feature, I don't see it as a killer feature, more like a nice to have.

C doesn't have the abstraction abilities of languages like C++ while Zig does, thanks to this feature. This is more than an exponential increase in expressivity (i.e. there are Zig programs that would take exponentially more code in C).

[deleted]

Re: Zig, the Small Language

#388

Post by davidatbu »

dundarious wrote: post #384
Ar-Curunir wrote: post #356

Earlier quoted context omitted.

I maintain Rust cryptography libraries with over 30-40k LoC, and I have never resorted to unsafe to bypass borrowck. Our code is as performant as any C impl, without the memory safety bugs. There are many such libraries in Rust.

I wouldn't expect cryptography to need much unsafe. I've never worked in the area, but I expect code mostly falls into 3 domains: parsing, "business" logic (negotiating algorithms, checking certificates/signatures the right way, etc.), and actual crypto algorithms. I see great benefit for Rust in the first two domains. In the algo domain, I don't see how memory safety adds anything as memory issues are an insignifica…

> I don't see how memory safety adds anything [to algos in cryptography] as memory issues are an insignificant problem.

I'm not terribly experienced in cryptography either, but I'm pretty sure that memory safety is a HUGE deal in cryptography as a whole. Heartbleed[0] was a memory safety issue. Python's cryptography package switched to Rust specifically because of memory safety [1].

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160

[1] https://github.com/pyca/cryptography/issues/5771

Re: Zig, the Small Language

#389

Post by littlestymaar »

ptato wrote: post #373
littlestymaar wrote: post #296

Earlier quoted context omitted.

> I still fought the borrow checker after a year of using Rust. That's interesting. How much Rust did you use during that year? And how level of proficiency did you reach? > And I found many situations while using Rust where I either needed to clone, or use unsafe That sounds like an uncommon trade-off. From my experience, the trade-off was usually “clone or put lifetime parameters everywhere”, which is annoying (and…

> How much Rust did you use during that year? And how level of proficiency did you reach? What kind of answer do you expect to these questions?

For the first one, something between: “I was learning Rust on my spare time” and “I was working full time in a Rust-centric team”. And the second one is more subjective, about how confident you considered yourself with the language and how familiar you felt with its concepts.

Re: Zig, the Small Language

#390

Post by Tozen »

rtev wrote: post #144
beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

Very good points, that can't be ignored. Zig looks to be trapped in a niche. It's going to have a really hard time pushing past other low-level languages, and because its small and focused on that area, will not be able to compete with numerous high-level general-purpose languages that do more for users.

Add to that, Rust and Go have strong corporate backing, continually get lots of shine in the media, and often are given positive spin or ratings whenever compared to other languages.

As you mentioned Nim, look how far uphill it still has to climb, after the many years (around 14 years) it has been out. TIOBE Index doesn't even have Nim in their top 50, and they aren't even on IEEE's top programming languages list (of around 60 languages). This is just as likely the fate of Zig as well. Not saying some people won't find Zig useful for particular niches, but rather it will likely never be on the level of Rust, Go, D, Object Pascal, etc... or possibly even Nim.

Post reply on HN