Live data from Hacker News

Interview with Zig language creator Andrew Kelley [video]

youtube.com

111–120 of 210 posts

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

#111
post #88

Earlier quoted context omitted.

The first rule of C is that no one masters C, but you could try anyway and still have time to master Zig in a matter of weeks, which is a rounding error. Given that both offer a C compatible ABI, what would serve your projects better?

I can't help but feel like in our industry C is successful (vs its 80s competition of Pascal/Modula-2, or Ada etc.) partially because of some of the same reasons that Git is successful now. Yes, it is powerful and flexible; but also in some ways unnecessarily arcane and 'dangerous' and _this gives the user a feeling of cleverness_ that is seductive to software engineers. Put another way: Most of us enjoy the mental s…

Given that you can "write Fortran in any language", I find this analysis unlikely.

I much prefer writing Python or Lisp code than C++, but I can't do my job in Python or Lisp code, so I write C++.

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

#112
post #25

Zig is appealing to me, but I wonder whether time spent mastering Zig would be better spent mastering C.

C has many advantages over Zig, mostly because it's standardized and extant.

Don't think Zig is worth it when it doesn't have linear or affine types.

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

#113

Earlier quoted context omitted.

>STL-heavy C++17 and beyond is, of course, the salient example. I've seen "clever" code in that style, but never great code. Maybe the authors of that code just had different priorities, such as maximising compilation time.

Hah! Yeah, that does seem sometimes like it must have been a deliberate goal, doesn't it? Got a good laugh out of that. The number of cycles wasted by C++ compilers fumbling toward solutions that would have been obvious in a better language (thousands of server-years per day where I work) is a legitimate ecological concern.

Frankly I find HN more of an impediment to rapid development than C++ compile times.

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

#114
post #55

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…

Linear types would be even better though. Still safe like Rust.

http://ats-lang.sourceforge.net/ baby!

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

#115
post #55

Earlier quoted context omitted.

Linear types would be even better though. Still safe like Rust.

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.

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

#116
post #26

Earlier quoted context omitted.

> On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much This is not true. Zig places a strong emphasis on memory safety, it just does so in a way that's very different from either Java's or Rust's. I wrote more about this here: https://news.ycombinator.com/item?id=24293329

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.

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

#117
post #105
post #100

Earlier quoted context omitted.

Yes, plus introspection. Zig tries very, very hard to avoid macros, so macros are an anti-feature from Zig's perspective. That you could do what Zig finds important for its domain, like conditional compilation, writing a typesafe println, generic types, and generating pretty-printing routines all in simple Zig without macros is a cool discovery. I don't know if it's true, but I think the desire to avoid macros at all…

I do love how zig's comptime naturally led to generics without extra syntax. But after using nim i'm convinced that macros make even more sense for systems programming. They can even affect performance -- nim's macros can generate types that would be difficult to write by hand. I also take issue with your statement that zig is "more minimal" since that only applies to the user's perspective -- from the compiler's per…

> But after using nim i'm convinced that macros make even more sense for systems programming.

Macros are controversial. I love them in Scheme and Clojure, but I wouldn't want them in any language aimed at a larger, more mainstream crowd. At the very least, macros introduce another meta-language to know (and if they're in a language with a complex type-level language like Rust or Haskell then they're a third language within the language), but I think it's a matter of personal aesthetic preference.

> But i vaguely recall already discussing this distinction with you so i don't want to rehash it.

Maybe we did. :)

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

#118
post #80

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…

I would hardly use Python as an example of good string support. Of all languages I have worked with it has some of the worst. Look at Rust instead for a modern language with good string support.

I believe OP was saying that the Python 2 → 3 debacle shows it's important to get strings right the first time.

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

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

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

#120
post #98

Earlier quoted context omitted.

> But C++/Rust can never have Zig's primary feature -- simplicity Sounds like a Go pitch, except Zig ain't Go. And while comptime is a cool feature, it's also a really complex one! > In other words, it has generics, but without having generics as a special construct. Zig recognises that once you have that other feature (compile-time introspection) you don't need generics as a separate construct, but they can be just…

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

Anecdotal note: more than 10 years ago, the Go team pitched why they didn't need generics nor macros, because code generation would solve both problems (+ others), and now they're on their way back to add generics to Go (with a lot of hassle).

Post reply on HN