6 ms·

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every ti

• ACCount37 4mo ago
  Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?
  • norman784 4mo ago
    Zig is low level, so it will certainly not replace your python usage, it is more like a modern C than anything else. There’s a video of a recent interview with Andrew Kelley, if you want to watch it to understand better what Zig is for, it’s on Jetbrains YouTube channel.
    • ACCount37 4mo ago
      No, I get that, but Zig being low level is kind of why I don't get why it would be a good tinkering language? When I want to tinker, I just want my logic to work, first of all. In 9 cases out of 10 that means going for high level. Even if the resulting code works with low level things like binary structures.
      • pmarreck 4mo ago
        > I just want my logic to work what the heck has convinced you that logic is somehow flawed in a new low-level language? LOLLL
      • deleted 4mo ago
        [deleted]
      • andyferris 4mo ago
        Low-level programming gets a bad name because C has many footguns and the spec leaves much behavior undefined - a fact that implementers use almost adversarially (which I'd support, if the goal was to refine the spec...). C++ adds more high-level conveniences without actually removing the footguns and undefined behavior (much C code compiles in a C++ compiler). Zig tries to keep the low-level C philosophy but have things more well factored and well defined. The result is you _can_ tinker in high-level code, yet "drop down" into low-level code as you desire. (Compared to rust, you get fewer compiler-enforced guarantees, but unlike C the language isn't trying to make high-level code adversarial).
        • pjmlp 4mo ago
          Basically what the world has lost by ignoring Modula-2 and Object Pascal, and going down the C path.
          • archargelod 4mo ago
            The spirit of Pascal lives on in Nim. It's arguably the closest modern language (with a sizeable community) to the Wirthian languages.
            • pjmlp 4mo ago
              I would add that Delphi still follows along, enough for an yearly conference in Germany, and that C# since getting Native AOT and the low level programming improvements, is close enough to Modula-3 design. There is Swift as well, although quite far from Wirthian compile times.
            • jodrellblank 4mo ago
              There’s a spirit of Pascal in Odin, although not a sizeable community. http://odin-lang.org/ http://odin-lang.org/
        • jcul 4mo ago
          It made me laugh to think of C implementers being adversarial! It can feel that way. I haven't really used modern C, not sure if it's evolved as much as modern C++, which I feel is a joy to use, and a lot safer. But then I've been writing C++ for decades. I feel like C evolved from basically syntax sugar for assembly, so that's where all the footguns come from, rather than being actually adversarial.
      • mcdonje 4mo ago
        You have a weirdly restrictive definition of "tinker"
        • ACCount37 4mo ago
          Not really? I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever. Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor. The tooling around embedded devices though? Python.
          • cornstalks 4mo ago
            When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?
            • ACCount37 4mo ago
              Most of the time "make something faster than anyone else has done" is just not worth doing? Good enough is good enough. Unless it's some super hot path and it's the speed that's the main goal, nothing else. Which is rarely the case. If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?
              • cornstalks 4mo ago
                No, I’m saying that it’s how I like to tinker. Others have their own ways of tinkering that are just as valid! I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process. I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.
      • brabel 4mo ago
        Tinkering means different things to different people! Want to tinker with your hardware, as bare metal as possible? Or extract every inch of performance out of your CPU? Zig is great for that.
      • deleted 4mo ago
        [deleted]
  • dmit 4mo ago
    Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C. As for the language itself, it's going to be more verbose than your Python code. Cons: you'll have to spell out a lot of things that you thought were obvious assumptions. Pros: you will be able to look at a page of code and know with a great degree of certainty that there are no hidden gotchas. No monkey patching, no __init__. Basically, it just does what it says on the tin. And finally, about the std lib and batteries: there's HTTP(S), compression algorithms, hash algorithms, RNG, I/O, the basic data structures you'd expect, JSON. Third-party libraries, if you choose not to vendor, are handled by including the repository url in a file (also automated by a CLI command), and then adding it to the build script (not automated). The `zig` command handles fetching and ensuring sanity, but otherwise assume a bit of elbow grease will need to be involved.
    • ACCount37 4mo ago
      Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch. For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.
      • p-e-w 4mo ago
        Not to mention that where heavy computation is required, Python often has libraries that are much, much faster than anything you can quickly hack together in C or Zig.
        • maleldil 4mo ago
          As long as you can express everything you need on the library's terms. As soon as you write a Python loop, your performance plummets.
  • portly 4mo ago
    I like that you have more freedom. You can play around with some idea but once you want to do something "serious" you can break into it directly. I start simple but sometimes blip into some performance obsession and I find Zig allows that.
  • miki123211 4mo ago
    And not only that, if you're doing something in Python, somebody has done it before. Maybe not this exact thing, but something close enough to it. LLMs know it, Stackoverflow knows it, whatever esoteric protocol or file format you're trying to interact with, somebody wrote a library for it in the Python 2 days and has ironed out all the bugs since. There's no other language quite like Python in this regard. Typescript is a close second, but the lack of metaprogramming facilities, no access to the type annotations at runtime, and the lack of operator overloading make some things needlessly complicated and uglier than they have any right to be.
  • dtj1123 4mo ago
    The only language I've historically been able to claim to know without feeling like I'm straight up lying has been Python, and having got past my first maybe 1000 lines of Zig I can say pretty confidently that whatever magic makes Python feel comfortable to write, Zig has too. It requires more of you in some ways, notably that you have to understand the basics of memory management and the behaviour of the stack, but so far I've found the affordances that the language provides for handling this stuff feel very intuitive. The only sharp edges I've felt so far have been the sometimes hard to guess locations of things in the standard library, and the permenant anxiety that arises from knowing I'm going to be a few more versions behind the current release with every month that passes.
    • lioeters 4mo ago
      It's true that Zig is very readable. I haven't yet seriouly studied or written much of it, but browsing through codebases of popular Zig projects, a lot of it just makes sense intuitively. In that way it has a Python-like friendliness of syntax. I enjoy the community and culture around Zig too. The other day I found a forum thread where people were sharing what they're currently building, and there were so many fun projects from small hobbyist things to large ambitious ones. For the latter, the main concern is the stability of the language, but the good thing is that everything is out in the open, everyone knows Zig hasn't reached version 1 status - but I can see concrete steps are being made to find a good solid interface, including this I/O stuff in 0.16. As someone casually learning the language, I find it refreshing to have insight into the development process.
  • flossly 4mo ago
    You both like different types of tinkering. Some people put a generator on a tesla cybertruck and call that garage tinkering. Some people make a go-cart out of a lawnmower and call that garage tinkering. The first is the "batteries included Python" tinkering, the second is the "low level Zig" tinkering.
  • jasdfasd8 4mo ago
    Crazy flexing a gateway programming language that everyone and their chachi knows.
  • FpUser 4mo ago
    I once had to write software that would go through whole bunch of PHP code (more than 5000 files), parse / discover certain patterns and write report with proposed fixes or same but with the fixes applied. For whatever reasons I had to do it in Python. It was total nightmare to debug as the execution speed in debug mode was insanely slow. I could've written it in C++ in exactly the same time and not to have any of the performance problems.
  • trueno 4mo ago
    took me a minute but once i started tinkering with compiled outputs and not dealing with runtimes and venvs my ability to tinker went super crazy. being able to pass something off to my vps with no dependencies if i was tinkering with something hosted was fantastic, or sharing a sidequest with a coworker that's buttoned up and ready to go with no additional environment setup for them
  • lll-o-lll 4mo ago
    “Tinker in my garage” for low level things. If I’m playing around with a custom layer 2 protocol, python is not my language of choice. Basically, if what you are tinkering needs precise control over the bits and bytes, Zig (or C) are designed for it.
  • OtomotO 4mo ago
    That's so funny. At university we didn't use Python, but mostly Java, C++, C a bit of Haskell and some even more esoteric ones. Sure thing I got exposed to Python, but to this day, I don't like it. All that whitespace typing just kills me xD I am not normally someone who cares the slightest about Syntax. I've written Rust, C++, C, C#, JavaScript, TypeScript, Haskell, Kotlin, Scala, PHP, and many, many more in my spare time and being paid to... Yes, I've also been paid to write Python and I use it for some scripts instead of bash occasionally, but boy will I never like Python
    • danielEM 4mo ago
      Well, I feel you very much about Python! Also was coding in plenty of languages for past 30 years (assembly, pascal, C, D, java, visual basic, typescript, C++, and so on and so for) and every now and then I wonder if that aversion of mine towards indentation based languages (python, nim) comes from lack of enough flexibility of my mind/aversion towards training my brain to use and recognize different coding way or it is simply because it not ergonomic enough once you reach certain skill level.
  • tomjen3 4mo ago
    Control. Its a replacement for C that is a lot nicer to work with. So basically if you either need your Python code to interact with a native library or need more control in a specific place, you can use Zig there. Zig makes it trivial to control which part of the code e.g allocate memory, so you can guarantee that your rendering or audio loop has no stuttering. I would still keep Python as the main driver for where dev speed is the most important part.
