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.
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.
Technically true, but unsafe Rust is much harder to deal with because it makes assumptions (sometimes very non-obvious) regarding aliasing that Zig does not. You might think you can avoid problems by using T* rather than T&, but every accessible local is effectively a T& so it's still very easy to do something you're not supposed to.
No, I'm not sure where you heard this but this is certainly not the case. If I have an i32 on the stack in Rust, there are no aliasing invariants that need to be upheld. You do, in fact, avoid problems in unsafe Rust by just using raw pointers instead of references. The idea that "unsafe Rust is harder to deal with than {Zig, C, C++}" is a long-outdated notion from old versions of Rust, before there was a dedicated way to produce a raw pointer without first producing an intermediate reference.
Go does not give you control. Much of the speed comes from choosing the right algorithms - including memory management. In Go you have GC, you don't have that in Zig.
Linked lists are a lot less slow if you use Arena allocation around your hotspots and make sure to allocate space for as many as you thing you need, since they will be carved out of a contigious block of memory and will stay in CPU cache.
Golang also requires you to write more code, as it lags Zigs try operator.
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
I would be very surprised to see a large Rust codebase being harder to maintain than a large Zig codebase. The former makes it much easier to maintain invariants at scale.
Well, you could go ask Richard Feldman, who I believe cited that reason to rewrite the nascent Roc language from being implemented in Rust to Zig, or anyone else who is moving from Rust to anything else. I've seen multiple people at this point complain about the scaling issue with Rust; the larger the codebase, the more you end up fighting the compiler before anything will actually build.
Note that it doesn't matter if the compiler is correct about its claims; if the language doesn't actively discourage patterns that produce this outcome at scale, then the language does not scale, end of story.
The trend is basically either linear or exponential: as more LOC of Rust are added, the greater the percent of total time you spend fighting the compiler to get a successful build, especially in a team context (which is exactly what gets you to >1M LOC). Solo devs can contain the whole design in their minds and may not run into this issue as much; the problem specifically occurs on teams where the mental model MUST be fractured by necessity, and this results in "distributed knowledge of magic" that ends up constantly breaking.
Perhaps this explains WHY there aren't that many Rust projects done by more than 1 developer that approach that many LOC.
Unless you enforce those macros somehow in a team setting, someone's going to forget to use them, and then you're still stuck with the original problem.
By the time C++ and Java were as old as Rust is today there were thousands of programs that over 1MLOC that had been maintained for at least five years. Rust is a rather old language, yet I doubt there are even hundreds of Rust programs over 1MLOC.
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.
You are entirely right here, you're also incredibly rude. Please don't bother replying when the only thing you're actually doing is being condescending and spreading negativity
Rudeness is perfectly acceptable when it comes to preventing the spread of blithe and thoughtless disinformation. I have no obligation to be polite to people who speak authoritatively on topics they know nothing about. I recommend you spend less energy on trying to defend clueless people by policing the tone of the people educating them, unless you think that polite ignorance is more societally valuable than brusque truth.
Could you please not sermonize or act like a demanding customer? We don't, and can't ever, see everything that's posted here, and even if we could it's not appropriate for moderators to adjudicate on the correctness of any claim. It’s by cultivating discussions between different people with different perspectives that we illuminate topics here. Obviously you have deep expertise on those topic. Great! Please educate people rather than berating them.
This is only a place anyone wants to participate on because we have guidelines and others make the effort to observe them. You've been here long enough to know that. Please don't trash what you seem to have found value in for so long. We don't need you to be "effusively pleasant" or erudite, just respectful.
For the price of all this righteousness you could have provided a reference. Some reference. So that curious bystanders like me can learn from the exchange.
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?
I find Python extremely unergonomical. Sure, it's nice to read (pseudocode, yay!) and sure, its library ecosystem is beyond amazing.
But... the LSPs I've tried (and I've tried a bunch!) are all atrocious: false positives and false negatives galore. Perhaps I'm spoiled by LSPs from languages with better type systems. Our code is strewn with (to me) mysterious comments such as `# NOQA 1234` which my colleague uses to make his Python tooling work with the codebase. I'm used to languages like Elm or Gleam in which a LSP error means there is an actual problem with your code, and a lack of a LSP error means the code will compile and run.
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.
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
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.
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.
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.