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

121–130 of 210 posts

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

#121

Post by littlestymaar »

pron wrote: post #85
rfoo wrote: post #72

Earlier quoted context omitted.

I thought after Intel MPX we can all agree "memory safety" in modern languages is more about temporal stuff (i.e. use-after-free, etc) than bounds check, but maybe I'm wrong. How does those runtime checks kill UAF?

> https://github.com/ziglang/zig/pull/5998 TBD :) But here's one way that's currently being tried: https://github.com/ziglang/zig/pull/5998

(Small copy past error here, you posted the same link twice.)

Regarding https://github.com/ziglang/zig/pull/5998 here we're exactly in the realm of C, changing the allocator with a custom one with additional bookkeeping to check for memory management issues. But it tanks performances so you can't generally use it for production (and if you were in a situation were you'd do it anyway, you'd be better off with completely automatic memory management: AKA a GC).

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

#122

Post by samatman »

nextaccountic wrote: post #115
klodolph wrote: post #109

Earlier quoted context omitted.

I also wish that Rust had linear types, it would make a lot of FFI easier without resorting to unsafe{}. With linear types you can guarantee that a destructor is run, so you can create objects with lifetimes that are not only bounded from below, but bounded by above. There are some common patterns in e.g. C libraries that rely on this--for example, you might register a callback on an object, and you want to assert th…

What about making the object borrow from the closure? This can be accomplished by a method that consumes the object and returns the closure (which now owns the object), and a closure method's that borrows the object back from it.

I'm not 100% confident I follow, but this sounds like one of those backflips Rust programmers do to satisfy the borrow checker.

As in, you wouldn't write the code this way if you didn't have to. You do get memory safety in return... but you can see where the desire for a more eloquent approach might arise.

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

#123

Post by littlestymaar »

The_rationalist wrote: post #106
littlestymaar wrote: post #73

Earlier quoted context omitted.

Thanks, I was very afraid for a moment. In fact, I recently worked for a company which started using Rust in a mission critical setting back in… 2013 (yes, long before the language was stable and its future secured). Fortunately it worked, but still, it was far from a safe move.

With retrospective, do you regret choosing rust? It's poor ecosystem with low human resources can kill a startup.

I didn't make the pick (and I wouldn't have picked Rust then, I still judge this move as way too risky), and I merely worked as a contractor there and the project was already 5 years old.

That being said, a few notes on Rust on this project:

Cons:

