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

111–120 of 181 posts

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

#111

Post by drougge »

mk12 wrote: post #86
lolinder wrote: post #33

Earlier quoted context omitted.

> Replacing the value of one variable constantly throughout the code could lead to unpredictable bugs. Having variables with scopes that last longer than they're actually used and with names that are overly long and verbose leads to unpredictable bugs, too, when people misuse the variables in the wrong context later. When I have `initial_foo`, `foo_feature_a`, and `foo_feature_b`, I have to read the entire code caref…

It’s a trade-off. If you allow shadowing, then you rule out the possibility of the value being used later. This prevents accidental use (later on, in a location you didn't intend to use it) and helps readability by reducing the number of variables you must keep track of at once. If you ban shadowing, then you rule out the possibility of the same name referring to different things in the same scope. This prevents acci…

I think it's worth pointing out that the example in the article contains a bug caused by not having shadowing: "const foo3 = try foo.addFeatureB();" should not be using the original foo, but foo2.

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

#112

Post by zozbot234 »

anacrolix wrote: post #101
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…

I agree. It's not ideal but Rust is a genuine improvement across the board on C and C++. It has the inertia and will slowly infiltrate and replace those 2. It also has the rare capacity to add some new areas without detracting from the mainstay: It's actually good as an embedded language for the web and as a DSL. C/C++ definitely didn't have that.

Safe C++ could still be a genuine improvement on Rust - if only because the community would be larger by at least one order of magnitude compared to present-day Rust. Though you would also need a viable C++ epochs proposal to keep the complexity from becoming totally unmanageable.

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

#113

Post by zozbot234 »

asa400 wrote: post #104
Defletter wrote: post #99

Earlier quoted context omitted.

The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.

Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.

ManuallyDrop seems overkill when you have Box::leak().

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

#114

Post by chrisco255 »

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?

So this is just an example of a pointer offset by 1 slot. It's not conceptually all that different to take sub-values of a slot.

To work with values that consume fractions of a byte, such as a 3-bit integer, a pointer + a bit offset is used to grab that value (that complexity is abstracted by the compiler). My argument is the bit shift necessary to load the 3-bits you need from the 8-bit slot is one of the cheapest operations a CPU can do. Meanwhile using 3-bits when all you need is 3-bits allows for things like arrays and packed structs to use much less memory than padding everything to 8 bits.

And why shouldn't a language support that?

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

#115

Post by zozbot234 »

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.

> Because you should be able to take the address of any value

That's debatable, though. One could argue that languages should explicitly support "values that are never going to have their address taken, be passed by reference/pointer, etc." which would only become addressable, e.g. as part of a struct.

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

#116

Post by zozbot234 »

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).

> Rust uses references all over the place

This is mostly a concern with the Rust stdlib, though. And it's in principle fixable, by writing new varieties of those stdlib functions that take raw-pointer or &UnsafeCell arguments, and delegating the "safe" varieties to those.

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

#117

Post by zozbot234 »

zamalek wrote: post #68
chrisco255 wrote: post #38

Earlier quoted context omitted.

Changing the type on a value is an anti-pattern, in my opinion. It's not obnoxious to be explicit in your variable names.

That implies that Hungarian notation is not obnoxious? Sure, that's a fine opinion to have, but I guarantee it is an exceedingly rare one.

If you're writing in a language without strong type checking, Hungarian notation makes sense.

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

#118

Post by tapirl »

Defletter wrote: post #110
tapirl wrote: post #96

Earlier quoted context omitted.

Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/C++ libraries.

> 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.

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

#119

Post by Ygg2 »

brabel wrote: post #109
pcwalton wrote: post #87

Earlier quoted context omitted.

> It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether. From what I've seen, clang has all of these and more for C++. If your metric is "tooling to help you catch UB", C++ is significantly superior to Zig.

WTH they were talking about Rust and Zig, they did not even mention C++ and you come with "if your metrics is blah then C++ is superior, checkmate!", completely ignoring C++ is a monster of complexity while Zig is basically simple as C.

If you present an argument that you like X in a thing so you picked B, and A exist that's more X than B, it means your argument is partially (you like X and Z) or totally (you like Y) wrong.

In this context of, if you are using Zig for its safety via tooling, there is a much more mature candidate C++.

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

#120

Post by Ygg2 »

throwawaymaths wrote: post #100
pcwalton wrote: post #83

Earlier quoted context omitted.

For one, it doesn't do all the "memory safety parts", according to the readme. I'm very skeptical that Zig can be made memory safe with a checker while still remaining compatible with existing code. Certainly neither C nor C++ can, and Zig isn't meaningfully different in expressivity (if anything, it's more expressive, which is the opposite of what you want).

FTrepo: Q: You didn't do X, so Zig will never be able to track X A: Maybe. Only way to know for sure is to fork this (or, hopefully, a 'real' successor) and fail. However, consider that "trivially" it should be possible to externally annotate every zig file with lifetime/type annotations identical to that of Rust and run "exactly the same" analysis as Rust and get the same memory safety as Rust. it appears the clr au…

> it appears the clr author anticipated you: you didnt fork it, try, and fail, so you have ceded the authority to credibly make your speculative complaint

That's a caveat. Not an expectation.

Plus that's not how proof works. Neither Zig nor Zig+Clr have really proven they are safe, ergo they are unsafe or possibly safe (respectively).

Post reply on HN