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

141–150 of 429 posts

Re: Zig, the Small Language

#141

Post by pjmlp »

naikrovek wrote: post #57
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.

simpler languages are easier to learn and to remember. small languages make software easier to write and to read. complex features (in a language that does the simple things correctly) are always easily composed from the simple features available. the antithesis of small languages is C++, which is probably the most popular language on the planet in which 0% of its users know 100% of. with a small language, i can’t us…

Same applies to Java 19, C# 11, Python 3.10,...

I can do puzzles in any of them, which many will fail to guess, specially if runtimes and standard libraries are part of the question pool.

Re: Zig, the Small Language

#143

Post by skocznymroczny »

naikrovek wrote: post #35
Kukumber wrote: post #17

Earlier quoted context omitted.

if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity

> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.

It makes a massive difference. I find most math related code unreadable without operator overloading, such code is very common in e.g. gamedev.

Just because people misuse operator overloading doesn't mean it should be removed from the language.

Re: Zig, the Small Language

#144

Post by rtev »

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?

Re: Zig, the Small Language

#145

Post by swsieber »

cle wrote: post #136
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.

> 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 completely disagree, I regularly catch mistakes/bugs in my own code due to enforced linting errors (both locally and in CI), and just in the past few months I can recall numerous instances where CI linting caught bugs in teammates' code too. There are both false positives and false negatives with linti…

And there are good and bad lints. If you want a somewhat view on what lints are good and bad go find some issues for Rust that discuss how to categorize a particular lint.

Re: Zig, the Small Language

#146

Post by cycomanic »

stephc_int13 wrote: post #79
Kukumber wrote: post #50

Earlier quoted context omitted.

> I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable

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

I somewhat agree with you, I argue that mat*mat should be an element wise operation and use a different operator for matrix operations (like numpy does it).

Re: Zig, the Small Language

#147

Post by skocznymroczny »

I like the idea of Zig, but haven't got to actually use it yet. I still can't get over it's syntax. I think the manual memory management approach but easier than C is a good path to follow. It makes Zig a natural in other environments such as WASM. Compare that to Go or D which started with a garbage collector and struggle in WASM (Go has to compile it's garbage collector to WASM to work, D forces you to manage your memory manually).

Re: Zig, the Small Language

#148

Post by nkozyra »

TakeBlaster16 wrote: post #65
masklinn wrote: post #22

Earlier quoted context omitted.

> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, b…

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.

Re: Zig, the Small Language

#149

Post by azakai »

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/

"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 example, by not reusing memory addresses. That adds overhead, which might rule Zig out in certain areas, but not others.

Also, while in many domains safety should be the #1 factor when when choosing a language (like building a web browser), that's not universally true. Other factors exist.

Re: Zig, the Small Language

#150

Post by acuozzo »

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/

I clicked the link and I see within the table mentions of "heap" and "free", but I regularly target systems with no runtime.

Does Rust offer many advantages over Zig in this space?

I mostly program in C, but I've been eyeballing both for some time now.

Post reply on HN