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

Why is Zig so cool?

nilostolte.github.io

Post reply on HN
Print view View original

171–180 of 527 posts

Re: Why is Zig so cool?

#171

Post by jamiejquinn »

The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare).

While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refining them, and removing unnecessary ones seems in sharp contrast to the development of any other langauge I'm aware of. I'm no language historian though, happy to be challenged.

Re: Why is Zig so cool?

#172

Post by evgpbfhnr »

porridgeraisin wrote: post #109
evgpbfhnr wrote: post #52

To author -- code sample as images is great for syntax highlight but I wanted to play with the examples and.. got stuck trying to copy the content. (also expected tesseract to do a bit better than this: $ wl-paste -t image/png | tesseract -l eng - - Estimating resolution as 199 const std = @import("std"); const expect = std.testing.expect; const Point = struct {x: i32, y: i32}; test "anonymous struct literal" { const…

tesseract does well for me... const std = @import("std"); const expect = std.testing.expect; const Point = struct {x: i32, y: i32}; test "anonymous struct literal" { const pt: Point = .{ .x = 13, .y = 67, }; try expect(pt.x == 13); try expect(pt.y == 67); The trick is to preprocess the image a little bit like so: ocr () { magick - -monochrome -negate - | tesseract stdin stdout 2> /dev/null }

Thank you!

Unfortunately I get the same kind of garbage around closing curly braces / closing parenthesis / dots with this magick filter... It seems to do slightly better with an extra `-resize 400%`, but still very far from as good as what you're getting (to be fair the monochrome filter is not pretty (bleeding) when inspecting the result).

I wonder what's different? ( ImageMagick-7.1.1.47-1.fc42.x86_64 and tesseract-5.5.0-5.fc42.x86_64 here, no config, langpack(s) also from the distro)

Re: Why is Zig so cool?

#173

Post by reorder9695 »

hamasho wrote: post #163

> Zig for ( 0..9 ) |i| { } > C for (i = 0; i I know an open interval [0..9) makes sense in many cases, but it's counterintuitive and I often forget whether it includes the last value or not. It's the same for python's range(0, 9).

Rust's solution to this is quite good, that's 0..9 and if you want to include 9 it's 0..=9, it looks a bit funny but knowing one with an = sign in it exists removes any doubt

Re: Why is Zig so cool?

#174

Post by jamiejquinn »

throwaway2037 wrote: post #170
jamiejquinn wrote: post #167

Earlier quoted context omitted.

Wow, Raku looks like a really interesting language, I'd never heard of it before! Have you used it in any large projects?

Had you heard of Perl 6?

Perl I used in 2008 or so but not since. Haven't come across Perl 6.

Re: Why is Zig so cool?

#175

Post by astrobe_ »

mk89 wrote: post #153

Some days ago I decided to look at Zig a bit more in detail. So I skipped the usual marketing and I checked why it could be an alternative to C or Rust. Could it be? It seems that (debug) allocators are a nice idea, however, it seems that they exist "somehow" already for C, so I wonder: why would you pick this language for your next low level program? They provide runtime checks, so you need thorough testing before y…

> So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators

A partial answer is that part of low-level programmers avoid memory allocation and threads like plague. In some cases they are not even an option (small embedded programming, it's nearly as low-level as you can get before going hardcore for real with assembly programming), but when they can the keywords are efficiency, reliability, predictability, and simplicity : statically allocating in advance is a thing you can do because the product is typically with max specs written on the box (e.g. max number of entries in a phone book, to take a generic dumb example), and you have to meet these requirements even if the customer uses all of the capabilities to the max; no memory overbooking allowed, which is basically what dynamic allocation is, in a sense.

> instead of starting a new programming language

If I were to start a new low-low level programming language, I would basically just fix C's weak typing problem, fix the UB problems that only come from issues with long-gone processors (like C++11 finally did with sign encoding), "backport" some C++ features (templates? constexpr?), add a pinch of syntactic sugar and fix union types to have proper sum types. But probably I've just described D and apparently a significant chunk of C23.

Re: Why is Zig so cool?

#176

Post by throwaway2037 »

cornstalks wrote: post #86
qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

People are working on this. std.zon is generally considered to be a good example of how to handle errors and diagnostics, though it's an area of active exploration. The plan is to eventually collect all the good patterns people have come up with and (1) publish them in a collection, and (2) update std to actually use them.

    > how to handle errors and diagnostics, though it's an area of active exploration
I am flabbergasted and exasperated by this sentiment. Zig is over 9 years old at this point. This feels this same kind of circular arguments from Golang "defenders" about generics and error handling.

Re: Why is Zig so cool?

#177

Post by DeathArrow »

>totally new way to write programs

To me it seems like a better C but not at all unique since most concepts in Zig are already present in other languages.

Zig is cool but not unique. And that is cool, too. Originality for the sake of originality doesn't add value in programming.

Re: Why is Zig so cool?

#178

Post by jibal »

mrgaro wrote: post #145
jibal wrote: post #122

Earlier quoted context omitted.

If you install Zig, you can now generate executables for virtually any target with just a CLI argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires compiling the compiler to target a different architecture.

Doesn't Golang support this as well, out of the box?

Apparently; I wasn't aware. But unlike Zig this doesn't work with FFI ... everything has to be Go code ... cross compilation works by compiling the library code for the target and caching it ... but if you need anything outside of that you're out of luck ... or maybe not ... I ran across this tidbit:

"When a Go project utilizes CGo to interact with C code, standard Go cross-compilation might require additional steps. This is because Go can cross-compile Go code but not C code directly, necessitating the availability of target system libraries on the development machine. Tools like Zig can be used as a C compiler (zcc) to facilitate cross-compilation for CGo-dependent projects by providing the necessary cross-compilation capabilities for the C code."

Re: Why is Zig so cool?

#179

Post by adrian_b »

hamasho wrote: post #163

> Zig for ( 0..9 ) |i| { } > C for (i = 0; i I know an open interval [0..9) makes sense in many cases, but it's counterintuitive and I often forget whether it includes the last value or not. It's the same for python's range(0, 9).

The better solution to forgetting whether an interval is closed or half-open is to always use only half-open intervals, without any exceptions.

In most cases half-open intervals result in the simplest program, so I agree with the choice of Zig, which is inherited from other languages well-designed from this point of view, e.g. Icon.

I find half-open intervals more intuitive than either closed intervals or open intervals, and much less prone to errors, for various reasons, e.g. the size of a half-open interval is equal to the difference between its limits, unlike for closed intervals or open intervals. Also when accessing the points in the interval backwards or circularly, there are simplifications in comparison with closed intervals.

Re: Why is Zig so cool?

#180

Post by jibal »

jibal wrote: post #115
krosaen wrote: post #92

I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).

Adopted from go, first appeared in D, invented by one of its major developers, Andrei Alexandrescu.

P.S. In D it's `scope(exit)` = defer, `scope(failure)` = Zig's errdefer, and `scope(success)` -- which no one else has and which I have made good use of. e.g., I have a mixin that traces entry and exit from a function, the latter with scope(success). If I use scope(exit) instead then when an exception is thrown all the leave messages are printed and then the stack trace, rather than seeing the stack trace at the point of failure (this baffled me when it first happened).
Post reply on HN