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

211–220 of 429 posts

Re: Zig, the Small Language

#211

Post by Cyberdog »

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

Would love to hear your experiences hiring devs and building projects in a new, scarcely-used language and ecosystem like this. I imagine you don't quite get the range of applicants you'd see hiring devs for Rust or Go or other trendy languages du jour, but maybe that's actually a good thing since it weeds out less experienced devs and résumé liars who probably don't even know Zig exists…?

Re: Zig, the Small Language

#212

Post by cztomsik »

rtev wrote: post #144
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 does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

for me,

- easy interfacing to C libs (glfw)

- very easy and readable metaprogramming (compile time inline for over all enum variants, duck-typed and strong-typed anytype at the same time, @compileError for advanced compile checks so you can teach compiler new rules about your code instead of trying to fit your code in the extisting compiler rules)

Re: Zig, the Small Language

#213

Post by kristoff_it »

pcwalton wrote: post #174
azakai wrote: post #149

Earlier quoted context omitted.

"Not much safer" isn't fair. Zig has full spatial memory safety, which is already a huge improvement over C. The Zig type system and how idiomatic code looks also prevent various safety risks. Also, Zig panics on integer overflow, avoiding various other dangers. Zig does lack a general solution for temporal memory safety. That is a downside. But it can still have that safety in ReleaseSafe mode, at least - for exampl…

> Zig has full spatial memory safety, which is already a huge improvement over C. I don't believe this is true. Zig has pointers to unknown numbers of items, which don't seem bounds checked: https://ziglang.org/documentation/master/#Pointers They prefer slices idiomatically, but that's not "full spatial memory safety". C also prefers you to pass the length of every array whenever you pass a pointer to it, in that cor…

> You might be able to say something like "Zig minus features X, Y, and Z has full spatial memory safety". I'd be interested to see what features those are: it looks like at a minimum you would have to get rid of multi-element pointers and extern unions.

Well, `[*]` pointers and extern unions exist for C interoperability. I'm sure that Rust has to do something comparable when interfacing with C.

These pointers actually do help making C interop more safe. In C there is no distinction at the type level between a pointer to a single element and a pointer to the first element of an array, so if you at some point get it wrong, the compiler can't help you.

In Zig, if you annotate `extern` function signatures correctly, the compiler will be able to tell you when you're wrongly trying to iterate over a single-element pointer (or viceversa).

That's a good feature to have, and IMO probably the worst supporting argument for your usual complaint about Zig's existence.

Re: Zig, the Small Language

#214

Post by masklinn »

nkozyra wrote: post #148
TakeBlaster16 wrote: post #65

Earlier quoted context omitted.

