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

111–120 of 284 posts

Re: Type resolution redesign, with language changes to taste

#111

Post by VorpalWay »

bboozzoo wrote: post #106
VorpalWay wrote: post #95

Earlier quoted context omitted.

Go has a garbage collector though. This makes it unsuitable for many use cases where you could have used C or C++ in the past. Rust and Zig don't have a GC, so they are able to fill this role. GC is a showstopper for my day job (hard realtime industrial machine control/robotics), but would also be unwanted for other use cases where worst case latency is important, such as realtime audio/video processing, games (where…

> GC is a showstopper for my day job (hard realtime industrial machine control/robotics) Which is a very niche use case to begin with, isn't it? It doesn't really contradict what the parent comment stated about Go feeling like modern C (with a boehm gc included if you will). We're using it this way and it feels just fine. I'd be happy to see parts of our C codebase rewritten in Go, but since that code is security sen…

> Which is a very niche use case to begin with, isn't it?

My specific use case is yes, but there are a ton of microcontrollers running realtime tasks all around us: brakes in cars, washing machine controllers, PID loops to regulate fans in your computer, ...

Embedded systems in general are far more common than "normal" computers, and many of them have varying levels of realtime requirements. Don't believe me? Every classical computer or phone will contain multiple microcontrollers, such as an SSD controller, a fan controller, wifi module, cellular baseband processor, ethernet NIC, etc. Depending on the exact specs of your device of course. Each SOC, CPU or GPU will contain multiple hidden helper cores that effectively run as embedded systems (Intel ME, AMD PSP, thermal management, and more). Add to that all the appliances, cars, toys, IOT things, smartcards, etc all around us.

No, I don't think it is niche. Fewer people may work on these, but they run in far more places.

Re: Type resolution redesign, with language changes to taste

#112

Post by tialaramex »

Cloudef wrote: post #86
tialaramex wrote: post #81

Earlier quoted context omitted.

Where does the name "zero type" come from? In type theory this is called an "empty" type because the set of values of this type is empty and I couldn't find (though I have no idea where to start) mention of it as a "zero" type. This stuff is foundational and so it's certainly a priority to get it right (which C++ didn't and will be paying for until it finally collapses under its own weight) but it's easier to follow…

I think rust calls them "zero sized types".

The ZSTs are unit types. They have one value, which we usually write as just the type name, so e.g.

    struct Goose;

    let x = Goose; // The variable x has type Goose, but also value Goose, the only value of that type
The choice to underscore that Rust's unit types have size zero is to contrast with languages like C or C++ where these types, which don't need representing, must nevertheless take up a whole byte of storage and it's just wasted.

But what we're talking about here are empty types. In Rust we'd write this:

    enum Donkey {}

    // We can't make any variables with the Donkey type, because there are no values of this type and a variable needs a value

Re: Type resolution redesign, with language changes to taste

#113

Post by hansvm »

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.

It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day.

Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.

Re: Type resolution redesign, with language changes to taste

#114

Post by jackhalford »

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…

> Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year.

Not at all, if the team needs 30 more years they should take it.

> However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0.

Funny you see it as bleak when most of the community sees it as the most excitinh thing in systems programming happening right now.

I think you comment is in bad faith, all the big zig projects say that the upgrade path is never a main concern, just read HN comments here or on other zig threads, people ask about this a lot and maintains always answer.

Re: Type resolution redesign, with language changes to taste

#116

Post by jodleif »

lionkor wrote: post #62
ryanxsim wrote: post #55

Earlier quoted context omitted.

I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

I found swift way more enjoyable than rust as a C++ alternative. It even has first class-ish interop now.

Re: Type resolution redesign, with language changes to taste

#117

Post by whobre »

nickysielicki wrote: post #27
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.

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

The forever backwards compatible promise of C++ is pretty much the main reason anyone is using C++.

Re: Type resolution redesign, with language changes to taste

#118

Post by nulltype »

lerno wrote: post #110
weebull wrote: post #72

Earlier quoted context omitted.

Two different philosophical approaches with Zig and Rust. - Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can. - Rust: let's make the compi…

> However we value explicitness and allow the developer to do anything they need to do* * except for having unused variables. Those are so dangerous the compiler will refuse the code every time.

It’s hard to say that one needs unused variables.

Re: Type resolution redesign, with language changes to taste

#119

Post by pjmlp »

ovao wrote: post #107
pjmlp wrote: post #40

Earlier quoted context omitted.

Only because the likes of Vercel and Netlify barely offer anything else on their free tiers. When people go AWS, Azure, GCP,... other languages take the reigns.

Do you have any stats on the latter?

My own anecdote.

Re: Type resolution redesign, with language changes to taste

#120

Post by rllj »

lerno wrote: post #110
weebull wrote: post #72

Earlier quoted context omitted.

Two different philosophical approaches with Zig and Rust. - Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can. - Rust: let's make the compi…

> However we value explicitness and allow the developer to do anything they need to do* * except for having unused variables. Those are so dangerous the compiler will refuse the code every time.

They are indeed dangerous, and I think this is a pretty good example of why.

https://andrewkelley.me/post/openzfs-bug-ported-zig.html

Post reply on HN