This quote is attributed to Oscar Wilde, but it seems like he never said it. In fact, there is no direct source for this particular quote by anyone. Even the shorter version "Imitation is the greatest form of lattery" is much older than Oscar Wilde. The full quote apparently did not appear on the internet before 2012.
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.
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.
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.
Araq the Nim creator is working on a rewrite of the Nim compiler called Nimony that'll become Nim 3.
It's making fast progress and will provide the basis for a proper LSP! Nimony already supports incremental compilation and parallel which are key pieces for good fast LSP.
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
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.
I don't think performance has got much to do with tinkering. IMO the real benefit of Zig is you get the flexibility of C with the ergonomics of a modern language.
I like Python as a tool language, and I am very impressed by projects like Micropython, but you always eventually run into a wall. I.e. you are never going to write a compute shader in python, but I assume someone is going to try.
I think the programmer should meet the hardware in the middle, and Python has a few too many layers of indirection to do this well.
> I don't think performance has got much to do with tinkering.
Yes, in general, but also there are cases when you realize you can, idk, parse a CSV file in 0.2 seconds instead of 200 seconds. That kind of improvement unlocks a new level of tinkering.
In my experience, this (for now) is mostly aspirational. It's obviously a major goal, and there are clear milestones outlined on how to achieve it, but in practice the initial compile of an empty project or the excruciating pause when you `direnv allow` and ZLS needs to be (re)built are not what I'd describe as "terrific".
What, you wouldn't want a condescending lecture on which exact, unpopular even at the time, languages from the 80's, which had 10% of features of Zig and ran 20x slower, also had fast compilation times? For the 1000th time? Shame on you.
> Can someone explain why it sounds like there's such rapid growth of Bun?
In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno.
Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.
Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
In my area it feels like it’s competing against go which is a language purposefully designed for the thing we’re building and has a great tool chain already. I never really wanted JavaScript. It’s not a very thoughtfully designed language and the not very good design was made for the browser. I just used node because it was simple to get it working. And you have bun and things like that competing for the space too
> It’s not a very thoughtfully designed language...
This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew up, learned JS, and have solid careers working in it since that time.
The ECMAScript we have today, and the Typescript extensions of it, is one of the most robust, best performing, intentionally designed dynamic scripting languages on the market. It helps that every major tech corporation in the world has gobs of the stuff bearing loads somewhere in their organizations; they invest massively in making sure it's pretty good.
Before any pedant comes in to post the "Wat" talk, no, JavaScript is not a perfect language. While I personally prefer strictly typed JIT language to it, I still write a lot of it, might even be most of what I write. JavaScript today is as good of a design of a dynamic scripting language as you will find.
The recent npm supply chain attacks relied on lifecycle scripts, which Deno doesn't run by default, but neither do pnpm or Bun. While Deno, like npm, supports a minimum release age, it doesn't enable it by default.
well deno has 'allow-read' 'allow-write' kind of permission, so if something tries to read from my ~/.ssh or other important folder, it can just block it
even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it
the problem was at the start of deno, it didn't integrate with npm; the same way Macintosh used to be free of virus and trojan horses was because people just didn't use it enough.
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
There are still some points of friction, but I'm content with it otherwise. The problems Deno resolves for me far outweigh the problems it introduces these days. I think the inflection point was roughly a year ago for me. Prior to that I really wanted to love it, but I ran into too many issues with the tooling I used most often. It was pretty frustrating. These days I rarely encounter anything at all, and I miss it a lot when I use other runtimes.
Bun simplified the pain with the ecosystem switch to esm. deno, at the time, made it worse by doing stuff with url based packages that didn’t fully catch on
Deno originally was not Node compatible at all, and required you to do everything in a Deno way:
- Deno plugin in editor, otherwise types dont work
- All imports via absolute URL, like Golang
- No backwards compatibility, so no existing code worked.
Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.
Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).
tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects
if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...
I should check actual perf numbers... well next week or month?
Tigerbeetle is in the database business. They operate on an entire different level of correctness expectations compared to something like Bun. The correctness guarantees they provide come first and foremost from the design, architecture and rigorous testing, not from the language they use for the implementation.
So, hopefully, the tech people involved in choosing a database for their project understand that, and do their own correctness and performance testing before making a decision. As for the business people, the tigerbeetle.com landing page doesn't mention Zig at all, although it probably will come up when they "ask AI" for a comparison. So, yeah, probably some risk. Perhaps the LLM will also point out the Jepsen report on Tigerbeetle to offset it.
> not from the language they use for the implementation.
Everybody has a plan until their compiler compiles an if-else wrong, and that's the level of instability that Zig had when I left it and Tigerbeetle committed to it.
No amount of testing is going to save you from that and it's a completely avoidable unnecessary self-inflicted problem, as a technical person that makes me seriously doubt every other decision you make on top of that. So I feel like they've already been fighting an uphill battle, where they have to proof that they have a stable system, despite an unconventional early stage foundation, and I feel like that it just got even harder.
Im learning zig for kernel bypass packet work. Aside from some noise, and one bug filed on cross compliation (prob simple to fix) bug, it works like I expect. Export of zig code to clib works fine. Comptime is great. Compile time superb. Like TB I will import no other modules ... and avoid all async.
But this link has got me concerned. When I get more ibverbs work done ill see how good/bad it is in rust.
In this kind of extremely low latency high throughput work there is hardly any (mostly none) MT data structures. Memory is pre-allocated for one pinned thread. Atomics are not much used either. So rust isn't going to help on design much. But I think rust/c interoperability is worse than zig.
In fairness to zig many of these issues were closed when zig 0.16.0 was released, which is what im using.
As for your list of grievances, they all seem to boil down to the respective LSPs not doing their job? Does Ctrl-Alt-l (lowercase L, not Shift+i) include the language's server in the context menu, and are there any errors reported for it if it does?
Hehe, why "probably"? It says "250 lines" right there in the subject. Surely one can skim the single file of code (https://github.com/ieviev/mini-gzip/blob/main/src/main.rs) and offer criticism that isn't based on hypotheticals?
Anyway, I skimmed the file for you this time, and basically you're either correct or wrong, depending on your definition of "error checking." The code handles error conditions by aborting the process. Seeing as it's a standalone CLI program and not a library meant for reuse, safely shutting down with a meaningful message sounds like fair game to me.
I once witnessed a local admonish another (younger) local for exactly that at a bar. He replied with a bratty "Not my fault they're using crappy chopsticks..."
"... that mediocrity can pay to greatness" is the rest of the quote.