• asibahi 4mo ago
  It’s definitely a great tinkering language but .. eh .. the Zig team and community are extremely opinionated about how to use the language correctly.
  • mcdonje 4mo ago
    Not really
  • 0x696C6961 4mo ago
    This has not been my experience.
    • xyzsparetimexyz 4mo ago
      https://www.reddit.com/r/Zig/comments/onzsfl/illegal_tabs/ https://www.reddit.com/r/Zig/comments/onzsfl/illegal_tabs/
      • j16sdiz 4mo ago
        I won't call it "opinionated about how to use the language correctly." Space is valid and it compile, Tab don't --- that's it. When one say "opinionated about how to use the language correctly", I would think JavaScript with or without end of statement semicolon and being yell at even when your program works.
      • 0x696C6961 4mo ago
        I don't understand how this is relevant to the thread.
• samuell 4mo ago
  My main issue with this is I expect Mojo to become the go to tinkering language for me.
• xyzsparetimexyz 4mo ago
  > But nothing gets in your face how to use the programming language "correctly". It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me
  • galangalalgol 4mo ago
    What do you like to ise those features for?
    • xyzsparetimexyz 4mo ago
      In rust, having unused variables as a warning (but not an error) let's you refactor code, test it and see what is now unused as a result. You can then remove the unused items. Zig requires you to remove the unused items (e.g. with '_ = ...;' which is then something you might forget about) before testing, increasing friction. Multiline comments are less important, but its still convenient for commenting out large chunks of code. IDEs make this a bit easier when you can press e.g. Ctrl+/ to comment out the selected lines with //, but it doesn't work in all cases. The friction stops zig from being fun imo. A shame because I really like comptime.
      • galangalalgol 4mo ago
        Thanks, there is always a risk of people jumping on replies like that to scream that you are doing it wrong. I just wanted to see how other people do stuff. Hope everyone stays nice.
    • Weebs 4mo ago
      Not the person you replied to but I leave unused variables as future TODOs. It's a warning in F#. I also often use them for inspecting data in the debugger
  • afirmativ 4mo ago
    I agree - can't create and toggle between rough code sketches of functions in a source file without these features. It's more than annoying.