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

81–90 of 181 posts

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

#81

Post by chrisco255 »

toprerules wrote: post #61
scubbo wrote: post #10

Great write-up, thank you! I used Zig for (most of) Advent Of Code last year, and while I did get up-to-speed on it faster than I did with Rust the previous year, I think that was just Second (low-level) Language syndrome. Having experienced it, I'm glad that I did (learning how cumbersome memory management is makes me glad that every other language I've used abstracts it away!), but if I had to pick a single low-lev…

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…

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".

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

#82

Post by hoelle »

pcwalton wrote: post #76
hoelle wrote: post #57

> Zig does enhance on C, there is no doubt. I would rather write Zig than C. The design is better, more modern, and the language is safer. But why stop half way? Why fix some problems and ignore the most damaging ones? I was disappointed when Rust went 1.0. It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make…

> It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make it workable for larger teams. There are million-line Rust projects now. Rust is obviously workable for larger teams. > Any language that imbues the entire set of special characters (!#*& []{}(); ...etc) with mystical semantic context is, imo, more interes…

> I think you're talking about @ and ~ boxes. As I recall, those were removed the same year the iPad and Instagram debuted.

Take criticism better.

A language choice on a project means the veterans are indefinitely charged with teaching it to newbies. For all Rust's perks, I judge that it would be a time suck for this reason.

Browsing some random rust game code: [https://github.com/bevyengine/bevy/blob/8c7f1b34d3fa52c007b2...] pub fn play( &mut self, player: &'p mut AnimationPlayer, new_animation: AnimationNodeIndex, transition_duration: Duration, ) -> &'p mut ActiveAnimation {

[https://github.com/bevyengine/bevy/blob/8c7f1b34d3fa52c007b2...] #[derive(Debug, Clone, Resource)] #[cfg_attr(feature = "bevy_reflect", derive(Reflect), reflect(Default, Resource))] pub struct ButtonInput { /// A collection of every button that is currently being pressed. pressed: HashSet, ...

Cool. Too many symbols.

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

#83

Post by pcwalton »

throwawaymaths wrote: post #70
zamalek wrote: post #66

Earlier quoted context omitted.

This is precisely the myth that the article talks about. Miri finds significantly more UB in unsafe Rust than Zig's checks do. Even if it weren't, this exaggeration is a complete theater. You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. The entirety of all Zig codebases is unsafe. That's fine if you are fine with unsafe cod…

yes but by the time you're using miri, why not just run zig with a separate static checker that does all the memory safety parts? https://github.com/ityonemo/clr

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

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

#84

Post by jay_kyburz »

lolinder wrote: post #33
lnenad wrote: post #7

When did shadowing become a feature? I was under the impression it's an anti-pattern. As per the example in the article > const foo = Foo.init(); > const foo2 = try foo.addFeatureA(); > const foo3 = try foo.addFeatureB(); It's a non issue to name vars in a descriptive way referring to the features initial_foo for example and then foo_feature_a. Or name them based on what they don't have and then name it foo. In the e…

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

I don't know zig at all, but why is the author trying to declare foo as const 3 times. Surely you would declare it as var with some default value that means uninitialized, then try and put values in it.

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

#85

Post by pcwalton »

hoelle wrote: post #82
pcwalton wrote: post #76

Earlier quoted context omitted.

> It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make it workable for larger teams. There are million-line Rust projects now. Rust is obviously workable for larger teams. > Any language that imbues the entire set of special characters (!#*& []{}(); ...etc) with mystical semantic context is, imo, more interes…

> I think you're talking about @ and ~ boxes. As I recall, those were removed the same year the iPad and Instagram debuted. Take criticism better. A language choice on a project means the veterans are indefinitely charged with teaching it to newbies. For all Rust's perks, I judge that it would be a time suck for this reason. Browsing some random rust game code: [ https://github.com/bevyengine/bevy/blob/8c7f1b34d3fa52…

That first "random Rust game code" is in fact code I wrote :)

It's the same amount of punctuation as C++, or really any other language with C-like syntax.

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

#86

Post by mk12 »

lolinder wrote: post #33
lnenad wrote: post #7

When did shadowing become a feature? I was under the impression it's an anti-pattern. As per the example in the article > const foo = Foo.init(); > const foo2 = try foo.addFeatureA(); > const foo3 = try foo.addFeatureB(); It's a non issue to name vars in a descriptive way referring to the features initial_foo for example and then foo_feature_a. Or name them based on what they don't have and then name it foo. In the e…

> 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 accidental use (of the wrong value, because you were confused about which one the name referred to) and helps readability by making it easier to immediately tell what names refer to.

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

#87

Post by pcwalton »

chrisco255 wrote: post #48
bobbylarrybobby wrote: post #36

Earlier quoted context omitted.

If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.

Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.

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

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

#88

Post by chrisco255 »

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.

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.

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

#89

Post by pkulak »

chrisco255 wrote: post #81
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…

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".

Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.
Post reply on HN