[HN Gopher] Zig by Example
___________________________________________________________________
Zig by Example
Author : dariubs
Score : 216 points
Date : 2026-06-08 13:06 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| shaftoe444 wrote:
| Examples target Zig 0.14.
|
| Been some significant changes since then, not least to printing
| and formatting (see writergate).
| gren236 wrote:
| Also build system and c interop is outdated
| embedding-shape wrote:
| Ah, but are those changes in the training data yet?
| sgt wrote:
| Probably not, but if this is all AI slop then why bother to
| read it? There's real documentation (and/or just code). Use
| it
| reactordev wrote:
| there's no question of if here...
| fallingmeat wrote:
| lots of people into zig this morning apparently!
| dominotw wrote:
| I am really looking into zig now because founder seems like a
| cool dude.
| code-blooded wrote:
| I just looked this up yesterday so sharing some more up-to-date
| resources for those interested in Zig:
|
| - Learning Zig by Karl Seguin:
| https://www.openmymind.net/learning_zig/
|
| - https://zig.guide/
|
| - Free project-based online book Introduction to Zig by Pedro
| Park: https://pedropark99.github.io/zig-book.
|
| - Ziglings, almost working programs you need to fix:
| https://codeberg.org/ziglings/exercises
| iamjackg wrote:
| "More up-to-date" meaning more sources that are also up to date
| like the OP, or meaning that the OP is not up to date? Silly
| English language!
| code-blooded wrote:
| Zig by Example seems to target Zig 0.14 at the moment. The
| links I posted should hopefully target version 0.15+
| fallingmeat wrote:
| for those new, start with why:
| https://ziglang.org/learn/why_zig_rust_d_cpp
| aselimov3 wrote:
| Is this much different than ziglings?
| voidUpdate wrote:
| This is essentially just a textbook of zig examples. Ziglings
| is an interactive exercise
| pezgrande wrote:
| I like Zig but stopped learning it when I realized that all
| project based on it requires a specific version of the compiler
| to build.
| eclectric wrote:
| I would be interested to learn why that is a problem. As a new
| Rust learner, I am curious.
| loeg wrote:
| It might not be the version you have installed, or the same
| version as another project you want to glue together into a
| single application.
| zuzululu wrote:
| wow. this is a major miss from Zig.
|
| on top of the decision to ban AI, I can see that we haven't
| seen the last of bad decisions from Zig
| hiccuphippo wrote:
| It is still in active development and before v1. They
| haven't decided to make it unstable on purpose it's
| simply not done yet.
|
| Anyone using it right now implicitly accepts that they'll
| have to keep track of the changes in the language and
| update their code accordingly.
| afavour wrote:
| Rust has editions, which can be mixed and matched between
| different dependencies. AFAIK Zig does not have this.
| tialaramex wrote:
| Historically, say, 15 years ago before 1.0, Rust too was
| always shifting about and so you'd find that the software you
| wrote last month now doesn't even compile and the advice has
| changed.
|
| Today most people write entirely stable+ Rust, and as
| somebody else mentioned Rust uses Editions to allow it to
| make any remaining language improvements, but if you were
| writing mostly _unstable_ Rust you would see a reduced
| version of the same churn. Last month you could
| foozle.boozle() and that gets you a Wibble, but then you
| upgraded and now foozle doesn 't have a boozle method, and
| apparently Wibbles no longer exist at all, everybody says you
| need to learn about Wumps instead now because those are
| apparently better or something?
|
| + If you don't use a "nightly" build of Rust or a special
| opt-in "nightly mode" your Rust compiler only recognises the
| stable language.
| nvme0n1p1 wrote:
| The situation will improve once they release a stable 1.0
| version.
|
| Until then, use mise, nix, docker, or something similar. (You
| should be doing this anyway for projects in all languages if
| you care about them building on anyone's machine other than
| your own.)
| noelwelsh wrote:
| Very brief. I'm not sure what this adds over reading the language
| documentation (which itself is not great). As it's entirely
| organized by language features it doesn't really talk about any
| larger scale design decisions, which is where I think language
| proficiency is really found.
| miroljub wrote:
| Looking for a resource (MCP, CLI, Skill, ...) that would improve
| Zig support in LLMs.
|
| Currently, doing something with Zig as a target language would
| spend many more tokens and produce subpar results.
| voidUpdate wrote:
| If you worked through this and learnt to use zig, your token
| usage would be even lower!
| short_sells_poo wrote:
| Don't be ridiculous. Learning? That's for the dinosaurs. Just
| throw an llm at the problem!
| all2 wrote:
| Both is good. I do both, and to get reasonable output from
| an LLM I _have_ to do both.
| miroljub wrote:
| What's wrong with learning by reviewing the LLM generated
| code and asking questions interactively? Works for other
| languages.
| anonfunction wrote:
| One of the preeminent Zig software projects, Tigerbeetle[1],
| has a great website[2] and markdown file[3] for what they call
| TigerStyle.
|
| It's honestly a great read as a human but also I packaged it as
| a skill and saw coding agent improvement, especially around
| memory usage.
|
| 1. https://tigerbeetle.com/
|
| 2. https://tigerstyle.dev/
|
| 3.
| https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
| all2 wrote:
| Best bet is tight integration with a language server and the
| zig docs as MD locally. You may also pull in the zig source
| code as canonical reference for best practices.
|
| From there you can derive a set of tools and references that
| you can build skills on.
|
| Any LLM can scratch together an MCP server, its basically
| FastAPI + functionality. Your goal, then, is to identify the
| subset of tools and data required to get 'good' output.
|
| If you want to test your MCP server implementation, grab the
| source of several popular zig projects, rewind their git
| history, and have your LLM of choice attempt to address PRs for
| issues on those repos. Compare LLM solutions with the repo
| solutions, grade on token spend, LOC produced, variance from
| Zig best practices, and so on.
| brodo wrote:
| Wrapping this [1] in a skill will help a lot: Also add this [2]
| and `zig fmt` to your buid.zig.
|
| [1]: https://github.com/rockorager/zigdoc [2]:
| https://github.com/rockorager/ziglint
| baalimago wrote:
| I'm missing the concurrency model.
| Zambyte wrote:
| For what it's worth, the concurrency model is very similar to
| the one in Go. Zig has std.Io.Queue instead of channels,
| std.Io.async and std.Io.concurrent instead of the go keyword,
| and switch over std.Io.Select instead of the select keyword.
| There are lots of resources on concurrency in Go, and the
| learning semantics would carry nicely over to Zig.
| jdw64 wrote:
| Is Zig just a trend, or will it become a solidly established
| language? After all, learning something is an investment of time.
| With Zig, it doesn't seem to have the same kind of industry
| pressure as Rust. There's talk in open source circles about AI-
| related issues, and on Hacker News people say good things about
| Zig. The allocator concept looks great. But there's also a
| possibility that it won't become mainstream, like the D language.
| I personally like D and think its compiler is beautiful, but
| being linguistically good is different from being industrially
| adopted. So should I learn Zig, or wait a bit longer?
|
| For now, I have a basic grasp of C#, a little Python, a little
| C++, and a little TypeScript. I also know Java to some extent,
| but honestly, what I mostly build is CRUD app assembly. To go
| deeper, I think I need to dig into a systems language. But I'm
| not sure whether to invest in Zig or Rust.
| tempaccount420 wrote:
| IMO, there isn't much space left to fill that Rust couldn't
| already fill.
| code-blooded wrote:
| Simplicity is one thing Zig excels at (at least from my early
| observations).
| Zambyte wrote:
| Yup. Rust tries to make it hard to do systems programming
| poorly. Zig tries to make it easy to do systems programming
| well. Rust pushes you into certain (good) practices. Zig
| makes it exceptionally easy to understand what's happening,
| making good practices the obvious choice.
| dnautics wrote:
| How crazy is it to have a language where combining two
| foundation traits is such a huge footgun that the linter
| has to warn you (but somehow you can't ban it within the
| language)
| repelsteeltje wrote:
| Haven't yet used Zig in anger, but it looks more like a
| successor to C (with a bit of Go), whereas Rust is a
| successor to C++, first and foremost.
| pseidemann wrote:
| If you want to learn systems programming, I can recommend
| learning C. If you want to learn a programming language which
| allows systems programming, I guess Rust is not a bad choice.
| But it might be less helpful if the systems basics are unknown.
| jdw64 wrote:
| I'm an industrial equipment programmer, so I do see C quite
| often. Actually, aside from C, it's just that when I first
| learned programming in college, I started with C. I thought
| that was only natural, but I guess I didn't explain enough.
| Inside my own head, C just feels like a given.
| pepa65 wrote:
| In that case, definitely learn Rust, it will expand your
| thinking about programming and be useful. Zig would just be
| too similar to C.
| pseidemann wrote:
| If you know C well already, there is nowhere to go deeper
| systems-wise, apart from assembly. Maybe you mean higher as
| in more abstract? Rust is pretty abstract compared to C.
| Zig not so much by design. If you want to try something
| else entirely paradigm-wise, maybe something like Haskell
| could be interesting to you, or if type systems interest
| you, TypeScript's is quite sophisticated.
| groan wrote:
| Unless you're actively promoting one of the languages for
| financial gain, you have nothing to lose by delaying commitment
| to one, both, or either. If any of them have lasting value,
| they will be as easy to pick up in the future as they are now.
| Nobody cares about the old Java or .NET versions where both
| suffered from limited implementations of generics and other
| things, and nobody is a better programmer for having used them
| back then compared to picking them up today.
| jdw64 wrote:
| Learning a language is ultimately for the purpose of building
| something, so doing both is a bit difficult. Personally, I
| find Zig easier and more approachable than Rust, so I've been
| reading about it, but I'm worried about what I can actually
| do with it
| repelsteeltje wrote:
| Hadn't thought of that and I think you're right.
|
| Having been exposed to Java < 5 (before generics) Arrays felt
| somewhat like JavaScript or PHP3. It's a lot more ergonomic
| today.
|
| But there are still many remnants (like null refs, despite
| Option<>) that are easiest understood by tracing back Java's
| historical roots.
| CyberDildonics wrote:
| It's unsafe and intentionally crashes on windows newlines and
| tabs. If C adopts defer, I don't think there will be enough of
| a differentiation to overcome the cynical user hostility.
|
| Just because people don't like this doesn't mean it's not true.
| rfgplk wrote:
| > C adopts defer
|
| C will almost certainly adopt defer in the next revision
| standard. C++ (via RAII + scoped classes) already effectively
| has defer.
|
| But the fact that it's unsafe means it's effectively
| unadoptable, no reason not to use C inplace of it.
| raincole wrote:
| What's the difference between a trend and a solid language? I
| bet many (I mean like millions) people still think Rust is a
| trend.
|
| > To go deeper, I think I need to dig into a systems language
|
| Most of such code is still written in C.
|
| But honestly, if you just need to squeeze _a little bit_ more
| performance, you should check the non-GC part of C# first
| (ArrayPool, Span, stackalloc).
| the__alchemist wrote:
| I'm suspicious that the user base is people who like to program
| using pointers in business logic. So, the subset of current C
| programmers who are willing to switch.
|
| With this in mind: Does anyone here program in Zig, or know
| someone who does who is not a current C (or C++) programmer?
| dnautics wrote:
| I program in zig. I am not a current C/C++ programmer (last
| time I touched C++ was 2003; I can read C ~just fine...
| write, uh, I just hate make, okay?).
|
| Most recently I have used zig for:
|
| Linux USB driver for a proprietary industrial digital camera
| that claude hacked the protocol for (I usbpcap'ped it), bound
| into an embedded Elixir-Nerves biology workstation. Same
| workstation has a libtoupcap digital camera for a microscope
| camera also mounted (here I use zig for the dlload boundary
| with elixir). The proprietary system I am running it on
| ironically won't work with windows anymore because the
| proprietary software it shipped with chokes when there are
| two cameras attached.
|
| I ship zigler, the embed-zig-in-elixir library. I keep
| finding more and more uses for it!
| hiccuphippo wrote:
| Also people who wants to get into lower level languages but
| is scared of C's footguns and C++/Rust language size: me.
| nurbl wrote:
| I'm professionally a python programmer with no C/C++
| experience, and I do some hobby programming in zig. I tried
| rust but it seemed complicated and kind of boring. Zig was a
| lot easier for me to get into. I don't mind that it's obscure
| and a bit of a moving target, but I have yet to do anything
| really "serious" with it.
| Cloudef wrote:
| Zig is not only a language. Its whole toolchain and takes
| freestanding as a target seriously.
| stephc_int13 wrote:
| Lindy effect is very strong in the programming languages world.
|
| Zig is a very interesting and well built language, but it is
| also niche, unstable and not offering radical improvements over
| C.
|
| C, as the foundation of all modern kernels and system tools,
| among many other things, is extremely unlikely to go away soon.
|
| Everything you do in Zig can be done almost in the same way in
| C or C++.
|
| I would say the real value of Zig is in the standard library
| that is more modern and arguably better.
| dnautics wrote:
| > Everything you do in Zig can be done almost in the same way
| in C or C++.
|
| Can you do this in C?
|
| https://github.com/ityonemo/clr
| stephc_int13 wrote:
| Linters are not exactly a new idea, and they can be pushed
| quite far.
|
| I am generally against the idea of language support for
| meta-programming, even using C macros or C++ templates.
|
| I do a lot of meta-programming/codegen with external
| tooling.
| dnautics wrote:
| > Linters are not exactly a new idea, and they can be
| pushed quite far.
|
| That's not an answer. There's a reason why you can't do
| it in C, and the reason is "the stdlib is poorly
| designed". No amount of linting can get you around that.
| stephc_int13 wrote:
| I agree about the C stdlib being outdated and the worst
| part of C. This is why I don't use it.
|
| A new modern C standard library would be a very good
| thing. But I am ok writing my own, tailored for my own
| needs and style.
| scottlamb wrote:
| Is there a particular domain you'd like to get into? It sounds
| like you're wanting to build expertise in something other than
| CRUD app assembly, but my language recommendations might change
| based on whether that's embedded, game development, distributed
| systems, system administration, etc.
|
| I don't think in your shoes I'd prioritize learning Zig for any
| of these domains, though, for a few reasons:
|
| * It's not a pre-req for understanding some existing corpus of
| important software (which is a big reason for C and C++ in
| 2026) or the language of choice for some current hot domain (as
| Python is for AI).
|
| * It's not memory-safe, which (whether via GC or Rust's borrow
| checker) is increasingly viewed as a critical security
| attribute.
|
| * It's not stable yet, so I'd expect a certain amount of
| running to keep in place both in your learning and in avoiding
| bitrot in anything you write in it.
|
| * From the outside, the community seems strangely hostile as
| well as elitist.
|
| A few I might suggest instead: Rust (both as a language I
| personally like and as the most different from the ones you've
| already touched), Go (which is a good choice for
| employability), SQL (maybe you already know this one if you're
| doing CRUD stuff but you didn't list it), bash, and more Python
| and/or TypeScript.
| scuff3d wrote:
| Rust didn't have nearly the industry adoption it does now back
| in 2020, but it was gaining traction in various parts of the
| community. If you learned it back then it was either because
| you love it, or you thought it had staying power.
|
| I think Zig does, specifically because of its build system and
| it's C interopt story. Plus Zig has the added advantage that
| learning it teaches you about how the computer works, how
| memory gets laid out, etc. So even if it never gets wide
| adoption the skills are highly transferable.
| Decabytes wrote:
| Here is where I think Zig shines. When you are a high level
| programmer that needs to drop down to a low level programming
| language for performance reasons. The issue with doing that as
| a high level programmer is that you don't do a lot of low level
| work frequently.
|
| So unless you work in another domain where you do a lot of low
| level programming, then every time you drop down you will be
| out of practice. This favors using a simpler low level
| language, with low friction for integration. Rust and C++ don't
| handle being used infrequently, but C with it's simpler
| standard library and syntax fits this nicely. But it doesn't
| have things you expect for a modern programming language, and
| it is also has a lot of dangerous footguns that are easy to
| forget if you are out of practice
|
| In comes Zig. It's low level, comes with it's own toolchain
| that makes it pleasant to work with, easy to cross compile, has
| more safety features built in that C, but is not overly
| complicated. The code tends to be more verbose, but also more
| straightforward. So it's a perfect language to pair, when you
| know you won't be able to do everything in a high level
| language.
|
| For me that's what seals the deal. I'd argue that Odin has a
| nicer syntax, but there is a reason that tools like cargo-
| zigbuild^1 exists. The fact projects not related to Zig are
| willing to ship Zig toolchains to make lives easier is a
| testament to how seriously Zig takes this.
|
| 1. https://crates.io/crates/cargo-zigbuild
| jayd16 wrote:
| Looking at it from an existing knowledge base and error
| checking point of view, I feel like C++ smart pointers or
| Rust is a better option for someone doing a dangerous low
| level thing rarely. I'm not sure Zig is really all that
| favorable a choice in your given scenario.
| Cloudef wrote:
| Rust unsafe is less safe than writing C code. Rust is not
| good language for writing "unsafe code". C++ smart pointers
| are really bad compared to arena allocators, and not
| allocating at all. It's very easy to end up with dangling
| references in C++, or double frees with smart pointers.
| Also the fact that C++ initialization itself is a huge foot
| gun.
| tialaramex wrote:
| I think if you need to get so close to the bare metal that
| you'd need _unsafe_ Rust then the equivalent Zig is also too
| dangerous to use "infrequently". Stuff like writing raw
| assembly, pointer twiddling, volatile stores or fetches - I
| would hire somebody with lots more experience to do that
| properly once if you need it.
|
| On the other hand if _safe_ Rust is an option that 's way
| more handholding than you're getting in Zig. Lots of "Whoops
| I forgot" mistakes won't even compile in safe Rust because it
| couldn't see why they're OK and that's required but in Zig
| now you've written a bug.
| Decabytes wrote:
| For clarity in this dual programming language scenario I'm
| talking about, I'm writing a user facing app that's mostly
| a lot of business logic.
|
| It's running slow so I profile it and I see my math
| function in pure Dart (or whatever language you are writing
| in) is the hot spot, and pressures the garbage collector
| too much, so I rewrite the function in a lower level
| language that doesn't have as much overhead, to speed
| things up. Then I just call it from the higher level
| language through the FFI.
|
| The benefit of Zig is the syntax is simple, and the build
| steps are simple, so it doesn't slow down app development
| too much
| Erenay09 wrote:
| I'd prefer that you watch this video interview with Andrew
| Kelley. He is describing that.
|
| https://www.youtube.com/watch?v=iqddnwKF8HQ
|
| Personal thoughts: I think Zig will become more stable once 1.0
| tag released. Currently I cant find a fix to my error in net.
| But the folks on Zig Discord server helping me out.
| kmaitreys wrote:
| Why do people still view languages as an investment? If you
| know programming then it's just a different syntax. Focus on
| learning programming.
| kyralis wrote:
| You're not wrong at the high level, but learning a particular
| language to the point of fluency is still an investment if
| you're interested in being productive while writing it. Sure,
| once you have the experience, reading most new languages is
| easy -- but learning the idioms and particular syntactic
| choices of a new language to that point that you can reach
| for them without having to constantly search or consult
| references isn't something that's instant. There's also a
| mental cost to how many of those languages you can have
| "ready to go" in your brain at any given time, and for
| languages that are evolving -- most of them, at this point,
| honestly, even old languages like C++ -- there's a cost to
| keeping up with the language as it changes.
|
| All of that is investment, and not all languages pay off that
| investment.
| kmaitreys wrote:
| I have never understood this way of approaching
| programming. I feel the best way to learn a language is
| solving a problem you have in that language.
|
| Figure out an actual real problem you have which you can
| solve with programming and just implement it in a language
| you're thinking about learning. This way there's nothing to
| invest in because you're solving a problem instead of
| approaching programming as if it was some coursework. It is
| not.
| hwntw wrote:
| I'd say it's worth learning new languages even purely for the
| sake and love of learning! That goes to both Rust and Zig, Rust
| is arguably more intellectually interesting, whereas with Zig
| you'll probably be writing useable hobby projects much quicker
| (I decided to tackle learning Zig and reading Crafting
| Interpreters simultaneously, transliterating the code in the
| book as I went along).
|
| Zig will be much easier to learn than Rust, but it's worth
| noting that it's syntactically _very_ unstable between releases
| (there were some huge changes between 0.15.2 and 0.16 to
| anything involving IO).
|
| It's really hard to predict what you'll actually use
| professionally in the future or what's going to be popular in
| ten years, but some of the greatest value comes from just
| learning a huge variety of topics.
|
| I'm a firm believer in prioritising enjoyment over utility, and
| I've always found that utility has flowed backwards from the
| enjoyment. And even if it doesn't, you've had a good time and
| found yourself richer for it!
| zuzululu wrote:
| I predict it will go the way of Ruby but far less adoption or
| jobs available since Zig community as a whole is anti-AI, which
| makes it impossible to operate with modern times.
| lukaslalinsky wrote:
| I feel that Zig will stay a niche language. In this world,
| there is no reason for corporations to use anything but Rust
| for this kind of code. And without the corporate push, it will
| probably still exist for a long time, but the D trajectory is
| what I predict. I really like the language and I hope it gets
| more popular, but it seems unlikely to me.
| stephc_int13 wrote:
| Encapsulating arguments inside .{} seems superfluous and noisy.
|
| I'm sure this can be rationalized in some way, to either simplify
| parsing or solve some rare ambiguity, but I just don't see it.
|
| I know this is a minor thing and can be considered as nitpicky,
| and I expect some friction with syntax when learning a new
| language, but I just can't stand things I see as gratuitous. Same
| with the forced use of _ = foo(.{}); to avoid compiling errors...
| brodo wrote:
| In Zig, function arguments are not wrapped in `.{}`. `.{}` is
| the syntax for creating a struct or a tuple. This is used as a
| pattern for allowing optional arguments (options struct) and
| variadic functions (tuple).
|
| Explicitly discarding return values is a thing many modern
| programming languages force you to do.
| stephc_int13 wrote:
| I know, and I don't see unused return values as an error, it
| should be a warning at best.
|
| And the compiler should be just a bit smarter to avoid the
| .{} thing when it is not strictly necessary.
| dnautics wrote:
| > And the compiler should be just a bit smarter to avoid
| the .{} thing when it is not strictly necessary.
|
| What's your plan for this? Rebuilding the C varargs mess
| from first principles?
| dnautics wrote:
| > Encapsulating arguments inside .{} seems superfluous and
| noisy.
|
| You don't do this? This is only for varargs or optionals.
|
| .{<stuff>} is just a shorthand for Type{<stuff>} (struct
| constructor) plus, "hey compiler, you figure out the type". So
| if anything it's LESS noisy than the alternative, and more
| forward-compatible if you change a type name for example.
| hiccuphippo wrote:
| I see it this way, the full signature for defining a variable
| is: var foo: Foo = Foo{};
|
| There's two ways to shorten it: var foo =
| Foo{}; var foo: Foo = .{};
|
| It can infer the type of the var from the right hand side; or
| the type of the right side from the type of the var.
|
| So when you see .{} as an argument, it is inferring the type
| from the function signature. It happens to be empty only
| because it's using default values (or is a tuple with 0 items).
|
| Edit: fixed the extra dots.
| dnautics wrote:
| that's not quite right.
|
| 1) It's var foo = Foo{...}; (no intervening dot)
|
| 2) I think parent commenter is referring to function call use
| case call_my_func(.{...})
| hiccuphippo wrote:
| 1) Ah yes, just typing from memory. Point still stands.
|
| 2) Adressed in the last paragraph.
| dnautics wrote:
| Point being, these two things aren't different (variable
| assignment and function calls); IIUC they go through the
| same analysis pathway, result location semantics.
|
| https://ziglang.org/documentation/master/#Result-
| Location-Se...
|
| It's a little bit weird, since the types flow in the
| reverse direction than you would expect.
| yrds96 wrote:
| This is outdated and AI generated.
|
| If you want a good source of zig learning material interactive
| and by examples please check out ziglings:
| https://codeberg.org/ziglings
|
| It's writen and tested by humans, which is essential for learning
| purposes. It's listed in the official zig website, by the way.
|
| This project is always up to date to the latest zig release.
| systems wrote:
| well, it also made by the same guy behind the boring go book
| which probably means that boring go is also most likely AI
| generated
|
| nowadays before reading or buying any book, we need to
| extensively investigate the author, the author name is now more
| important than ever, i think whenever a book is shared, the
| author need to me highlighted
| embedding-shape wrote:
| > nowadays before reading or buying any book, we need to
| extensively investigate the author
|
| I mean not really. You read a paragraph or two and notice the
| quality of the text, start getting suspicious and continue
| two or three paragraphs more, notice some very basic
| inconsistencies/incoherence, realize it's AI-written and
| ctrl+w the tab (or put back the book in the shelf) and move
| on with your life.
|
| If there is no samples of the book, I'd hesitate to even
| consider buying it, just so you can actually sample the text.
| Very easy in bookstores luckily, so not a huge problem in the
| end.
| Jblx2 wrote:
| You can just read a paragraph or two of each email, and
| then decide whether or not to delete them. We don't
| additional tools to combat spam.
| embedding-shape wrote:
| Kind of feels like a slightly different thing, I don't
| spend days/weeks reading through one email.
| systems wrote:
| we don't pay for emails either
|
| i think for consumer protection, AI products need to be
| flagged as AI products, clearly labelled as AI produced
| or assisted , of course for free goods the burden is on
| us, but for anything we pay for, I hope we get this
| protection
| Jblx2 wrote:
| If someone wanted an AI generated Zig tutorial, why
| wouldn't they go to their favorite LLM supplier and
| simply prompt the AI for one? Why do we need someone to
| create this spam ahead of time? LLMs are improving all
| the time and Zig is a moving target. Seems like a win-
| win-win. The end-user gets a better (and potentially
| customized) tutorial for the latest Zig, and there is
| less overall spam pollution.
| embedding-shape wrote:
| I don't have the answers to those questions, and I don't
| know why I'm being asked those either. I don't like AI-
| slop either, I don't think anyone except the ones who
| produce it themselves like it.
|
| But ultimately it's a fools errand trying to stop/get
| people to do something, best you can do is adjust your
| own approach.
| cgh wrote:
| That guy's entire post and submission history appears to be
| listicles and slop.
| zuzululu wrote:
| I think this is a major problem with Zig in that they've
| cornered themselves into not utilizing AI and have attracted
| anti-AI absolutist crowd that is going to be a major
| hinderance.
|
| As a Rust user, AI has put Rust easily in the hands of
| developers who were previously intimidated by it. I've learned
| a ton about Rust simply by fiddling with LLMs and asking
| questions to other Rust devs who don't really care whether AI
| is used.
|
| As soon as you give into the mob rule, your existence is going
| to depend entirely on the ideology of the crowd and you lose
| the ability to adapt and remain competitive. ex) "modern
| audience" games from large studios.
| nafizh wrote:
| You are free to use AI to write Zig code just not use AI to
| write code for Zig. In fact, many people already do build
| software with zig written by AI. Check out rockorager's
| github.
| b33j0r wrote:
| Do not use this, I recommend ziglings if anything besides what
| Loris would say: you have to read code.
|
| The builtins don't even compile in these examples. This is 2
| years out of date at least.
| tapirl wrote:
| Having quick viewed all the chapters, the examples are too
| simplistic to fully demonstrate Zig's syntax and semantics.
| porteghal wrote:
| just read it fast and easy! for a starter like me? amazing!
| atique29 wrote:
| My gut feelings had me check the Zig version. "Examples target
| Zig 0.14." Ah there we go
| mustaphah wrote:
| You would probably be better off reading
| learnxinyminutes.com/zig/
| Thanemate wrote:
| 3 commits? Really? Why don't I just ask Claude or chatGPT
| instead?
| synergy20 wrote:
| does zig still matter in the AI era? i was learning zig on and
| off and now have no motivation to learn it anymore.
___________________________________________________________________
(page generated 2026-06-09 05:02 UTC)