Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

251–260 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#251

Post by ncmncm »

k__ wrote: post #158
dagmx wrote: post #146

Earlier quoted context omitted.

I've only ever really seen it in Zig communities that Rust is closer to C++ In Rust communities, it's often pitched as alternates to both, but closer to C. I suppose it's all relative, but the comparison of rust to c++ seems external

Yes, I also had the impression Rust is a C replacement.

Rust's purpose, its whole reason to exist, is to displace C. Rust will unavoidably fail in that, because anybody still using C is not willing to learn anything else: anybody willing to move on from C already did, long ago.

Rust is already approaching C++ in complexity, surpassing it in some places; and also in expressive power, but not surpassing it anywhere yet.

If Rust does not end up fizzling (which is still very possible!), Rust programmers will generally be drawn from the same population as C++ programmers. They will be people who want and can use a powerful language to make themselves more productive and able to manage bigger projects, without need to worry that they are taking a performance penalty, or losing control of details that matter.

Users of Zig, like of Nim and C, will be those uncomfortable with language power, disinclined to automate. Their attention is not on software and what they can build of it, but on problems where a thin veneer of software can add something useful. When there is not much for the software to do, you don't need much power to get it doing that.

Re: Failing to Learn Zig via Advent of Code

#252

Post by ncmncm »

eximius wrote: post #211
k__ wrote: post #158

Earlier quoted context omitted.

Yes, I also had the impression Rust is a C replacement.

From a programming language design space, it's much more like C++. However it can occupy some niches that C can but C++ does poorly because of zero cost abstractions, I think. (Very handwavy)

There are no niches where Rust can do better than C++. In many places Rust can, uniquely, match C++.

Re: Failing to Learn Zig via Advent of Code

#253

Post by _vvhw »

octoberfranklin wrote: post #244
socialdemocrat wrote: post #109

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…

I still can't figure out how Zig proposes to prevent undefined behavior without a borrow checker (aka MLKit regions) or GC. AFAICT the answer is "inject as many runtime checks as needed" although the docs seem to go way out of their way to avoid making this explicit.... or deal with the fact that these checks are now runtime failures rather than compile-time failures, and therefore need code to handle them. It seems…

You're conflating undefined behavior with spatial/temporal memory safety, the latter of which is what is 100% prevented by Rust's borrow checker, provided you're not interfacing with hardware, in which case I believe that things change more in binary fashion.

However, Zig treats memory safety not as an extreme-at-all-costs but as a spectrum (there are reasons for wanting to think like this, at least when writing low-level code if you want to make more use of the hardware), getting 100% on the spatial memory safety front and reaching to 50-75% on the temporal memory safety front through the GPA. That's already an order of magnitude more safety than C, at which point memory exploits have dropped in ranking, and you should be more concerned about things like explicit control flow, error handling and checked arithmetic, not to mention the orthogonality of the language.

Furthermore, in the systems world, there are many safety critical systems where dynamic allocation and multi-threaded control planes are simply off the table to begin with because they're dangerous in some domains and not as safe as static allocation and single-threaded control planes, which are less dimensional and easier to reason about. And in those cases, UAFs and multi-threaded races are less of a concern (still a concern, but less).

Also, Rust won't protect you from all undefined behavior, and Zig often helps more than you think. For example, you might be surprised to hear that Rust has checked arithmetic off by default in safe builds, whereas Zig has this enabled. I've done a little security work on some large systems and the decision to disable checked arithmetic always blows my mind. Integer overflow and underflow are right up there as threat vectors when writing anything that's touching hostile data.

I'm waiting for the day when Rust changes direction on this, and I think there's a chance this will happen because the alternative status quo of not checking arithmetic (at all) is just not tenable, at least not if we care about safety and security holistically, and not only memory safety.

Re: Failing to Learn Zig via Advent of Code

#254

Post by ncmncm »

_vvhw wrote: post #249
ncmncm wrote: post #248

When I saw > I try to keep my C++ simple and somewhat C-like. ... I knew this would not be very informative. On one hand, the author's failure to take advantage of the power C++ offers means he will likely also fail to see how to use well what Zig does offer. (One doubts he makes any more effective use of Rust, another powerful language, than of C++.) At the same time, it should make him a better prospect to become a…

> But he is right that "no hidden control flow" is an anti-feature. Hmmm, "no hidden control flow" is at least what I want writing distributed systems, storage engines or device drivers. Calling it an "anti-feature" is dismissing important domains for system languages where control flow in the control plane needs to be explicitly visible, and where the necessity for things like static allocation and NASA's "The Power…

Destructors are a powerful tool to ensure that required events occur, an important part of safety-critical coding.

Static allocation is a valuable method that is wholly compatible with use of destructors. If you imagine that freeing dynamically-allocated memory is the main use for destructors, you have utterly failed to understand them.

Re: Failing to Learn Zig via Advent of Code

#255

Post by jibalt »

There's a Hello World program at the beginning of the Zig Reference Manual. It of course shows how to print things. Many other of these failures could be avoided by reading that document, reading Zig source code in the distribution, looking at issues on Github, reading blogs and watching presentations by Andrew Kelley, etc.

