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

161–170 of 284 posts

Re: Type resolution redesign, with language changes to taste

#161

Post by kprotty »

api wrote: post #93
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.

My take, unfortunately, is that Zig might be a more modern C but that gives us little we don’t already have. Rust gives us memory safety by default and some awesome ML-ish type system features among other things, which are things we didn’t already have. Memory safety and almost totally automatic memory management with no runtime are big things too. Go, meanwhile, is like a cleaner more modern Java with less baggage.…

Zig gives things we really dont have yet: C + generics + good const eval + good build system + easy cross compilation + modern niceties (optionals, errors, sum types, slices, vectors, arbitrary bit packing, expression freedom).

Are there any other languages that provide this? Would genuinely consider the switch for some stuff if so.

Re: Type resolution redesign, with language changes to taste

#162

Post by txdv »

sesm wrote: post #100

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

I think zig is striving for language minimalism, make it minimal as possible then if a feature optimized multiple places use cases benefit

Re: Type resolution redesign, with language changes to taste

#163

Post by wvlia5 »

rtfeldman wrote: post #15
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.

I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark). The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to…

What's the main value proposition of roc? I found interesting tags (like symbols in mathematica) and tags with payloads (like python namedtuple or dataclasses). I haven't seen this elsewhere. Otherwise seems quite typical (Pattern matching is quite common, for example).

Example programs that you couldn't easily express in other languages?

Re: Type resolution redesign, with language changes to taste

#164

Post by lionkor »

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.

And Zig isn't stable yet

Re: Type resolution redesign, with language changes to taste

#165

Post by winterqt »

ChrisSD wrote: post #143

> Many projects including Chromium, boringssl, Firefox, and Rust call SystemFunction036 from advapi32.dll because it worked on versions older than Windows 8. That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chro…

(This is a response to a different devlog entry on the same page, not TFA.)

Re: Type resolution redesign, with language changes to taste

#166

Post by skavi »

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 am going to ask a question that is is definitely not the place for, but I am not involved with Zig in any way and am curious, so I hope you'll indulge me.

I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change:

        /// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified
        /// in the type to avoid `MultiArrayList(T)` depending on the alignment of `T` because this
        /// can lead to dependency loops. See `allocatedBytes` which `@alignCast`s this pointer to
        /// the correct type.
How could relying on `@alignOf(T)` in the definition of `MultiArrayList(T)` cause a loop? Even with `T` itself being a MultiArrayList, surely that is a fully distinct, monomorphized type? I expect I am missing something obvious.

[0]: https://codeberg.org/ziglang/zig/pulls/31403/files#diff-a6fc...

Re: Type resolution redesign, with language changes to taste

#167

Post by gabriela_c »

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.

Same for kernel drivers

Re: Type resolution redesign, with language changes to taste

#168

Post by flohofwoe »

pjmlp wrote: post #98
flohofwoe wrote: post #88

Earlier quoted context omitted.

Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many other projects) Same for the Metal shading language. C++ adds exactly nothing useful to a shading language over a C dialect that's extended with vector and matrix math types (at least they didn't pick ObjC or Swift though).

CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.

> HLSL evolution roadmap

...that's just because of the traditional-game-dev Stockholm syndrome towards C++ (but not too much C++ please!).

> Khronos future for Vulkan

As far as I'm aware Khronos is not planning to move the Vulkan API to C++ - and the 'modern C++' sample code which adds a C++ RAII wrapper on top of the Vulkan C API does more harm than good (especially since lifetime management for Vulkan object is a bit more involved than just adding a class wrapper with a destructor).

Re: Type resolution redesign, with language changes to taste

#169

Post by ChrisSD »

winterqt wrote: post #165
ChrisSD wrote: post #143

> Many projects including Chromium, boringssl, Firefox, and Rust call SystemFunction036 from advapi32.dll because it worked on versions older than Windows 8. That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chro…

(This is a response to a different devlog entry on the same page, not TFA.)

Oh sorry, I thought this was just listing changes since the branch.

Re: Type resolution redesign, with language changes to taste

#170

Post by estebank »

simonask wrote: post #139
pjmlp wrote: post #127

Earlier quoted context omitted.

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

Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust. Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.

If anything, making cranelift an LLVM replacement would likely go counter to its stated goals of being a simple and fast code generator.
Post reply on HN