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

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

401–410 of 429 posts

Re: Zig, the Small Language

#401

Post by dolmen »

littlestymaar wrote: post #125
stephc_int13 wrote: post #79

Earlier quoted context omitted.

Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. This is exactly the point.

Integer division isn't a simple one either though… Matrix multiplication are “basic operations” in the sense that you use them as the basic block of your algorithms, and in code using such blocks you really appreciate having a simple operator for those instead of littering your formula with functions calls (which is basically writing your formulas in Polish notation, not the most legible way to write formulas …)

Matrix multiplication is a niche in the programming world.

Re: Zig, the Small Language

#402

Post by cassepipe »

bb88 wrote: post #338
tialaramex wrote: post #317

Earlier quoted context omitted.

I still think the first language when I was an undergraduate (so, last century) was the correct choice: an ML in our case SML/NJ The stuff about how this actually works can come later, we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense) I agree that (safe) Rust has too much stuff for a first language for Computer Scientists. Lifetimes! Polymorphism…

> we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense) From an educational viewpoint, I don't like that EE and SWE programs have very little overlap. A lot of EE tools could be improved if EE's learned more software (particularly parsing and compilers). A lot of SWE don't get into the dirty details of a CPU and what makes it tick and see it some sor…

As I understand you advocate a bottom - up approach rather than a top-down one. I personally prefer the former over the latter as it makes more sense to me to learn how to make basic programs work before I learn what incredible things I can do with them. I have over one year of C experience in my school doing things like rewriting functions of the C stdlib and reimplementin getline() before I learn about radix sort, implement a tree or make a basic ray tracer. Thats works for me but I know there are some theory/abstraction oriented people that like to learn about algorithms first and fill in the details late. In the end if you want programming to be interesting you need both practical and theoretical knowledge so I guess you should know yourself and take the approach that work for you. Having people who want to build stuff learn abstract concepts in Scheme may be as counter-productive than having people who want to learn about clever data structures learn how to make a basic text editor in C in the terminal.

Re: Zig, the Small Language

#403

Post by pverghese »

adamdusty wrote: post #335
boywitharupee wrote: post #108

Earlier quoted context omitted.

For unused vars you can do this and the compiler will ignore it. _ = my_unsed_var;

Doesn't that entirely defeat the purpose of having the compiler not allow unused variables.

Not exactly. Because a quick grep of _ = gives you the variables which are needed to be checked before whether used or unused

Re: Zig, the Small Language

#404

Post by davidatbu »

dundarious wrote: post #398
davidatbu wrote: post #388

Earlier quoted context omitted.

> I don't see how memory safety adds anything [to algos in cryptography] as memory issues are an insignificant problem. I'm not terribly experienced in cryptography either, but I'm pretty sure that memory safety is a HUGE deal in cryptography as a whole. Heartbleed[0] was a memory safety issue. Python's cryptography package switched to Rust specifically because of memory safety [1]. [0] https://cve.mitre.org/cgi-bin/…

Heartbleed was in the parsing/business logic areas -- the areas where I said Rust's memory safety provides great benefits. When I say crypto algos, I mean implementing S-boxes in 3DES, etc.

If you agree that Rust's memory safety is hugely beneficial in cryptography, then I'd love to hear other (sub)domains (e.g., kernel code, networking code, blockchain, ...etc) that necessitate tricky data structures, making Zig a better fit than Rust (which, IIUC, is your main point here).

Re: Zig, the Small Language

#405

Post by naasking »

masklinn wrote: post #339
mayormcheeseman wrote: post #336

Earlier quoted context omitted.

I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.

> I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers So someone’s anal retentive was made into a langage mandate rather than anything actually useful? > Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Why are dead variables any dirtier than dead stores? Or unchecke…

> Why are dead variables any dirtier than dead stores?

If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this.

If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.

Re: Zig, the Small Language

#406

Post by naasking »

lopatin wrote: post #285
kristoff_it wrote: post #221

Earlier quoted context omitted.

Well if one never stops to think about its potential merits, it can surely only be perceived as dogmatic. One thing is evaluating a choice in its full context and not liking it, another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.

> you might want to take a moment to ponder the fact > Well if one never stops to think about its potential merits Listing some of those merits may be more productive than insisting people aren't thinking about it hard enough

I don't program in Zig, but I can think of a few reasons in principle:

1. WYSIWIG compiler: how many people have been complaining lately about C compilers eliminating code on them due to undefined behaviour? If you eliminate certain optimizations so your complier doesn't do this, like dead code/variable elimination, then what the code looks like is exactly what executes. This means some important optimizations may have to be done by hand. Eliminating dead variables could be one of them.

2. Arguably dead variables are a mistake. Either they're a (major) mistake because you neglected to include a value in your computation, or a (minor) mistake because you declared a superfluous variable that's never used.

3. If you want your code to be clear and as self-documenting as possible, unused variables are an impediment. I can't speak to the accuracy of Zig's analysis, but I can see how it would be annoying while working out an algorithm.

Re: Zig, the Small Language

#407

Post by pron »

pcwalton wrote: post #292
azakai wrote: post #291

Earlier quoted context omitted.

> Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel. You're right on each of those points. But (AFAIK) all those types are explici…

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C+…

