this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence
it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees
edit:
> This brings me to my next reason: I have the discipline to write C at a high level.
factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.
I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe.
> you have a professional obligation to use a higher-level language, with stronger guarantees
Oh? So we have professional obligations now? For FOSS? News to me.
I don't get paid for my work. Not yet. So I have no obligation.
And when I do get paid, my code will be in my own safe language.
This accusatory response is exactly the kind of thing that puts a lot of people off Rust.
> factually, you do not. nobody does.
When I say "write C at a high level," I don't mean that I'm perfect. I mean that I write excellent C compared to all C programmers out there.
Engineering is not about perfection; it never was. It's about doing the best we can with the tools that we have.
[1]: https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...
Of course, feel free to judge for yourself.
I think the proof is in the pudding here. I can't imagine using a messaging client or an email client written in C, and also there isn't much that is written in C anymore even if I wanted to: you're looking at Swift/Java/Kotlin/TypeScript/JavaScript/C#/Vala/Dart/Rust/Go, and maybe C++.
Is anyone writing production servers in C these days? It feels like they're 100% Go and Rust.
There are notable exceptions, in particular I'm thinking about OpenBSD. I think OS dev is a pretty niche area though, especially when you're talking about OpenBSD's wide platform support, so I think it's more the exception that proves the rule than anything.
All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.
Much of the Rust compiler is written in Rust and so has fewer problems.
https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...
https://security.apple.com/blog/towards-the-next-generation-...
https://www.chromium.org/Home/chromium-security/memory-safet...
https://security.googleblog.com/2022/08/making-linux-kernel-...
Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)
So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.
Lets see how serious those developers get to be around security issues, when liability finally takes off.
the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale
at scale means across a broad demographic of programmers, working on a broad set of programs
if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity
strcpy and pointer arithmetic are basically not possible to get right
we need to move beyond this very low level of abstraction
It's not possible for human beings to write correct code.
The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘<’ that should have been ‘<=’. No language would have stopped that.
Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in Python, and you'll never OOM making an accidental copy in C.
yet c code is inarguably more error-prone than basically any other language
Of course, the errors that do get through might be more severe in C than in python, but not always.
After all, the most expensive and destructive RCE ever was in a piece of Java software.
In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.
If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.
Fuzzing is still not part of the default Rust tooling.
"it works" is factually not true, look at ~any CVE
In early 1980's it was only running Bell Lab's world and a couple of universities that got hold of the source tapes.
I agree that C the programming language does not help you avoid memory errors, however, saying it's impossible is too binary. People do make mistakes, whether it's copy editors missing a typo or professional chefs misremembering whether they stocked an ingredient. Projects written in C need longer periods of code review and testing, but they can be made right. The code that took us to the moon was written in assembly after all.
It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.
at scale, it is not possible for humans to hand-write C programs that are free of segmentation fault class errors
this is not controversial or in any way arguable
Inb4 you move the goalposts for "at scale". This is an operating system with capability-based access control which is not something that most operating systems even have.
Also the cryptographic constraints are part of the proof system.
It's all in a monorepo that has my "libc".
comptime just doesn't fit my brain well.
Async Zig gives me a headache. [1]
[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
https://youtu.be/lDfjdGva3NE?t=1999
Yielding is async and threaded is sync)
He claims that you can call functions fine in either mode if the functions are known at compile time. I never disputed that.
If he tried to call those functions with possibly unknowable function pointers at runtime, I doubt it would work as well.
There is a difference between compile time and runtime. At compile time, Zig can transform known functions to async to allow turn to call async functions. At runtime, that's not possible.
The 75 examples in my post show that.
I guess the question hinges on "just how hard" counts as "hard" for #3. I would say "not having to write an event loop because the compiler generates another version for the sync-calling-async with a single keyword" case counts as "not hard", but this is a matter of perspective. The language design still has rough edges, and you certainly ran into them, but with the function pointer stuff, I think you were really trying hard to break it to prove a specific point (this is a good thing! it will allow the team to fix it). To that point, they simply hadn't run into the specific runtime/comptime thing that you ran into, but it's pretty easy to see how exactly what you ran into can be addressed and fixed at comptime, it... just hasn't yet.
The Zig compiler would have to have perfect knowledge of all functions that can be called anywhere. At compile time. Alan Turing proved that this is impossible.
In other words, Zig cannot address it. Ever.
Say you're a library author. You distribute pre-built library files.
You've already lost because the compiler does not know your clients' code when it compiles your library.
I am not kidding when I say it's provably impossible.
Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out".
The Zig compiler is finite and deterministic, yes, but that's not the problem.
The problem is that user code is not finite nor deterministic.
Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1]
(In this context, the word "undecidable" used by that source means "uncomputable".)
If the type system is uncomputable, then the type system will never be able to resolve all uses of function pointers everywhere.
The whole point of the Halting Problem is that you could have a finite and deterministic Turing Machine that runs other Turing Machines, and that finite and deterministic Turing Machine could run into situation where it never halts.
I never say this when people ask (because most people don't understand), but the real reason I don't like Zig is because of how infinite the language is, starting with its uncomputable type system.
This makes Zig one of the most unreasonable [2] programming languages in existence.
If you don't believe me, ask the Zig team how they plan to solve this problem. Don't ask them if they plan to solve it; ask them how.
Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win.
But if they say they can't, will you believe them?
[1]: https://3fx.ch/typing-is-hard.html#zig
[2]: https://fsharpforfunandprofit.com/posts/is-your-language-unr...
The Zig compiler has a counter that describes the maximum allowed amount of branching that the compiler can do while evaluating comptime code. The counter can be manually set to a higher value but all compilations will eventually fail if your comptime logic is too loopy. In practice the guideline is to not overuse comptime and instead create a dedicated build step for things like creating pre-computed value tables.
> Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win.
cringe
Okay, here's a solution. It's already implemented. Nice.
Now let me destroy it.
You said those compilations "fail"; I presume there's an error that kicks in.
In that case, then some valid Zig programs will be rejected, but your type system is now not technically Turing-complete. It's also less powerful; there are going to be things that Zig's type system cannot express.
But wait; that's a user-defined setting? This means that either users will increase that setting when they need to and run into the same problem, or follow your guideline:
> In practice the guideline is to not overuse comptime and instead create a dedicated build step for things like creating pre-computed value tables.
It sounds like a dedicated build step would be the better option than comptime, to be honest.
Also, if you step out to dedicated build steps, then the compiler no longer has complete visibility into that code when analyzing. At that point, the Halting Problem applies again.
Also, what do you do if a user needs to pass a function pointer to a C function? I presume they must use a sync function? If so, that seems like a direct application of the function colors definition; some functions are unusable in certain places. If not, I'd be interested in what Zig does there.
I think you're a bit too high on all this compsci theory stuff.
All computations in all languages (including ones generally considered to be turing complete) fail when you run out of resources like RAM or patience. Zig introduces an artificial quantity that can be used as a machine-independent way to ensure all compilations eventually end in either success or failure. It's like a timeout, but an actual timeout would be inconsistent across different machines (with different performance characteristics).
The actual state of things is much more boring than what your analysis tries to suggest: comptime is used to do some metaprogramming whose practical value is in good part determined by it not being too crazy, so the fact that you can't make a DisprovesCollatzConjecture type is actually fine.
You have found another feature of Zig that's even more mundane than async where you're trying really hard to misunderstand everything to indulge in... "destroying".
I think your own wording betrays the fact that you care about needlessly debating people more than actually understanding the tools in front of you in order to produce better software.
I have an acquaintance who was trying to write a Zig compiler. Comptime was his bane.
If you think I care about "needlessly debating people more than actually understanding the tools in front of me," let me dispel that notion.
I was once a fan of Zig.
Yep. I was. I thought it was great and was even going to rewrite all of my monorepo in it.
And then I started studying it in detail, trying to understand it. It took a while, but I came to realize that Zig appears good and has flashy ideas, but that Andrew just didn't understand the consequences of his design decisions.
In other words, I spent time trying to understand Zig before I ever got these opinions.
To go back to the topic, sure the use of this may appear boring, but if tools have a hard time working with Zig code, so will people. That's my problem with it.
You are absolutely right that this is a "boring" part of Zig, but that doesn't mean it's good. It means that that's where complexity hides.
Once I figured that out, I realized that to make better software, it would be better for me to stick with C.
My wording, by the way, comes from a bit of exasperation because to me, it feels like you, Andrew, and the rest of the Zig team are reluctant to accept criticism or that Zig isn't perfect or even the best.
A program is defined to be invalid when it runs out of counters. Problem solved.
>Also, if you step out to dedicated build steps, then the compiler no longer has complete visibility into that code when analyzing.
You can't really "generate code" in these dedicated build steps. Kristoff is talking about generating data. you could maybe build an object file, but then it's bound in using c abi, statically, which we've already solved in this conversation.
>Also, what do you do if a user needs to pass a function pointer to a C function? I presume they must use a sync function? If so, that seems like a direct application of the function colors definition;
In the long run for zig, calling out to c abi, much less one which takes a function pointer, much less one which you happen to have as async, is going to be a rare enough operation that I think people aren't clamoring to go and use it, which fails one of the criteria for your function coloring list. Besides, you just quickly wrap it in noasync context and you're done (you can't pass a zig callconv function directly to a c abi callconv site without at least a tiny wrapper anyways).
Except that the counter can be adjusted by users.
> You can't really "generate code" in these dedicated build steps. Kristoff is talking about generating data. you could maybe build an object file, but then it's bound in using c abi, statically, which we've already solved in this conversation.
So any code generated outside has to be sync? That's exactly what I thought.
But even if Zig only allowed people to generate only data, this is a pretty big limitation.
This may not be a problem now, but it does mean that as Zig programs grow, people will run into this problem. I suspect that this means that Zig will struggle more than C to scale, maybe even more than C++ or Rust.
> In the long run for zig, calling out to c abi, much less one which takes a function pointer, much less one which you happen to have as async, is going to be a rare enough operation that I think people aren't clamoring to go and use it
This assumes that people won't want to interface with software that isn't in Zig. This is another way that Zig will struggle to scale.
> Besides, you just quickly wrap it in noasync context and you're done
This sounds exactly like a special calling technique mentioned in the function colors post.
> (you can't pass a zig callconv function directly to a c abi callconv site without at least a tiny wrapper anyways).
And this also sounds exactly like a special calling technique.
So? You've changed the program, and now it's valid. (as my handle suggests) I was a math major: arbitrarily large but finite is a different category than infinite, and that makes all the difference in the world.
> his sounds exactly like a special calling technique mentioned in the function colors post.
No, but the seam between async and sync in most other implementations requires writing an entire event loop. In this case it's often a single keyword, six characters. At worst, you write an extra function header to wrap it.
It's not the extraness that matters, it's the pain of doing so. Hell, even go requires you write "go" in front of your function to run it asynchronously, and I don't think that this counts as "colored functions".
Can you elaborate on what you mean here, and the problems this might cause? Do you mean that some function pointers cannot be resolved to concrete functions? Or that the process of evaluating comptime may be infinite? Or some other problem where the compiler can't determine whether a function pointer is needed for a given function?
All of the above, actually.
Turing-completeness and the uncomputability thereof are widespread, easy to build, hard to keep away, and affects everything that might happen at runtime.
A list of things that can happen is infinite, but that list absolutely includes:
* Whether a particular function pointer resolves to certain functions,
* Whether evaluating the comptime portion of a Zig program will take forever,
* Whether the compiler fails to exclude a particular function from being used as a function pointer at a particular place.
Turing-completeness is a wildly powerful property, but that power is not free; the inability to figure out what might happen in a program is only just the biggest and most apparent cost.
The problems this might cause can be summarized like this: you can never know what a program will do for a given set of inputs until you run the program on those inputs, and even then, you might never know if the program never halts.
Does that make sense?
This is only a turing completeness issue if the list of functions is infinite. It is not, in zig.
You cheat. You don't write C the hard way. But ok, that's an easier way to use C today.
I'm okay with cheating if it reduces bugs.
That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else.
I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize.
[1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...