291–300 of 527 posts
Zig has completely changed the way I program (even outside of it). A lot of the goals and heuristics I used to have while writing code have completely changed. It's like seeing programming itself in a new way.
I totally vibe with the intro but then the rest of the article goes on to be a showcase bits of zig. I feel what is missing is how each feature is so cool compared to other languages. As a language nerd zig syntax is just so cool. It doesn’t feel the need to adhere to any conventions and seems to solve the problems in the most direct and simple way. An example of this declaring a label and referring to a label. By mo…
I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt…
There's a certain beauty in only having to know 1~2 loops/iteration concepts compared to 4~5 in modern multi paradigm languages(various forms of loops, multiple shapes of LINQ, the functional stuff etc).
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, refini…
Earlier quoted context omitted.
D and Nim both offer that. D has a tool, rdmd, that compiles (with caching) and runs a script written in D, so you write #!/usr/bin/env rdmd D code ... and run it as if it were an executable.
If you want to write a code example on HN you can just indent it by 2 spaces and it'll work like you'd expect. For example: #!/usr/bin/env rdmd D code...
Earlier quoted context omitted.
Nope, that is a English grammar construct that is a shortcut for "and" and "or", as any good English grammar book will explain. Indeed you see those for Java/Scala and Objective-C/Swift in technical books and job adverts. Any search on the careers sites, or documentation, on companies that have seats at ISO, sell/develop C and C++ compilers, have such C/C++ references in a couple of places. Do you need any example?
In the general case yes, but "C/C++" became an idiom for the stance, that C and C++ are essentially the same, that C++ is a superset of C or that C++ is just the replacing successor of C and it should be treated as superseded. This is quite wrong and thus there is a lot of rightful intervention to that term. Personally I use "C, C++" when I want to talk about both without claiming, that they are the same language.
It is a bikeshedding discussion that doesn't help in anything, regarding lack of security in C, or the legions of folks that keep using C data types in C++, including bare bones null terminated strings and plain arrays instead of collection types with bounds checking enabled.
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.
A lot of comments here kind of miss the point, but that's to be expected because you can only really get it when you have the experience. Like hearing a description of a painting will not give you the same emotion as looking at it yourself. Zig has completely changed the way I program (even outside of it). A lot of the goals and heuristics I used to have while writing code have completely changed. It's like seeing pr…
They allow for super ergonomical coding of state machines, which is a lot of fun.
Earlier quoted context omitted.
Pixi, Conan, or Nix— all better choices than abusing the Python ecosystem to ship arbitrary executables.
It could easily be the case that the zig compiler is useful in some mixed-language project and this is not actually "abuse".
I know some of it has already happened with rust, but perhaps there’s a broader reckoning that needs to occur here wrt standards around how language specific build and packaging systems handle cross language projects… which could well point to phasing those in favour of nix or pixi, which are designed from the getgo to support this use case.
Earlier quoted context omitted.
I think you've skipped over all the cases where knowing the filename is actually helpful? It's true that sometimes it isn't. Also, a line number is often helpful, which is why compilers include it. Some JSON parsers omit that, which is annoying.
> Also, a line number is often helpful That's not error data, that's (one level of) a stack trace. And you can do that in zig, but not by putting call stack data into error return codes. The conflation between exception handling and error flagging (something that C++ did largely as a mistake, and that has been embraced by managed runtimes like Python or Java) is actually precisely what this feature is designed to unt…
They're not talking about the stack trace, but about the common case where the error is not helpful without additional information, for example a JSON parsing library that wants to report the position (line number) in the string where the error appears.
There's no way of doing that in Zig, the best you can do is return a "ParseError" and build you own, non-standard diagnostic facilities to report detailed information though output arguments.