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

Zig; what I think after months of using it

strongly-typed-thoughts.net

Post reply on HN
Print view View original

131–140 of 181 posts

Re: Zig; what I think after months of using it

#131

Post by littlestymaar »

tapirl wrote: post #118
Defletter wrote: post #110

Earlier quoted context omitted.

> but IMO, it will become more popular than Rust While I wish this were true, I very much doubt it, at least not until Zig has proper interfaces and gives up its weird hangup on anonymous functions. It's also extremely easy to effectively lose access to Zig features without cluttering your code. For example, say you want to use libevent in Zig: your event callbacks must use C calling conventions, meaning you lose acc…

It seems you are proving Zig will not become very popular, but not Zig will not become more popular than Rust. I agree that Zig will not become very popular. It needs certain programming experiences to master it. But I'm quite sure it will become more popular than Rust.

There's a contradiction though, as Rust is already popular…

Re: Zig; what I think after months of using it

#132

Post by tasuki »

hitekker wrote: post #102
toprerules wrote: post #61

Earlier quoted context omitted.

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…

A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive. A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.

> A big company I worked at actually deprecated the last of its Rust code last year.

What replaced Rust?

Re: Zig; what I think after months of using it

#133

Post by Miksel12 »

pcwalton wrote: post #79
sedatk wrote: post #55

> The first one that comes to mind is its arbitrary-sized integers. That sounds weird at first, but yes, you can have the regular u8, u16, u32 etc., but also u3. At first it might sound like dark magic, but it makes sense with a good example that is actually a defect in Rust to me. You don't need Rust to support that because it can be implemented externally. For example, crates like "bitbybit" and "arbitrary-int" pro…

I'm normally not sympathetic to the "you don't need that" argument, but there is a much stronger argument for not having arbitrarily-sized integers in Rust: the fact that values of such types can't have an address. The reason why our types all have bit sizes measured in octets is that a byte is the minimum granularity for a pointer.

They could just be aligend and padded to the next power of 2, right? I think they work like that in Zig and only when they are put in a (bit)packed struct are they actually (bit)unaligned and unpadded.

Re: Zig; what I think after months of using it

#134

Post by Gibbon1 »

pcwalton wrote: post #125
Gibbon1 wrote: post #106

Earlier quoted context omitted.

With a 64 bit pointer you could make it bit addressable.

At that cost of having your loads no longer be hardware load instructions, which would be bad for performance.

High performance memory systems aren't register based anyways.

Re: Zig; what I think after months of using it

#135

Post by oneshtein »

mk12 wrote: post #74
oneshtein wrote: post #64

Earlier quoted context omitted.

Yes, unsafe code is problematic in Rust, C, C++, etc. Is Zig different?

It’s harder to write correct unsafe Rust than correct Zig because (1) Rust uses references all over the place, but when writing unsafe code you must scrupulously avoid “producing” an invalid reference (even if you never deference it), and (2) there’s lots of syntax noise which obscures what the code is doing (though &raw is a step in the right direction).

For Rust references, rules[0] are not hard to follow:

The pointer must be properly aligned.

It must be non-null.

It must be “dereferenceable”: a pointer is dereferenceable if the memory range of the given size starting at the pointer is entirely contained within the bounds of that allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

The pointer must point to a valid value of type T.

When creating a mutable reference, then while this reference exists, the memory it points to must not get accessed (read or written) through any other pointer or reference not derived from this reference.

When creating a shared reference, then while this reference exists, the memory it points to must not get mutated (except inside UnsafeCell).

[0]: https://doc.rust-lang.org/stable/core/ptr/index.html#pointer...

Re: Zig; what I think after months of using it

#136

Post by mmusson »

pcwalton wrote: post #91
chrisco255 wrote: post #88

Earlier quoted context omitted.

A byte isn't the minimum granularity for a pointer. The minimum is based on whatever target you're compiling for. If it's a 32-bit target platform, then the minimum granularity is 4 bytes. Why should pointer size determine value size though? It's super fast to shift bits around, too, when needed.

> If it's a 32-bit target platform, then the minimum granularity is 4 bytes. Huh? How do you think `const char *s = "Hello"; const char *t = &s[1];` works? > Why should pointer size determine value size though? Because you should be able to take the address of any value, and addresses have byte granularity.

> Huh? How do you think `const char s = "Hello"; const char t = &s[1];` works?

I think you and the parent are using different definitions of granularity. The parent meant that sizeof(t) could be 32 or 64 bits. I think you just meant that the smallest thing the pointer references is the address of a single byte.

Rust already has fat pointers though. A reference to a smaller byte value could be a pointer plus a bit-mask.

Re: Zig; what I think after months of using it

#138

Post by YuukiRey »

grayhatter wrote: post #73

lol, I knew exactly who wrote this once I saw the complaint about shadowing being forbidden. The author and I were just arguing about it the other day on irc. While the author considers it an annoying language bug because it requires creating additional variable names (given refactoring was an unpalatable option). I consider it a feature. Said arguments have become a recurring and frustrating refrain; when rust impos…

The duck typing argument is absolutely not based on minimal or missing documentation. There wouldn't be countless issues about it in the Zig repository if it were that simple. See https://github.com/ziglang/zig/issues/17198

I'm simply going to quote one of the comments from the linked GitHub issue:

> generic code is hard. Hard to implement correctly, hard to test, hard to use, hard to reason about. But, for better or worse, Zig has generics. That is something that cannot be ignored. The presence of generic capabilities means that generic code will be written; most of the std relies on generic code.

Re: Zig; what I think after months of using it

#139

Post by polanas »

lnenad wrote: post #108
pkulak wrote: post #92

Earlier quoted context omitted.

And on the whole, I prefer shadowing. I’ve never had a bug in either direction, but keeping everything immutable without shadowing means you spend all your brain power Naming Things.

I mean that's a really fake problem. How many times per line of code do you actually need to name variables and how many of those times you're shadowing a previously defined var. I'm guessing a very small amount.

In case of rust, it actually happens quite often. I find myself rarely needing to use mut, instead using functional approaches such as iterators and expressions. So a high percentage of the code is let statements

Re: Zig; what I think after months of using it

#140

Post by lolinder »

lnenad wrote: post #45
lolinder wrote: post #34

Earlier quoted context omitted.

> Often, the bug is caused by an accidental use of := instead of =. This is a distinctly Go problem, not a problem with shadowing as a concept. In Rust you'd have to accidentally add a whole `let` keyword, which is a lot harder to do or to miss when you're scanning through a block. There are lots of good explanations in this subthread for why shadowing as a concept is great. It sounds like Go's syntax choices make it…

> There are lots of good explanations in this subthread for why shadowing as a concept is great Not really. All of them boil down to ergonomics, when in reality it doesn't bring a lot of benefit other than people hating on more descriptive variable names (which is fair).

You're saying ergonomics aren't a good explanation? The entire point of a programming language over writing machine code boils down to ergonomics! You've got to do better than "it's just ergonomics" when your argument for a language to ban shadowing is also "just ergonomics".

The debate here is about which one truly has better ergonomics!

Post reply on HN