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

301–310 of 429 posts

Re: Zig, the Small Language

#301

Post by ModernMech »

ptato wrote: post #176
littlestymaar wrote: post #156

Earlier quoted context omitted.

> Not fighting the borrow checker This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules. > or making gratuitous copies of data to satisfy the borrow checker. You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the bor…

That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.

I'd say that after using Rust for a year I also fought the borrow checker, but after using Rust for 6 years I definitely don't anymore. A lot of the difference between a year and 6 was unlearning C++ habits.

Re: Zig, the Small Language

#302

Post by stephc_int13 »

k__ wrote: post #261
ferdowsi wrote: post #157

Earlier quoted context omitted.

I would choose Zig because Zig has a much more approachable learning curve and Zig code is eminently legible compared to Rust code and it's overly complex type system.

Why not Go or Nim?

Because Garbage Collection is basically a garbage feature that should be, at the very least, optional.

Re: Zig, the Small Language

#303

Post by KerrAvon »

rahen wrote: post #210
RussianCow wrote: post #166

Earlier quoted context omitted.

They both emphasize productivity over other factors like performance and correctness, so I think they're very much in the same boat in terms of use cases.

Go was created for correctness. It is strongly, statically typed, it won't compile if there are unused imports or variables, and it won't compile either if you don't free up resources after usage. C/C++ don't do that and have UBs. Go is in the same ballpark than C#: a modernized C with GC, good productivity although not as good as a scripting language, and good performance although not as good as ANSI C. They're popu…

Correctness may have been a goal of the Go language authors but they don't seem to have achieved it.

I could find countless other comments about this on HN, but here's the top hit in a quick search. https://news.ycombinator.com/item?id=26632821

Re: Zig, the Small Language

#304

Post by azakai »

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+…

Yes, technically there might exist a subset of C++ as safe as idiomatic Zig. But in practice inertia and legacy code and lack of ergonomics etc. work against that subset of C++ becoming popular - does anyone constantly type .at()? Zig can do better, if it doesn't squander the opportunity.

In other words, this isn't about theoretical subsets of a language. It's that there is an opportunity when designing a new language to use better defaults and have better idiomatic patterns. If Zig and Carbon do it properly, I think they can get to a place where they have practically no spatial memory errors in the real world. That is measurable, in principle, so we'll see how it plays out I suppose.

Re: Zig, the Small Language

#305

Post by hsn915 »

stephc_int13 wrote: post #300
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/

As far as I am concerned, the alleged "memory safety" benefits of Rust do not have much more value or weight than wishful thinking, this kind of claim can only gain strength by standing the test of time. Computer security is a real problem that must be fully addressed at every step of the design of a system, language and tooling can help, a bit, not much. Rust is not a "safe" language. It might be -safer- than C/C++,…

Here's a hypothesis I'd like to see Rust advocate attack:

In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".

Re: Zig, the Small Language

#306

Post by hsn915 »

Cyberdog wrote: post #211
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…?

http://paulgraham.com/pypar.html

Although the "Python Paradox" does not apply to Python anymore (it has become even more mainstream than Java), it does highlight an important point:

If you choose your language based on "I want the biggest pool of developers" you are also saying "I want the most average and mediocre developers that I can pay for cheap".

Re: Zig, the Small Language

#307

Post by [deleted] »

xedrac wrote: post #188
rtev wrote: post #144

Earlier quoted context omitted.

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?

I could see Zig thriving in a kernel, with its seamless integration with C. It would be a relatively simple upgrade to make. I still think Rust is the better choice though. Maybe the answer to your question is, if you're strictly a C developer and you want something a little nicer without too much more, then Zig might be the best choice for you.

[deleted]

Re: Zig, the Small Language

#308

Post by strager »

LAC-Tech wrote: post #289
sph wrote: post #139

Earlier quoted context omitted.

IIRC there's already a Zig fork that turns that abomination off. I remember seeing it mentioned in that upstream issue OP mentioned.

Do you remember the name or have a link?

Maybe this: https://github.com/ziglang/zig/issues/335#issuecomment-10138...

Re: Zig, the Small Language

#309

Post by [deleted] »

wyldfire wrote: post #14
Kukumber wrote: post #7

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.

[deleted]

Re: Zig, the Small Language

#310

Post by coderenegade »

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.

Code is read more than it's written, so clarity is important. The fewer ways there are to do things, the closer everyone is to a common understanding of a given block of code, which makes understanding another programmer's intent easier. In turn, this makes onboarding to a project much more effective, and lets devs reach a minimum level of competency more quickly.

Note that small doesn't imply lacking features. For example, something like a std::transform is often "smaller" than iterating through an array with a for-loop, but it's also clearer and less error prone. It's a result of the language itself providing more powerful data structures, and interfaces that make manipulation of those structures easier, which is what I'd argue "small" is actually shorthand for. I don't want to be using a language that only has if-statements and goto, which would be "small" in one sense of the word; I want to use a language that has the minimum necessary number of keywords, decorators, or meta-languages, and instead provides clear, ergonomic ways to express my intent to the machine.

Post reply on HN