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

Zig 0.8.0 Release Notes

ziglang.org

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Zig 0.8.0 Release Notes

#71

Post by oconnor663 »

gnuvince wrote: post #67
Rusky wrote: post #10

The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…

> And, I've seen it in Rust as a "workaround" for the borrow checker, where that framing tends to make it feel like cheating or settling, which IMO is unfortunate since when people arrive at it for other reasons it seems to have a lot of other benefits! Great point! I've been using Rust for 4–5 years now and putting objects in Vecs and using integers as "pointers" felt a lot like cheating (i.e., "I'm doing the wrong™…

This is basically what an Entity Component System is, right? I always find myself linking back to this talk: https://youtu.be/aKLntZcp27M

Re: Zig 0.8.0 Release Notes

#72

Post by b3morales »

scraptor wrote: post #70
b3morales wrote: post #69

Earlier quoted context omitted.

Can you point out the section of the release notes that discusses this change? I'd like to read more and I'm not able to figure out what you're referring to.

https://ziglang.org/download/0.8.0/release-notes.html#Rework...

Thank you!

Re: Zig 0.8.0 Release Notes

#73

Post by coldtea »

mkishi wrote: post #66
coldtea wrote: post #64

Earlier quoted context omitted.

> we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers Well, this says that zig team reported those bugs as "release blockers". Doesn't mean the LLVM release team also considered them release blockers (or that it had too).

Could you elaborate on when they wouldn't treat regressions as blockers? I'm not very familiar with LLVM and couldn't gather that from the "How To Release LLVM To The Public" docs [1]. [1] https://llvm.org/docs/HowToReleaseLLVM.html

Well, e.g. they say: "Only critical bugs found during this testing phase will be fixed." - so e.g. not all regressions are necessarily release blockers.

Besides, whatever the "process" says, isn't it ultimate up to the release manager?

Re: Zig 0.8.0 Release Notes

#74

Post by ncmncm »

papaf wrote: post #48
ncmncm wrote: post #46

Earlier quoted context omitted.

You almost got there. What makes a language powerful is the ability to put essential semantics into a library where they can be got right once, so all users of the library benefit. It is worth design, implementation, testing, optimization effort if the results can be delivered over and over, in many different contexts, reliably. Destructors are the necessary ingredient to pull transaction semantics into libraries. Wi…

I agree with your comment about libraries. Destructors biggest advantage is in well used libraries. Any interesting code involves custom classes written by less experienced developers that are only used once or twice in an application -- it is there that that the complexity of destructors hurt.

There certainly are design complexities in C++, around copy and move constructors and various operators. Some of those could have been avoided, in hindsight, and new languages can.

None of those complexities spill over onto destructors. They were perfect in their original conception, and are unchanged 40 years on. They evoke no regrets. No bugs trace to anything unfortunate about destructors.

Re: Zig 0.8.0 Release Notes

#75

Post by ncmncm »

somethingor wrote: post #58
ncmncm wrote: post #44

Earlier quoted context omitted.

It would be better if a C or C++ header sufficed to declare things so they may be called directly from Zig, without need for matching declarations in Zig. Or, do they? For it to be useful, types would need to be imported, too. That would need destructor and overloading support. Which is doable.

That is how Zig works with C code: - https://ziglang.org/learn/overview/#integration-with-c-libra... - https://ziglang.org/documentation/master/#Import-from-C-Head...

OK, that is very cool. It makes Zig seem like a markedly better choice than Rust for adoption in Linux.

Re: Zig 0.8.0 Release Notes

#76

Post by ncmncm »

pjmlp wrote: post #56
ncmncm wrote: post #44

Earlier quoted context omitted.

It would be better if a C or C++ header sufficed to declare things so they may be called directly from Zig, without need for matching declarations in Zig. Or, do they? For it to be useful, types would need to be imported, too. That would need destructor and overloading support. Which is doable.

Depends how much modern C and C++ Zig wants to implement in order to understand the types. Generics, lambdas, concepts, templates, exceptions, ....

If Zig doesn't have lambdas yet, that is a clear omission. It would be wise to reserve syntax for it early.

Re: Zig 0.8.0 Release Notes

#77

Post by ncmncm »

pjmlp wrote: post #57
masklinn wrote: post #55

Earlier quoted context omitted.

> What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.". Right, but we're not discussing C++ are we? We're discussing RAII. C++'s mistakes are C++'s mistakes, adding RAII to a language doesn't imply you have to replicate C++'s mistakes, nor are C++'s mistakes issues with the concept of RAII, or destructors.

Had RAAI been properly implemented in C++, doing something like new std::string("something") should have been a compiler error. From type theory point of view, ideally RAII aware types should only compose with outher RAII types without escape hatches. Rust and Ada do it better in this regard.

What do you imagine is typologically wrong with new std::string("pjmlp")?

Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom; and std::string is limited (expect unicode-aware strings in '23). But a heap-allocated string object is a thing equally easy and useful to express in Rust. (Dunno about Ada: does it have any analog of destructors, yet?)

Re: Zig 0.8.0 Release Notes

#78

Post by lenkite »

c0ast wrote: post #24
lenkite wrote: post #19

Earlier quoted context omitted.

I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically. https://github.com/ziglang/zig/issues/782

With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.

Destructors don't do any strange thing in C++ apart from closing allocated resources - so in reality you always know what happens. This presents mistakes and decreases code length in calling code.

Re: Zig 0.8.0 Release Notes

#79

Post by txdv »

Jarred wrote: post #26

I’ve been using Zig for a new JavaScript build tool and I really like it. It’s great for writing performance-critical code. It took me about two weeks to feel comfortable & productive in it.

Can you link to the github repo?

Re: Zig 0.8.0 Release Notes

#80

Post by masklinn »

ncmncm wrote: post #77
pjmlp wrote: post #57

Earlier quoted context omitted.

Had RAAI been properly implemented in C++, doing something like new std::string("something") should have been a compiler error. From type theory point of view, ideally RAII aware types should only compose with outher RAII types without escape hatches. Rust and Ada do it better in this regard.

What do you imagine is typologically wrong with new std::string("pjmlp") ? Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom; and std::string is limited (expect unicode-aware strings in '23). But a heap-allocated string object is a thing equally easy and useful to express in Rust. (Dunno about Ada: does it have any analog of destructors, yet?)

> What do you imagine is typologically wrong with new std::string("pjmlp")?

You have to remember to `free` the string explicitely.

> Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom

Is it? Isn't that going to create an `unique_ptr`?

Post reply on HN