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

Type resolution redesign, with language changes to taste

ziglang.org

Post reply on HN
Print view View original

231–240 of 284 posts

Re: Type resolution redesign, with language changes to taste

#231

Post by bro45x »

MintPaw wrote: post #207
bro45x wrote: post #201

Earlier quoted context omitted.

Zig's worth it though. I don't care for libraries that aren't maintained anyway. If they don't maintain it, it's just bad anyway. Why do you always nag about Zig. Stop shilling your C3 here.

This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable. But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good. Requiring every dependency to be constantly maintai…

Looks like all the 2 users of C3 came here to complain about Zig. Why should we listen to you?

Re: Type resolution redesign, with language changes to taste

#232

Post by CyberDildonics »

9rx wrote: post #195
7bit wrote: post #96

Earlier quoted context omitted.

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

If you make up your own definitions things can be anything you want and have or not have any label.

Re: Type resolution redesign, with language changes to taste

#233

Post by skavi »

burgerone wrote: post #186

What makes zig special as a language? I have the impression that it has quite a large fan base here on HN but don't really hear any talks about it anywhere else.

Disclaimer: I don't really use Zig (primarily a Rust dev) but I do think it's quite cool.

If you're willing to dive right into it, I'd first read a bit about the comptime system [0] then have a go at reading the source for `MultiArrayList` [1], a container which internally stores elements in SoA format.

At least, that was what got me interested.

[0]: https://ziglang.org/documentation/master/#comptime

[1]: https://codeberg.org/ziglang/zig/src/branch/master/lib/std/m...

Re: Type resolution redesign, with language changes to taste

#234

Post by steeve »

h4ch1 wrote: post #2

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

hi, i'm the founder of https://github.com/zml/zml, very happy with Zig

Re: Type resolution redesign, with language changes to taste

#235

Post by bro45x »

throwaway17_17 wrote: post #145
AndyKelley wrote: post #11

Earlier quoted context omitted.

Originally, Zig's type system was less disciplined in terms of the "zero" type (also known as "noreturn"). This was proposed, discussed, and accepted here: https://github.com/ziglang/zig/issues/3257 Later, Matthew Lugg made a follow-up proposal, which was discussed both publicly and in ZSF core team meetings. https://github.com/ziglang/zig/issues/15909 He writes: > A (fairly uncontroversial) subset of this behavior w…

Thanks for the reply Andrew, I certainly did not mean to imply any issues with trustworthiness for Zig users or prospective adopters. Also, I absolutely did not intend to imply any negatives toward Zog’s evolution or this particular development on the compiler’s internals. I enjoy all of the process and implementation content, i.e. videos, podcast, and blogs that yourself and contributors have provided through variou…

Zog? What the hell man.

Re: Type resolution redesign, with language changes to taste

#236

Post by bro45x »

AndyKelley wrote: post #11
throwaway17_17 wrote: post #7

Congratulations to the dev, a 30,000 line PR for a language compiler (and a very much non-trivial compiler) is a feat to be proud of. But a change of this magnitude is a serious bit of development and gave me pause. I understand both of the following: 1. Language development is a tricky subject, in general, but especially for those languages looking for wide adoption or hoping for ‘generational’ (program life span be…

Originally, Zig's type system was less disciplined in terms of the "zero" type (also known as "noreturn"). This was proposed, discussed, and accepted here: https://github.com/ziglang/zig/issues/3257 Later, Matthew Lugg made a follow-up proposal, which was discussed both publicly and in ZSF core team meetings. https://github.com/ziglang/zig/issues/15909 He writes: > A (fairly uncontroversial) subset of this behavior w…

You're the man Kelley, don't let the doomers get to you

Re: Type resolution redesign, with language changes to taste

#237

Post by 9rx »

CyberDildonics wrote: post #232
9rx wrote: post #195

Earlier quoted context omitted.

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

If you make up your own definitions things can be anything you want and have or not have any label.

Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented.

And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that allows C++ to become "object-oriented" ever since. I mean, who wouldn't want to latch onto a term that was about the unique features of a failed programming language that never went anywhere?

Re: Type resolution redesign, with language changes to taste

#238

Post by xthunk »

One thing I’ve noticed reading Zig discussions is that many semantics seem simple on their own but interactions can be subtle – like in the behavior fixed here.

I wonder if this ends up similar to C++ template rules where the surface looks small but the edge cases accumulate over time.

Re: Type resolution redesign, with language changes to taste

#239

Post by peesem »

Arch485 wrote: post #142
sesm wrote: post #100

Instead of implementing a workaround for types as namespaces, wouldn't it better to explicitly add namespaces to the language?

It's not so much a workaround as it is an elegance in design. In Zig, when you @import a file, that file is converted to a struct with comptime fields for all of the public members. Similarly, a "namespace" in Zig is just a nested struct with more fields. Usually it's just another import of something else. N.B.: Coffee hasn't reached my bloodstream yet; accuracy not guaranteed.

files aren't converted to structs on import, they _are_ structs (well, their contents are the inside of a struct declaration). also, public members don't become comptime fields? file structs are basically left as-is on import, nearly like you copy&pasted the file contents into a struct declaration

Re: Type resolution redesign, with language changes to taste

#240

Post by peesem »

lerno wrote: post #103

It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years. There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics. To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is…

it seems to me like the acceptance of breaking changes by the Zig community is more coming from "it's worth it to get a nice, polished language" than some "source of pride" which i personally have not seen in my time in a/the Zig discord server.

what is the problem with zig being developed for 10+ years? if people want stable languages there are stable languages to be used. if a language like zig is not achievable in less than 10 years, should it just not be developed from the start?

i think your problems with build.zig are overstated. where do you see someone saying "to build your first Hello World, first understand this build script in non-trivial Zig"? you can literally just do `zig run file.zig`, so if someone is advocating for that then i think many would agree they are teaching the wrong way. i wonder if you saw an example project with a build script that was intended to show the power and possibilities of Zig rather than to be a starter guide.

Post reply on HN