> I don't see any reason why modern C++ wouldn't be just as spatially memory safe as Zig is

Well, you'd need to avoid arrays and pointer arithmetic, some of the most basic language primitives, but being safer than C++ (even though it is) is not Zig's only or even main differentiation from C++.

> But I don't actually think that makes for safer programs, empirically speaking--otherwise, C programs would be safer than C++ programs, and they generally aren't.

Once again you're begging the question by trying to draw similarities between C and Zig and using extrapolations that you yourself know to be wrong.

We both agree that the sweet spot for correctness is somewhere on the spectrum between C and Idris, but we really don't know more than that. No one is claiming that any language X that's simpler than another language Y will be more effective at producing correct programs, just as no one is claiming the same for any language X that can offer more sound guarantees than Y. In fact, we know that both of these statements are wrong.

What we know is that simplicity and soundness are both sometimes better for correctness but neither is always better for correctness. I.e., we know that we cannot make the extrapolations that you're making.

Re: Zig, the Small Language

#408

Post by dundarious »

davidatbu wrote: post #404
dundarious wrote: post #398

Earlier quoted context omitted.

Heartbleed was in the parsing/business logic areas -- the areas where I said Rust's memory safety provides great benefits. When I say crypto algos, I mean implementing S-boxes in 3DES, etc.

If you agree that Rust's memory safety is hugely beneficial in cryptography, then I'd love to hear other (sub)domains (e.g., kernel code, networking code, blockchain, ...etc) that necessitate tricky data structures, making Zig a better fit than Rust (which, IIUC, is your main point here).

I don’t have a “zig/rust is better than rust/zig” point here. The point was to say you have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away), especially since a great example of such unsafe code is data structures code, and that is where a lot of my memory errors occur. Then we got diverted into some minor points about how much benefit does memory safety at compile time give you in different domains.

I wouldn’t build a company or long-term project around Zig right now, since it’s quite young, so if the choice was just those two, I’d probably always pick Rust. But ignoring that, since Zig will probably “graduate” in a year or two: both are good for all those domains, and I’d be hard-pressed to say one is better or worse than the other without further constraints. Zig certainly seems less indirect and more lightweight, and has less of an immediate cognitive burden, but Rust’s additional burden there is providing some additional value. I really don’t like Rust’s allocation story though — AFAIK there are plenty of allocations in std that can only be controlled by swapping out the global allocator, possibly even at link time. C++ is clunky on this front too, just in a different way. C is “better” simply because the standard library is so meager, but that has never been a problem for me in practice.

Re: Zig, the Small Language

#409

Post by davidatbu »

dundarious wrote: post #408
davidatbu wrote: post #404

Earlier quoted context omitted.

If you agree that Rust's memory safety is hugely beneficial in cryptography, then I'd love to hear other (sub)domains (e.g., kernel code, networking code, blockchain, ...etc) that necessitate tricky data structures, making Zig a better fit than Rust (which, IIUC, is your main point here).

I don’t have a “zig/rust is better than rust/zig” point here. The point was to say you have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away), especially since a great example of such unsafe code is data structures code, and that is where a lot of my memory errors occur. Then we got diverted into some minor points about how much benefit does memor…

> You have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away).

Agreed.

> I really don’t like Rust’s allocation story though.

I presume this is because of the lack of ergonomic handling of OOM? Only time I've run into OOM was when training deep learning models (in Python backed by C++) on a GPU, but if I were to do that in Rust, I'm pretty sure I'd be able to avoid the memory leaks that caused OOM since allocations in a deep learning training loop are almost always deterministic.

So I would love to learn about the domains where you think OOM is a huge issue (apart from kernel code, which I'm already familiar with).

Btw, thanks for all the replies! I'm learning with every one.

Re: Zig, the Small Language

#410

Post by dundarious »

davidatbu wrote: post #409
dundarious wrote: post #408

Earlier quoted context omitted.

I don’t have a “zig/rust is better than rust/zig” point here. The point was to say you have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away), especially since a great example of such unsafe code is data structures code, and that is where a lot of my memory errors occur. Then we got diverted into some minor points about how much benefit does memor…

> You have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away). Agreed. > I really don’t like Rust’s allocation story though. I presume this is because of the lack of ergonomic handling of OOM? Only time I've run into OOM was when training deep learning models (in Python backed by C++) on a GPU, but if I were to do that in Rust, I'm pretty sure I'd…

It's not at all about OOM, actually. It's about performance, and to a lesser degree, simplifying code or architecture. Zig's FixedBufferAllocator and ArenaAllocator are very simple and very useful, and they conform to the Allocator interface that's used for every bit of allocation in std and non-std. Anyone who has written a lot of C or a certain kind of C++ will be very familiar with the concepts, and will have used them a lot. They're nothing revolutionary, but not having a "default" global allocator and having a culture of passing the Allocator as a parameter means there's a nice way to actually use these things without always having to rewrite/modify someone else's code -- all Zig code I've seen passes the Allocator as an argument. This also means you have some idea of when allocations occur, which is another thing I often want to know (I used to work on ultra low latency systems, measuring in nanoseconds -- no allocations allowed in the hot path).
Post reply on HN