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

Interview with Zig language creator Andrew Kelley [video]

youtube.com

Post reply on HN
Print view View original

201–210 of 210 posts

Re: Interview with Zig language creator Andrew Kelley [video]

#201

Post by int_19h »

pron wrote: post #15
notacoward wrote: post #13

Earlier quoted context omitted.

> The vast majority of programmers don't use low-level languages for writing applications I work in a multi-million-line codebase, a significant majority of which is very far from that "need perfect control" domain but is written in a what I'd call a mid-level language - a high-abstraction dialect of C++. So I'd say GP is correct, that too many people are stuck writing code in the wrong language for the task at hand.…

I totally agree, and I think that C++ is exactly this "wrong kind of language," and Rust follows in its footsteps, but I'm sure others disagree. For example, for decades Microsoft has shown an attraction to this kind of languages (they love C++, C# is going down that path, and they're showing interest in Rust), so it might ultimately be a matter of taste -- a personal aesthetic preference -- unless somebody is ever a…

How is C# similar to C++ in that regard? It's a much higher-level language.

Re: Interview with Zig language creator Andrew Kelley [video]

#202

Post by wtetzner »

nulltype wrote: post #196
littlestymaar wrote: post #179

Earlier quoted context omitted.

(This was a reference to the Go language, which after a decade saying “generics aren't needed” and even “the lack of generics is a feature”, are eventually shoehorning them in the language in their Go2 campaign.)

I think they've been saying "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." since 2013: https://web.archive.org/web/20130410000959/https://golang.or...

That's what they've been saying, but I don't buy it.

I mean, the workarounds are horrible code generation tools and reflection. How were those ever not considered to be more complex than generics?

Re: Interview with Zig language creator Andrew Kelley [video]

#203

Post by [deleted] »

int_19h wrote: post #200
edflsafoiewq wrote: post #153

Earlier quoted context omitted.

The question is how to do automatic resource management. There are no checks of any sort, runtime or not, to help you here (correct me if I'm wrong). RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII. defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an Arra…

> defer also cannot handle resources whose lifetimes do not correspond to nested scopes It can, it's just more explicit about it. In a language with destructors, you'd do RAII here by having a list destructor that cleans up each element in turn. In a language with defer, the same destructor becomes a regular function that you'd invoke in the deferred expression.

[deleted]

Re: Interview with Zig language creator Andrew Kelley [video]

#204

Post by edflsafoiewq »

int_19h wrote: post #200
edflsafoiewq wrote: post #153

Earlier quoted context omitted.

The question is how to do automatic resource management. There are no checks of any sort, runtime or not, to help you here (correct me if I'm wrong). RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII. defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an Arra…

> defer also cannot handle resources whose lifetimes do not correspond to nested scopes It can, it's just more explicit about it. In a language with destructors, you'd do RAII here by having a list destructor that cleans up each element in turn. In a language with defer, the same destructor becomes a regular function that you'd invoke in the deferred expression.

The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc.

The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements. If you call, say, replace_range on a list of strings, it will leak the replaced strings.

Re: Interview with Zig language creator Andrew Kelley [video]

#205

Post by mwkaufma »

int_19h wrote: post #199
cycloptic wrote: post #148

Earlier quoted context omitted.

Thank you for the examples. I'm not sure std::function is a good comparison. After some research it seems this used to be in the spec, but it was removed because nobody supported it correctly and it seems it was too difficult to do it in a type-safe manner anyway: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p030... The other thing is that Zig doesn't seem to have any real plans to support C++-style closur…

C++-style closures are unrelated to custom allocators, since they're not heap-allocated.

You are correct that the type the compiler creates for a lambda is allocated in-place, usually on the stack, and perform no heap-allocs. However if you pass it to a std:: function it will be _boxed_ and std::function _will_ heap alloc the space for it. This alloc is what's not customizable.

Re: Interview with Zig language creator Andrew Kelley [video]

#206

Post by int_19h »

edflsafoiewq wrote: post #204
int_19h wrote: post #200

Earlier quoted context omitted.

> defer also cannot handle resources whose lifetimes do not correspond to nested scopes It can, it's just more explicit about it. In a language with destructors, you'd do RAII here by having a list destructor that cleans up each element in turn. In a language with defer, the same destructor becomes a regular function that you'd invoke in the deferred expression.

The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc. The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements. If you call, say, replace_range on a list of strings, it will leak the replaced strings.

> The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc.

That's separate from the destructor for the entire list. It does mean that the code that removes an element from the list has to explicitly invoke the destructor for it - which is in agreement with using "defer" to explicitly invoking destructors for locals.

> The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements.

But you can have a generic notion of a destructor - that's orthogonal to whether destructors are invoked explicitly. You just have an interface (or trait, or whatever it's called) that exposes a destructor method for a type.

Re: Interview with Zig language creator Andrew Kelley [video]

#207

Post by int_19h »

mwkaufma wrote: post #205
int_19h wrote: post #199

Earlier quoted context omitted.

C++-style closures are unrelated to custom allocators, since they're not heap-allocated.

You are correct that the type the compiler creates for a lambda is allocated in-place, usually on the stack, and perform no heap-allocs. However if you pass it to a std:: function it will be _boxed_ and std::function _will_ heap alloc the space for it. This alloc is what's not customizable.

That's fair, but std::function is not specifically about lambdas (As Boost.Function, it predates them, in fact) - it's about wrapping an arbitrary callable in a way that allows erasing its type. Idiomatic C++ rarely uses that class - I don't think it's used anywhere else in the standard library, even though it has plenty of higher-order functions etc. Turns out that closures that can only be passed in and not returned are still plenty useful.

Re: Interview with Zig language creator Andrew Kelley [video]

#208

Post by mratsim »

pron wrote: post #195
elcritch wrote: post #191

Earlier quoted context omitted.

After reading your previous comment, I read a bit more about comptime. It does seem to be able to handle most of the cases I could think of wanting macros for, and it is a nice UX in that it's really like "bounded macros" and prevents building arbitrary new semantics. Though thinking on two levels in a given function does seem tricky to me, but perhaps that's just familiarity. Personally, I kind of like having separa…

The beauty of comptime is that, unlike with macros, you don't need to think on two levels. The semantics is the same as if everything were done at runtime. To read a comptime function you can completely ignore the distinction between compilation time and runtime. To write it you need to know that some operations are only available at compile-time. See my comment here about "Zig' ": https://news.ycombinator.com/item?i…

In Nim the equivalent is using a `static:` block, then everything inside has normal Nim syntax but evaluated at compile-time.

You can also do `const a = static(foo(x, y, z))` to force normal function to be evaluated at compile-time and store them in a constants.

Hence you don't need to use macros for compile-time evaluation in Nim just like in Zig. However macros are necessary for AST manipulation.

Re: Interview with Zig language creator Andrew Kelley [video]

#209

Post by mwkaufma »

int_19h wrote: post #207
mwkaufma wrote: post #205

Earlier quoted context omitted.

You are correct that the type the compiler creates for a lambda is allocated in-place, usually on the stack, and perform no heap-allocs. However if you pass it to a std:: function it will be _boxed_ and std::function _will_ heap alloc the space for it. This alloc is what's not customizable.

That's fair, but std::function is not specifically about lambdas (As Boost.Function, it predates them, in fact) - it's about wrapping an arbitrary callable in a way that allows erasing its type. Idiomatic C++ rarely uses that class - I don't think it's used anywhere else in the standard library, even though it has plenty of higher-order functions etc. Turns out that closures that can only be passed in and not returne…

In my dayjob as a code-reviewer, I see it in code-bases a lot. Between the generic name and elevated status in the std namespace, it's a natural tool for developers to reach for, across experience-levels. I speculate that the boxing side-effects are not well understood, given how many times I have to lift them out of hot-loops (despite the many unverified claims that "oh, LLVM will inline and optimize that away, no worries, teehee").

In general, I have not observed a consensus for 'idiomatic' C++, even within a single project. I say this as someone who wishes there was, because my job would be a lot easier if dependencies were less heterogeneous :)

Re: Interview with Zig language creator Andrew Kelley [video]

#210

Post by edflsafoiewq »

int_19h wrote: post #206
edflsafoiewq wrote: post #204

Earlier quoted context omitted.

The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc. The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements. If you call, say, replace_range on a list of strings, it will leak the replaced strings.

> The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc. That's separate from the destructor for the entire list. It does mean that the code that removes an element from the list has to explicitly invoke the destructor for it - which is in agreement with using "defer" to explicitly invoking destructors for locals. > The other issue…

You could but Zig does not.
Post reply on HN