Zig seems to behave similarly. This compiles: export fn x() i32 { var a: i32 = 1; // okay a = 2; return a; } This does not: export fn x() i32 { var a: i32 = 1; // unused variable var a2: i32 = 2; return a2; } > Not that this lint actually achieves that, or even prevents real errors. I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

I don't think that's quite the same issue. That `a` is reassigned doesn't make it unused. It is, after all, a variable. And that's why this issue is kind of hard. It's why I end up block scoping a lot of error code in Go, which is ugly but generally safer.

> I don't think that's quite the same issue.

It is.

> That `a` is reassigned doesn't make it unused. It is, after all, a variable.

But that's exactly why it's bad, "unused variable" is not a super useful signal in the first place, and if you assert that everything must be used then you need to protect against "unused stores" instead.

SSA tells us there is essentially no difference between assigning and reassigning.

Re: Zig, the Small Language

#215

Post by edflsafoiewq »

avgcorrection wrote: post #205
lopatin wrote: post #195

Earlier quoted context omitted.

A dogmatic one, by the sounds of it.

Maybe this becomes the equivalent of `go fmt` in 10 years. “How I learned to stop worrying and love errors-only”

We've had -Werror forever, the consensus is it's a bad idea. In addition to everything else, you can't ever change the warnings, including fixing bugs in them, without potentially breaking code.

Re: Zig, the Small Language

#216

Post by flumpcakes »

avgcorrection wrote: post #199

I’m in favor of big general purpose languages. Why? Not for their own sake. Just because it’s tedious to use multiple languages. - How do they communicate? Maybe Json if it’s just data. For more control you need FFI - And FFI is such a hassle that some languages seem to focus mostly on getting a nice C FFI - ... That lingua franca that proves that you can have all the simple languages that you want as long as its nam…

Zig can directly compile C and C++ code. It's probably one of the easiest languages for C/C++ interop.

Re: Zig, the Small Language

#217

Post by masklinn »

mirekrusin wrote: post #138
masklinn wrote: post #88

Earlier quoted context omitted.

> This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. Don’t get me wrong I like a good unused code warning . What frustrates me is that Go’s is dumb / unreliable, and it will stop you from working entirely until you’ve complied with this whim, which has a fraction of a percent chance of identifying a real bug. > Basically writing go without `staticcheck`…

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.

Re: Zig, the Small Language

#218

Post by flumpcakes »

amelius wrote: post #94
10000truths wrote: post #46

Earlier quoted context omitted.

It's usually not the disk space that's the bottleneck, but rather, the CPU instruction cache. On modern Intel and AMD CPUs, the jump from L1 -> L2 alone can triple the latency of a memory fetch. For a "hello world" application, that doesn't really mater, but for, say, an OS kernel, it becomes really important to keep as much of your hot-path code in i-cache as possible.

It requires a special kind of programming. Maybe they should just release the benchmarks instead of saying "small". By the way, I wouldn't be surprised if Rust 2.0 will feature a typechecker that guarantees that everything fits in the L1 cache.

I really am stretching to find a link between a typechecker and L1 cache. Perhaps some kind of dynamic analysis of code and averaged data could give you a non-empiric measurement of L1 cache utilisation but considering cache behaviour it's not standardised even within one vendor it would be a ball-park guess at best.

Re: Zig, the Small Language

#219

Post by masklinn »

flumpcakes wrote: post #189
masklinn wrote: post #10

Earlier quoted context omitted.

Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.

It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all a…

> It is not useless though.

True, it's actively harmful.

> There is a big difference between an unused variable and explicitly defining an unused variable.

Which is not helpful when you're only doing it to hide a compiler error foisted upon you.

> Kelly is designing Zig to do nothing surprising or change things underneath you.

Refusing to compile my code because I've an unused variable is certainly surprising.

> If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable.

That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising.

> I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).

1. that it's an error is the entire problem here

2. and as far as I'm concerned it's a ridiculously weak warning, if your standard is that no action should be useless you need an unused store error, which subsume unused variables

Re: Zig, the Small Language

#220

Post by avgcorrection »

IIAOPSW wrote: post #127
jayd16 wrote: post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

I must confess I had to suppress my knee jerk urge to downvote. It almost feels like you're asking "what's the appeal of elegance?" "What's the appeal of Chess, if you want complex gameplay just have complex rules." It almost feels alien that someone couldn't get it. Here's a simple but perhaps disappointing theory. Painting with a broad brush for a moment, there are primarily two sorts of thinkers: memorizers and lo…

What a lame Mars/Venus theory. Language designers never make complex features in order to have more to learn and catalogue. They are nakedly compromises which are supposed to make certain things easier, maybe even simpler in certain senses (for example simpler library code: more complex features like pattern matching can make for less spaghetti control flow).

Then the retort might be “but they wittingly or unwittingly pursue the goal of complexity for its own sake!”, in which case that would just prove that you have stacked the deck in favor of the “logician” (who makes simple languages for simplicity’s sake—simple).

Another problem is that some language designers are logicians by trade already.

> So, for the logician type thinker, small languages are just deeply pleasing for the same reason Newtons laws and Chess are deeply pleasing.

Chess has Opening Theory. I bet the Half-Delayed Swashbuckler Sicilian just comes naturally to the oh-so exalted logician.

(Then the retort might be, oh I’m just talking about the game in the abstract, not the metagame. Well it is very important how a game is actually played and how a language is actually put to use.)

Post reply on HN