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

331–340 of 429 posts

Re: Zig, the Small Language

#331

Post by thayne »

TakeBlaster16 wrote: post #4

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

My typical approach to warnings and lints is to treat them as fatal, and if there is a good reason to ignore it, specifically silence it for that specific instance, with a comment on why it is ok.

It really irks me when there isn't a way to have granular control over silencing warnings.

Re: Zig, the Small Language

#332

Post by LAC-Tech »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

It's safer than C and easier to use than rust.

Re: Zig, the Small Language

#333

Post by dcsommer »

azakai wrote: post #249
pcwalton wrote: post #222

Earlier quoted context omitted.

I didn't say that multi-element pointers were a bad feature, simply that they're a counterexample to the claim that Zig has spatial memory safety. Generally in memory-safe languages the corresponding features are behind some kind of "unsafe" marker: in Rust and C# they're behind "unsafe", in Java they're behind "sun.misc.Unsafe", etc. I don't see any such marker in Zig.

Is the marker the critical thing here, though? I just wrote in another comment that I think the Zig compiler can warn about using an unsafe pointer. The critical thing, I believe, is that unsafe can be discovered and audited. Unsafe pointers have a different type in Zig, so they are separable from the rest of the language, unless I'm missing something. The bottom line is that in a memory-safe language it should be po…

I would want to see an example of such a tool before comparing the two approaches or giving credit to Zig. As you admit in the other comment, even if such an "after the fact" tool can exist, still the net safety will be less. A compiler that does not force the developer to consciously think about safety at the time of using the unsafe feature increases the probability of misuse and safety defects.

Re: Zig, the Small Language

#334

Post by mhh__ »

WalterBright wrote: post #37
TakeBlaster16 wrote: post #4

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it…

Nearly everyone I speak to hates the unreachable error messages, by the way.

It's not useless to have them but they can be utterly infuriating for exactly the reason you mention since most projects have warnings-are-errors turned on.

The way I shut it up in a class is usually by branching on the this pointer. Sneaky.

Re: Zig, the Small Language

#335

Post by adamdusty »

boywitharupee wrote: post #108
kuon wrote: post #40

I love zig but I have two pain points. Function naming convention as camelCase. I can overlook that and use snake_case in my code, which I do and people frown upon me. Second is inability to turn unused var check off.

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.

Re: Zig, the Small Language

#336

Post by mayormcheeseman »

masklinn wrote: post #217
mirekrusin wrote: post #138

Earlier quoted context omitted.

So you don't publish it. I guess they could have levels and allow them in debug mode or with special flag or something?

> So you don't publish it. Why do they care? > I guess they could have levels and allow them in debug mode or with special flag or something? Well yes, that's how normal compilers do things.

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.

Re: Zig, the Small Language

#337

Post by ctas »

Jarred wrote: post #142

If you want to build stuff using Zig full-time, Oven ( https://oven.sh ) is hiring Zig engineers. Email jarred@oven.sh to apply

Also, if you're a company looking to hire Zig devs check out zigjobs.org. (Disclaimer: I made it.)

Re: Zig, the Small Language

#338

Post by bb88 »

tialaramex wrote: post #317
brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

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 sort of magical black box, and ergo don't understand digital logic.

Datapoint: There are now thousands of programming languages. There are primarily two digital logic languages: VHDL and Verilog.

If you ever cross over to the EE side, you'll understand how terrible some of the software is.

> 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

Again, I don't know. So much of Computer Science programs hinge on getting that first educational experience right. Not so much a problem for MIT, but the program I'm aware of that used Scheme for there CS100 course shrank over time. People just dropped and changed their degrees, when in reality if Scheme/ML were a junior level course, they probably would have more students, higher budget, etc -- and possibly most students would have an easier time after learning a little bit of imperative programming.

Perhaps it's a fair point that CS100 should be a weed-out course. But on the other hand, we don't teach the theory of calculus before we teach students trigonometry.

Re: Zig, the Small Language

#339

Post by masklinn »

mayormcheeseman wrote: post #336
masklinn wrote: post #217

Earlier quoted context omitted.

> So you don't publish it. Why do they care? > I guess they could have levels and allow them in debug mode or with special flag or something? Well yes, that's how normal compilers do things.

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 unchecked errors?

Re: Zig, the Small Language

#340

Post by davidatbu »

ArrayBoundCheck wrote: post #270
cercatrova wrote: post #83

Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.

Despite what students who never programmed professionally say, memory isn't a problem to a significant amount of C and C++ developers. I think it's been a year since I last access an invalid pointer and that only happened because I forgot that I am not suppose to add elements to array in a `for (auto var : array)` loop. It use to be a for index loop and it didn't take long to figure out the change broke something

I'm one of those who "has never programmed [C/C++] professionally".

Isn't your statement at odds with assessment from many big tech companies that memory safety is the prevailing reason for CVEs? I'm sure you're not suggesting that the folks who make these assessments are not experienced C/C++ programmers, so I'm curious about your thinking on this.

Post reply on HN