Zig is far from a finished project so it's premature to complain about most of the things you are complaining about.

Re: Failing to Learn Zig via Advent of Code

#256

Post by jibalt »

dundarious wrote: post #222
yjftsjthsd-h wrote: post #181

Earlier quoted context omitted.

> Zig is basically C with a fancy type system, so you should not expect things like special String types, If I can't have nice strings, what should I be expecting from a fancy type system?

Zig's "fancy" (I don't think they're that fancy) type features that IMO make it a great C alternative are: - non-null pointers, and distinct types for single-item pointers and multi-item pointers (multi-item pointers are rarely used except indirectly via slices, so unchecked pointer arithmetic errors are largely banished) - builtin tagged unions (AKA algebraic data types) with very pleasant to use switch logic -- it…

Many of Zig's fancy type features are in the library, not in the language, because types can be programmatically constructed at compile time.

Re: Failing to Learn Zig via Advent of Code

#257

Post by jolux »

Comevius wrote: post #228
jolux wrote: post #204

Earlier quoted context omitted.

> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we wan…

Here is an example with a keyboard firmware why you might not always want all that complexity. https://kevinlynagh.com/rust-zig/ https://zig.news/aransentin/analysis-of-the-overhead-of-a-mi... The point of languages like C and Zig is that they are only a bit higher level than assembly for portability, but otherwise they don't hinder you to do whatever. It's up to you to solve problems like memory safety. You might no…

I read the thread about the keyboard at the time. The author literally said it was a hobby project and they weren't concerned about safety, which is why they weren't interested in all of the solutions people offered for their problems with Rust. Zig's fine if you don't care about safety. But that's not really how I've heard it advertised.

> but otherwise they don't hinder you to do whatever

Neither does Rust! You can choose to ignore what the compiler wants you to do and just program with unsafe everywhere. The difference is that you don't have the option of writing safe code in Zig and C.

> It's up to you to solve problems like memory safety.

And so far, memory safety is not actually a problem that programmers have been able to solve by sheer force of will without borrow checkers or garbage collection. For a subset of trivial programs, sure. But not at any reasonable scale.

Re: Failing to Learn Zig via Advent of Code

#258

Post by octoberfranklin »

ralphb wrote: post #77
megumax wrote: post #70

My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Zig still can't proper handle UTF-8 strings [1] in 2022, which is kind of unfortunate, because it's a `requirement`. In a `recent` interview[2], he claims that Zig is faster than C and Rust, but he refers to extremely short benchmarking that has almost no value in the real world. At least Rust, as blamed and…

Rust was started in 2006. [1] Zig was started in 2015. [2] [1] https://en.wikipedia.org/wiki/Rust_(programming_language) [2] https://en.wikipedia.org/wiki/Zig_(programming_language)

The language called "Rust" prior to 2013 is a completely different language from what people today know as "Rust". That language had a garbage collector, mutable aliasing, and no borrow checker (the three most unique features of today's Rust), and was basically "golang with different syntax":

http://smallcultfollowing.com/babysteps/blog/2012/11/18/imag...

The whole language got rebooted shortly after the blog post above, mostly because the borrow checker made so many other things suddenly unnecessary or trivial. What we call Rust today is at most 9 years old, and any similarities to pre-2013 Rust are strictly superficial syntax. They share a name and some syntax, sort of like Java and Javascript do.

Zig today at T+7 is not where Rust was in 2020 at T+7.

Re: Failing to Learn Zig via Advent of Code

#259

Post by jibalt »

octoberfranklin wrote: post #244
socialdemocrat wrote: post #109

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…

I still can't figure out how Zig proposes to prevent undefined behavior without a borrow checker (aka MLKit regions) or GC. AFAICT the answer is "inject as many runtime checks as needed" although the docs seem to go way out of their way to avoid making this explicit.... or deal with the fact that these checks are now runtime failures rather than compile-time failures, and therefore need code to handle them. It seems…

Zig doesn't propose to prevent UB (in fact the docs say that it takes aggressive advantage of it for optimization).

(Neither does Rust.)

Re: Failing to Learn Zig via Advent of Code

#260

Post by dnautics »

AndyKelley wrote: post #144
dnautics wrote: post #98

Earlier quoted context omitted.

> The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`. I don't know if ZSF can guide this or if we can incept it into Andy's head, but if there were any coordinate…

Unfortunately I want to destroy it with fire. I am not happy with formatted printing at the moment. But that's something that will ruin a lot of people's day so it will have to be done carefully. To be less dramatic: I do intend to wildly break formatted printing at some point. Point taken though. Perhaps it deserves its own seat in the roadmap.

Haha no problem! I both love the formatted printing and hate it, but it's the details of how it works that I hate, it's the power that it has that I love (hence 'beautiful bastard'). I'm sure there is "a better way", so killing it with fire, unless you totally screw it up, gets my support, for whatever that's worth. Anyways, Just whatever it winds up being, it should be well documented, and well documented early.
Post reply on HN