- finding people proficient in Rust was a challenge (but that's why I go hired, so for me that was a plus;).

- in the first few years of the project, keeping up with language changes (before Rust 1.0 and even after because the project had been using nightly Rust until 2018) added.

Neural:

- the library ecosystem was nonexistent at the beginning, but because Rust has good C interop, the project just used C libraries for different things. Some where replaced by pure Rust ones later on, some didn't.

Pro: (Note: the project had important performance requirements (regarding CPU and memory consumption) so had Rust not been chosen, the project would have been written in C++.)

- When your Rust program compiles, it never crashes (except on an assert)

- I've spent exactly 0 minutes in a debugger on that project

- I've done massive refactoring without issues: you just fix the compiler errors (which are now extraordinarily clear!), you recompile and it works.

So overall, the Rust bet was a big success for this project! But you're right: the company wasn't a start-up and the company's ability to count on an existing team was vital here because hiring a new Rust dev would have been impossible in the first few years. With Rust becoming more and more popular each year, the hiring issue shouldn't be as acute right now (well, especially since Mozilla fired dozens of Rust-fluent developers earlier this month…)

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

#124

Post by networkimprov »

HourglassFR wrote: post #59

I've stumbled upon the Zig language a while back and have been checking in regularly to follow its progress. Recently I took the time to write a very small program to get a feeling for it. My thoughts : - It's a very low level language. Having written mostly Python for the past few years, it is quite the contrast. I had to force myself to think in C to get the train going - Getting my head around the error handling t…

Here is a proposal for cleaner error handling, using named catch blocks:

https://github.com/ziglang/zig/issues/5421

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

#125

Post by the_duke »

logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

There is some ongoing work towards custom allocators for containers in Rust std. [1]

Right now you could also go no_std (you still get the core library, which does not contain any allocating data structures) and use custom containers with a passed in allocator.

Zig is definitely a cool language, and it will be interesting if they can come up with good solutions to memory management!

But sentences like these in the documentation [2] would make me prefer Rust for most low level domains (for now):

> It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. Note that a slice is a form of pointer, in that it references other memory. ...

> ... the documentation for the function should explain who "owns" the pointer

[1] https://github.com/rust-lang/wg-allocators

[2] https://ziglang.org/documentation/master/#toc-Lifetime-and-O...

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

#126

Post by samatman »

identity0 wrote: post #119
Kednicma wrote: post #3

I hope that we're not stuck writing piles of low-level code for all eternity. We don't need more than a few pages of each low-level language, and while I do really like Zig's qualities compared to C, I'd still like to minimize the amount of Zig or C total that has to be written. I think that our community's equivalent of "where's my flying car?" is "where's my higher-level language?"

There are literally 100s of high level languages, for every imaginable programming paradigm. If you want to write fast code where you control memory and don't use a garbage collector, C, C++, and Rust are your only options. It's nice to see new additions to the list.

Ada, D, Pascal/Delphi, and yes, Fortran, are all still options.

I think Zig has the potential to be the best of them, fwiw.

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

#127

Post by edflsafoiewq »

pron wrote: post #22
tobz1000 wrote: post #17

Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts. Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implicati…

Zig gives you memory safety (or, rather, will ultimately do that), but it does so in a way that's different from both languages with garbage collection (whether tracing or reference-counting) or with sound type-system guarantees a-la Rust. It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production. You lose soundness, but we don't h…

Does zig have an answer to RAII yet?

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

#128

Post by fsociety »

cycloptic wrote: post #71
voldacar wrote: post #69

Earlier quoted context omitted.

It isn't really a matter of can do/cannot do. It's more about the default patterns promoted by the idiomatic way of writing code. Yeah you could write C++ code that constantly passes around allocators while also using STL heavily, but it will be verbose, unnatural, and ugly. As well as having nicer syntax in general and real metaprogramming instead of the brain damage that is templates, zig promotes this kind of allo…

I'm not sure what you mean that it's verbose, unnatural and ugly. To me it looks the same. In C++, you have to pass around an allocator to your templates. You can typedef this away if you want. In Zig, you have to pass around an allocator as a function argument or a struct member. You can comptime this away if you want. Is there some fundamental way that I missed that Zig changes this? If your actual complaint is tha…

The difference is you have to pass an allocator to the standard library functions in Zig. That’s why it is idiomatic compared to C++.

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

#129

Post by fsociety »

pron wrote: post #116
AsyncAwait wrote: post #104

Earlier quoted context omitted.

I meant a borrow checker, which I assumed was clear from what I was replying to. Yes, Zig does do runtime checks in dev builds and I did not mean to imply otherwise, I don't think the runtime checks provide the same set of benefits. Just so we're clear, I like Zig :-)

> I don't think the runtime checks provide the same set of benefits. Of course not, but that doesn't mean Zig is less effective at achieving correctness. It just does so in a different way -- it trades sound guarantees for less sound ones and a simpler language with a faster cycle. Is one better than the other? Hard to say. Only empirical study could settle that.

I’d argue it does mean it is less effective at achieving correctness but the trade-off made is the whole point of Zig. Simple language that is really a better C.

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

#130

Post by pron »

littlestymaar wrote: post #120
pron wrote: post #98

Earlier quoted context omitted.

> it's also a really complex one! No, it's a very simple one, so much so that it's erasable: https://news.ycombinator.com/item?id=24293611 And still it is probably the most complex aspect of Zig. > Zig is cool, but I hoped the “generics are too complex of a feature” meme would die now that Go is getting generics, and I'd be really sad to see come back… You've misunderstood me. Generics are a good thing -- if that's a…

> But if you have generics and procedural macros, it turns out that you can do the work of both with a feature that's simpler than either. Here I think we just have a different subjective perception of what simplicity is. I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer) Anecd…

> I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer)

OK, but that's not quite the situation. Here we're talking about languages that have, or will have, the single "more powerful" construct, and also the more specific, special case one, as two separate constructs, even though one of them would have sufficed.

Again, Zig has parameterized types, and very elegant and powerful ones -- they're functions that take some types as argument and return a type. It just doesn't have generics as a separate construct. Rather, it is a special case of a more general one (that Rust and C++ will also have).

Post reply on HN