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

121–130 of 181 posts

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

#121

Post by pcwalton »

tapirl wrote: post #96
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…

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.

> Zig is good at all the areas Rust is good at.

Not memory safety.

> Zig is also good at game development which Rust is not good at.

Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, visibility ranges with dithering, percentage-closer soft shadows, additive animation blending, generalized animation, animation masks, offset allocation, volumetric fog, the postprocessing infrastructure, chromatic aberration, SMAA, PBR anisotropy, skinned motion vectors, screen-space reflections, depth of field, clearcoat, filmic color grading, GPU frustum culling, alpha-to-coverage, percentage-closer filtering, animation graphs, and irradiance volumes. In addition to extremely rapid general engine progress, there have also successful titles, such as Tiny Glade.

Whether Rust can be a productive language for game development was an interesting question a few years ago. At this point the answer is fairly clear.

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

#122

Post by pcwalton »

zozbot234 wrote: post #112
anacrolix wrote: post #101

Earlier quoted context omitted.

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.

I'm not convinced, actually. The problem is that every proposal for safe C++ that I've seen sacrifices compatibility with the broader C++ ecosystem. Yes, you could graft borrow checking onto a C++-like semantics, but what you would end up creating is an incompatible dialect of C++--essentially a new language. So the resulting ecosystem would actually be smaller than that of Rust.

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

#123

Post by ibraheemdev »

> The message has some weird mentions in (alloc565), but the actual useful information is there: a pointer is dangling.

The allocation ID is actually very useful for debugging. You can actually use the flags `-Zmiri-track-alloc-id=alloc565 -Zmiri-track-alloc-accesses` to track the allocation, deallocation, and any reads/writes to/from this location.

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

#124

Post by pcwalton »

chrisco255 wrote: post #114
pcwalton wrote: post #91

Earlier quoted context omitted.

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

If your pointers have to have a bit offset, then now a pointer isn't just 1 hardware word, which would be odd to say the least for a systems language. (It would also be slow, because making a load anything other than a load is something you really don't want to do; you would lose the ability to fold into addressing modes on x86 in many cases for example.)

If some pointers have a bit offset but others don't, OK, I guess, but I'd argue that at that point it'd be a cleaner design to just have a "pointer plus bit offset" be a separate type from "regular pointer". And that would get back to the problem that you would have a type that you couldn't take a "regular" pointer to.

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

#125

Post by pcwalton »

Gibbon1 wrote: post #106
pcwalton wrote: post #91

Earlier quoted context omitted.

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

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.

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

#126

Post by pcwalton »

zozbot234 wrote: post #115
pcwalton wrote: post #91

Earlier quoted context omitted.

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

C and C++ (the latter unofficially, IIRC) have this with bitfield types, and they aren't very well loved, precisely because they aren't addressable.

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

#127

Post by zozbot234 »

pcwalton wrote: post #122
zozbot234 wrote: post #112

Earlier quoted context omitted.

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.

I'm not convinced, actually. The problem is that every proposal for safe C++ that I've seen sacrifices compatibility with the broader C++ ecosystem. Yes, you could graft borrow checking onto a C++-like semantics, but what you would end up creating is an incompatible dialect of C++--essentially a new language. So the resulting ecosystem would actually be smaller than that of Rust.

I think this issue is a bit overstated. What people want is not to have interop with existing C++ code, but to just keep writing C++ in the same idiomatic style. And this just isn't feasible if you want to automatically ensure memory safety. It's especially problematic in larger codebases that can't be comprehensively surveyed, which is what people mostly want to use C++ for. So, something has to give.

Rust is a bit of a different story, because the clunkiness of Pin actually makes interop with C++ (and, to a lesser extent, C) surprisingly difficult in a way that might be amenable to improvement.

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

#129

Post by littlestymaar »

pcwalton wrote: post #121
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.

> Zig is good at all the areas Rust is good at. Not memory safety. > Zig is also good at game development which Rust is not good at. Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, v…

You cannot use yourself as an argument about the productivity of Rust, you designed this language!

Joke aside, the velocity of the Bevy Engine as a whole is indeed a testament to Rust productivity.

Last year I had two groups of students who built a multiplayer FPS and a Tower defense respectively after just one and a half days of Rust class so the learning curve is clearly not as bad as people like to tell on HN.

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

#130

Post by Gibbon1 »

adgjlsfhk1 wrote: post #78
Turskarama wrote: post #31

Earlier quoted context omitted.

I honestly don't see how anyone who has used a language with both unions and interfaces could come up with anything else that makes dynamic types better. Either way you need to fulfill the contract, but I'd much prefer to find out I failed to do that at compile time.

the place where imo static languages come up short is first class functions.

I think C# has first class functions. Any pure function you can pass around. And you can create lambdas.

gcc has nested functions that can act like a closure.

And Clang has blocks.

Post reply on HN