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

191–200 of 429 posts

Re: Zig, the Small Language

#191

Post by sound1 »

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…

> Small coding languages let you know everything while learning as little as possible.

Very well put

Re: Zig, the Small Language

#192

Post by Symmetry »

WalterBright wrote: post #53
naikrovek wrote: post #35

Earlier quoted context omitted.

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

Here's a sweet example of proper use of operator overloading: https://dlang.org/phobos/std_checkedint.html where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens. Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));

I think haskell does this right. You can make function infix by turning "add a b" into "a `add` b" and you can't overload existing operators but you can make your own and do "a _+ b" or whatever and everybody will know it isn't the standard + but it's still readable.

Re: Zig, the Small Language

#193

Post by md224 »

ok_dad wrote: post #164
sph wrote: post #137

Earlier quoted context omitted.

You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a ma…

So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...

What if the person you're replying to really, really likes Zig except for this one aspect of it?

Re: Zig, the Small Language

#194

Post by verdagon »

pcwalton wrote: post #151
verdagon wrote: post #121

Earlier quoted context omitted.

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…

> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.

That was a typo, supposed to say "memory unsafety". Thanks for catching that, edited now.

Re: Zig, the Small Language

#195

Post by lopatin »

kristoff_it wrote: post #169
sph wrote: post #137

Earlier quoted context omitted.

You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a ma…

> And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a massive undertaking to add warnings to a compiler. What a sorry excuse. Setting aside the unused variables issue for a moment, you might want to take a moment to ponder the fact that not having warning messages is an explicit design choice, not a missing feature.

A dogmatic one, by the sounds of it.

Re: Zig, the Small Language

#196

Post by flumpcakes »

azakai wrote: post #149
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 exampl…

I scratch my head when people think Rust is the "the answer". Zig has different trade offs to Rust and in some areas is safer. It is also a much smaller language , and hopefully won't need language lawyers to debate endlessly best practices. A gentle reminder to people that even "safe" Rust code can still crash. We always need to be vigilant and take our time to actually think about what we are doing and not just on the problem we are trying to solve.

Re: Zig, the Small Language

#197

Post by jayd16 »

donio wrote: post #129
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.

To me being able to keep the entire language in my head is invaluable. When working with Go for example I know that I can dive into the bowels of some library dependency and I will be able to read it and figure out how it works. This is because the language encourages straightforward code and has very little magic. The code does what it says. We have to deal with complex libraries no matter of how big or small the la…

But it seems to me language features help the understanding. You'll need to learn whatever library or custom code was used instead of a language feature with the added headache that you need to learn it every time and you'll see many implementations.

That said, I'm used to Java or C# as far as language size goes and I don't feel suffocated by it. I'm not sure if its a natural inclination or a learned skill.

Re: Zig, the Small Language

#198

Post by cztomsik »

pcwalton wrote: post #151
verdagon wrote: post #121

Earlier quoted context omitted.

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…

> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.

for native addons for GC'd languages you probably don't want to introduce another GC, rust is not well-suited for interfacing with FFI, C++ is a bit heavyweight but okish I guess and C is totally unsafe, Zig is just right.

Re: Zig, the Small Language

#199

Post by avgcorrection »

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 name is one letter and starts with “c”

- All kinds of minute differences that are real tradeoffs when it comes to each individual language become major pains when switching between them

- Sometimes you seem to have to rule out languages just because they don’t have good libraries for X. Or can’t do concurrent tasks. How are multiple small languages supposed to flourish when 20+ year old languages can’t get good library coverage or get rid of their global interpreter lock?

I would like small languages if they all played nicely together. But they almost never do.

Re: Zig, the Small Language

#200

Post by iainmerrick »

vinay_ys wrote: post #11
dmytrish wrote: post #9

Earlier quoted context omitted.

That makes unused variables "used", which defeats the point of the check.

Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.

But then what if you accidentally check in that workaround?

The strict compiler check would have had exactly the opposite effect from the intended one.

Post reply on HN