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

151–160 of 284 posts

Re: Type resolution redesign, with language changes to taste

#151

Post by [deleted] »

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

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…

[deleted]

Re: Type resolution redesign, with language changes to taste

#152

Post by kristoff_it »

throwaway17_17 wrote: post #149
mlugg wrote: post #146

Hi, author of this devlog here! Not to dismiss concerns about breaking language changes, but there seems to be a bit of a misconception here that this compiler change was highly breaking and will require significant effort from Zig users to update for. Perhaps I unintentionally gave that impression in the devlog or the PR writeup, apologies if so---but it's not the case! Although there were breaking changes in this p…

I made one of the comments that seems to be perceived a critical of the changes (I made a statement about the seemingly brief paragraph on changing semantics). As I replied to Andrew, I will tell you: the PR had a large amount of planning and implementation that seems of great quality. I certainly did not intend to discredit you or the obviously large amount of work you have done previously or on the change. I guess…

Your comment was reasonable, I don't know why it got downvoted that hard.

Re: Type resolution redesign, with language changes to taste

#153

Post by mlugg »

Cloudef wrote: post #138
mk12 wrote: post #104

Earlier quoted context omitted.

No, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.

I see. I can not give more insightful answer here then. From personal experience, I've noticed with 0.16 with the std.Io async stuff that you cannot do: io.concurrent(foo, .{}); where foo's return type is `error{foobar}!noreturn`, because the compiler crashes when it tries to use that type as a std.Io.Future(T)'s struct field. Might be related or not.

It is indeed (somewhat) related, and in fact that was fixed by this PR: https://github.com/ziglang/zig/issues/25771

Re: Type resolution redesign, with language changes to taste

#154

Post by keybored »

lionkor wrote: post #126
mgoetzke wrote: post #109

Earlier quoted context omitted.

As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all. One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.

See my other comment[1] It replaces C++ for me, so I would say it's "a C++" [1]: https://news.ycombinator.com/item?id=47334275

And in a world of only you your claim is true.

Re: Type resolution redesign, with language changes to taste

#155

Post by CyberDildonics »

weebull wrote: post #72
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

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…

as few footguns as possible

There are no destructors so all the memory ownership footguns are still there.

Re: Type resolution redesign, with language changes to taste

#157

Post by duped »

nulltype wrote: post #118
lerno wrote: post #110

Earlier quoted context omitted.

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

If I comment out sections of code while debugging or iterating I don't want a compile error for some unused variable or argument. Warning. fine, but this happens to me so frequently that the idea of unused variables being an error is insane to me.

Re: Type resolution redesign, with language changes to taste

#158

Post by _bohm »

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…

A pretty obvious explanation as to why Odin has more games written in it is that the language is somewhat explicitly marketed towards that use-case, even going as far to have a vendor library collection that includes many popular game dev libraries.

Re: Type resolution redesign, with language changes to taste

#159

Post by kprotty »

pjmlp wrote: post #127
lionkor wrote: post #105

Earlier quoted context omitted.

I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++". For example, high performance servers (voltlane.net), programming languages ( https://github.com/HF-Foundation , https://github.com/lionkor/mcl-rs , and one private one), webservers (beampaint.com) and lots of other domains. Rust is cl…

> found no place in which C++ is a better fit than Rust, and so it's my "new C++". Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.

There are places a language could be a better fit, but which haven't adopted it. E.g. most languages over typescript on the backend, most systems programming languages over Java for games.

Re: Type resolution redesign, with language changes to taste

#160

Post by smj-edison »

microtonal wrote: post #76
lionkor wrote: post #62

Earlier quoted context omitted.

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.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.

I believe Rust is mainly being used for driver development, which seems a great fit (there's so many people of different skill levels who write Linux drivers, so this should help avoid bad driver code being exploited). It may also end up in the core systems, but it also might not fit there as well.
Post reply on HN