| ▲ | ACCount37 4 hours 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? |
|
| ▲ | dmit 3 hours ago | parent | next [-] |
| 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 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | archargelod an hour ago | parent | next [-] | | > For the rare exceptions, I make a C lib The problem is that most people using Python don't have enough expertise in C to do the same. It also kinda destroys the argument that Python is good if your solution for performance is to use a different language alongside it. | | |
| ▲ | itishappy 29 minutes ago | parent [-] | | The argument is that the ergonomics of using Python are worth the squeeze of learning two languages. Are the ergonomics of using Zig really enough to justify replacing Python on the happy path, or would it end up replacing just C? |
| |
| ▲ | lenkite an hour ago | parent | prev | next [-] | | Even if you are fine with Python's speed, its memory consumption DOES effect things and can be an extraordinary pain when you need to fit the result of your tinkering in any sort of constrained environment. | | |
| ▲ | maccard 32 minutes ago | parent [-] | | By the time I’m memory constrained even on my laptop the processing cost of whatever I’m doing has gone beyond shoving it in the first scripting language I can find. Every device I write code on has at least 16GB RAM - most of them are 64 or 128 |
| |
| ▲ | p-e-w 3 hours ago | parent | prev | next [-] | | 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 3 hours ago | parent | next [-] | | 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. | |
| ▲ | bluecalm 2 hours ago | parent | prev [-] | | Only if you doing something thousands of people has done before.
Anything new, even very simple and you are on your own and Python is 100x slower than naive C implementation on many tasks. Last little project I remember is writing a solver for a puzzle game my friend published. Python just doesn't work at all for such tasks. I think you are wrong about speed of those libraries as well. In my experience naive code designed for a specific task beats highly sophisticated general code and it doesn't take a rocket scientist to get huge speed-ups over some well established fast library. |
| |
| ▲ | miki123211 2 hours ago | parent | prev [-] | | And if you really need more performance (or, more often, fast startup times), Go gives you 90% of the speed with 30% of the effort. Rust if you really want to squeeze everything that can possibly be squeezed of that CPU. | | |
| ▲ | pmarreck 32 minutes ago | parent [-] | | that’s not what the benchmarks say about Go, and based on multiple reports, Rust does not scale well into large codebases, which eventually become brittle and very difficult to change Zig is a return to “no magical effects,” except with reasonable safety | | |
| ▲ | kibwen 2 minutes ago | parent | next [-] | | > based on multiple reports These reports are smoking crack. Rust scales gloriously well into large codebases, and it especially shines when it comes to making major refactorings. Please don't bother speaking about things that you don't understand. | |
| ▲ | Synthetic7346 21 minutes ago | parent | prev [-] | | Link to said benchmarks? |
|
|
| |
| ▲ | archargelod an hour ago | parent | prev [-] | | That's actually a great argument for Nim[0]. Easy interop with C, native-speed performance, and a syntax very close to Python in both readability and how quickly you can get something working. Batteries included, automatic memory management without a conventional GC and metaprogramming - is a really cool combination. [0] - https://nim-lang.org/ | | |
| ▲ | tatjam an hour ago | parent | next [-] | | Aggh if only its LSP was better! I have always run into issues when using Helix with it (it kept crashing), and I'm absolutely spoiled by good LSPs in other languages :( Wish I had the time and skill to actually contribute to the LSP, if you have ever used Nim it's a seriously underrated language. | |
| ▲ | pmarreck 26 minutes ago | parent | prev [-] | | it is my second choice next to Zig and does have a lot of cool features, for sure. The nice thing is that all these languages feature easy C interop so you can use a C FFI as the interface between them if you want to experiment with, for example, writing a module in Nim |
|
|
|
| ▲ | norman784 4 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | 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. | | |
| ▲ | mcdonje 3 hours ago | parent | next [-] | | You have a weirdly restrictive definition of "tinker" | | |
| ▲ | maccard 30 minutes ago | parent | next [-] | | Almost all of my tinkering is “download this thing, cache it (because it’s huge), run a program or a series of programs on it, and package the output up somewhere.” When I’m writing the thing that does the work I’m not tinkering any more.. | |
| ▲ | ACCount37 an hour ago | parent | prev [-] | | 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 33 minutes ago | parent [-] | | 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 a minute ago | parent [-] | | 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? |
|
|
| |
| ▲ | andyferris 3 hours ago | parent | prev | next [-] | | 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). | | |
| ▲ | jcul 2 hours ago | parent | next [-] | | 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. | | |
| ▲ | robinsonb5 an hour ago | parent | next [-] | | If some of the things that the C standard left undefined had instead been made implementation defined then the compiler would at least be obligated to do something that makes sense on the target architecture, rather than having license to take the lawful-evil route. (Plenty of architectures have addressable RAM at location zero, for instance.) For some reason this always brings to mind that moment in Red Dwarf where Kryten, devoid of his behavioural chip, deems it appropriate to serve roast human to his crewmates. "If you eat chicken, obviously you'd eat your own species as well, otherwise you'd just be picking on the chickens!" | |
| ▲ | uecker 2 hours ago | parent | prev [-] | | Both C and C++ compilers (in fact, they share this part) very aggressively exploited undefined behavior for performance. But I this was certainly not adversarial. Programmers also regularity picked optimizations over safety. I think nowadays the unsafety of C with modern tooling vs the safety of - say - Rust is very much exaggerated. |
| |
| ▲ | pjmlp 3 hours ago | parent | prev [-] | | Basically what the world has lost by ignoring Modula-2 and Object Pascal, and going down the C path. | | |
| ▲ | archargelod an hour ago | parent [-] | | The spirit of Pascal lives on in Nim. It's arguably the closest modern language (with a sizeable community) to the Wirthian languages. | | |
| ▲ | jodrellblank 24 minutes ago | parent | next [-] | | There’s a spirit of Pascal in Odin, although not a sizeable community. http://odin-lang.org/ | |
| ▲ | pjmlp 43 minutes ago | parent | prev [-] | | 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. |
|
|
| |
| ▲ | 3 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | brabel 3 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | 2 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | pmarreck 25 minutes ago | parent | prev [-] | | > 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 |
|
|
|
| ▲ | flossly an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | miki123211 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | portly 3 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | dtj1123 2 hours ago | parent | prev [-] |
| 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 30 minutes ago | parent [-] | | 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. |
|