“ The language is different from Rust (who could’ve thought that, yeah), but it left a genuinely good impression. It’s straightforward, modern, and blazingly fast. I believe it has real potential to become the true successor to C. On the other hand, it’s still young, and it shows: the shape of the language itself feels unfinished in places, and I suspect it’ll pick up more of the cooler quality-of-life features and syntax sugar as it matures.
As for me, I’d like to keep contributing to the ecosystem, and I will, whenever I come across a project worth building.”
Idk I don’t write either well enough to have a hand in this but losing out all of this for more
Imperative stuff seems like a step back.
“ No functional paradigm
Rust is technically an imperative language, but it draws heavily on functional concepts: zero-cost iterators, lazy evaluation, ADTs, pattern matching, monadic types, traits, closures, and so on. Having also spent time with Haskell and Erlang, I’ve become fairly inclined toward the functional style, and it shows in this library. It leans heavily on FP idioms:
Monadic error control via combinators like Queryable and related types
Monadic-style data types like Data<T> with map, flat_map, reduce, and friends
Pure, immutable transformations
Combinators over iterators instead of loops
Closures for local abstraction
Declarative macros as a small embedded DSL
Sum types and product types”
Modern and blazing fast, what we lost leaving behind languages like Modula-2 and Object Pascal, having newer generations to think C and C++ were the only compiled languages alternatives to scripting languages.
I miss the years of writing CLI tools, web servers and clients, in Ada (and of course, real-time complex distributed system...). Felt so simple and right and fast and robust. The code is still readable today and maintaining it is a zero effort today. Clean Java without the enterprise BS was a close second in ease of programming - boilerplate be damned.
I'm glad NVIDIA found a way to make GPUs programmable and got us out of the shaders tarpit, but did it have to be C++...
You repeating this weird strawman take a million times doesn't make it true. Why don't you finally just put out some genuinely interesting projects demonstrating how everybody was doing it wrong, so people can make up their own mind and finally be convinced. There must be some true magic in those languages and platforms you mention, that should offset the pain of writing in upper case and with super long KEYWORDs everywhere, and to offset the cost of switching to a culture that has way less mindshare and way less of a software ecosystem around it.
FWIW I've actually worked for 6 months on a large old Delphi project. It was some performance work that, as almost always, mainly required getting the language crap out of the way. In the end I got the job done (100x-1000x speedup) but I wouldn't want to switch back to this ecosystem: Licensing costs, weird language warts there too. A slow moving ecosystem. Ultimately, I just need something that does what I tell it to do, reliably and fast, and that doesn't get in the way.
I’m more than a bit out of my depth discussing the topic, but I’m not sure than imperative-dominant languages will ever really go away or that functional-dominant languages will ever become as popular as C and C++. Ugly as they may be, imperative languages seem to be grokked by humans more readily and are more often than not “good enough” for the most part so it’s difficult to see them losing substantial momentum.
Until there is a machine that is natively functional, there is always going to an incentive to go lower level for more performance.
Even hardware (GPUs) that functional language could trivially exploit, it’s still higher performance to write low level code and manages all the memory imperatively
I don’t see the point of letting an LLM generate an article when the topic is your personal, subjective experience which only you, a human, would be able to express.
Not OP, but I think the leading and trailing paragraphs were mostly human-written (and nice to read), but the memory leak example cases had a very different flavor of prose and code comments that smelled very Claude-y to me
It's unfortunate, but to come across as genuine now I think you have to actively avoid AI-isms.
In this case it feels AI generated with human polish, or vice versa. A couple tells are "One caveat worth stating up front..." and of course, "...the shape of the language itself...".
So anything that has em dashes is now considered LLM generated?
Is that what they said? If that's not what they said, why are you putting words in their mouth in an attempt to weaken their statement into some completely ridiculous stupid strawman that is obviously not actually what they said?
That’s the first thing others point to being LLM-generated. If you see, right after the phrase you quote, there is a question as to what else OP thinks is LLM-generated. I didn’t put words into anyones mouth
The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it.
I think when we're looking back on the 2020s we'll be struck by the Allocator obsession
All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.
For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.
But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
AAA games use allocators extensively, and they are more complex pieces of software with higher performance requirements than nearly anything else out there. So I'm not sure what toy problems you're talking about.
Allocators have been in wide use long before the 2020s but I agree there does seem to be a resurgent interest lately. Although I would argue it's part of a more broad trend of focusing data driven design. Which makes sense because accessing main memory is one of the slowest things your program can do.
And those games do so in a language (C++) where allocators is not a headline feature, and is barely even supported at all in the standard library.
The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
They do, but not necessarily together with generic, standard containers.
When you find yourself wanting a nonstandard allocator, you usually want it because you want it to have some interesting property. It's not necessarily trivial to fit that into the interface of something like `std::vector`, or `std::unordered_map`, etc.
Here's my take as a game developer: 99% of use cases for custom allocators are scratch allocators for doing stuff within a frame. 95% of those are much easier to serve by just amortizing allocations by storing things in an `std::vector` (or equivalent) that gets cleared every frame. You can use linear storage to back many interesting data structures, including queues, ring buffers, priority queues, binary heaps, etc., and that's more than enough for a large number of systems in a game.
The overwhelming majority of the time, more complex data structures (like hash maps etc.) have a longer lifetime than the current frame, because the whole point of using them in the first place is to amortize lookup time across frames.
Off topic, but I remember fondly the pre-LLM days when I used to love reading about programming languages. I never got a chance to professionally work with Rust, but made some cool hobby projects with it. Would have eventually tried out zig too.
Now it all feels so pointless though. Like memorizing rules to do mental arithmetic. Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.
I think (for now), it is still relevant. A language is an abstraction, and a good abstraction, like a good LLM harness, can be quite valuable.
Let’s say I’m writing some concurrent code with an LLM. I’d probably feel much safer having it write Rust, rather than C. So even in a post-LLM world, languages will continue to evolve as long as abstractions can be improved.
But do you still have enthusiasm for finding out about new language features or concepts? I'll do what it takes to get the job done, but the passion for it is totally gone.
Yes, as an example structured concurrency in Java (final release in Java 28 perhaps). I think that could totally change how we write concurrent code in that language.
I just upgraded a less important service to Java 27, a few days after its release (several nice features). It's cool how easy it is to upgrade nowadays.
That an agent writes most of the code doesn't mean anything to me here.
My examples are Java because that is the main language where I work.
You're welcome. I now feel inspired to try to change your mind, if you don't mind.
I would argue that "concepts" actually are more important than ever. Let's take my structured concurrency example. It doesn't matter here exactly what is, but if it ends up being as important as I think it will be, I likely want to write most concurrent code that way going forward.
However, it will likely be years until agents go to it unless deliberately steered in that direction. And if I want to make agents write it, I need to review it, and if I'm going to review, I need to understand it.
I think this is why I'm not pessimistic about the profession, it still feels like what I'm doing and learning matters.
There's a couple of languages I follow their roadmap and I find exciting, including Java and C#. I don't feel there's proper justification of writing backend services in something like python or ruby anymore, for example.
I used Rust extensively pre-LLM, and I'm much happier to serialize my thoughts to Rust than any other language.
I prefer to prototype in Golang since it compiles fast and makes for quick iteration, but at the end I ask the LLM to port the Golang to Rust.
Nice Rust enums for APIs are the chef's kiss.
I absolutely will not write anything in Python or scripting languages anymore. They're too brittle and don't have great devex or deployment stories. Especially when you can just as easily build in a typesafe language with good error handling that compiles down to a single static binary.
Yep, my point tho is more sentimental than technical. Let the LLM figure out the language details and just manage the output and deployment. It's ... not fun
I was thinking about that too recently. We have a new service that we’re trying to publish an SDK for. I don’t like the SDK that was created and kept nitpicking about how verbose certain things are and how “unergonomic” it feels (long tedious type names, annoying redundant constructs, etc) But then I was wondering if for a brand new service/SDK if anyone cares anymore and how much fuss i should be making about that.
For years I used Rust as my hobby-programming language and loved it greatly. I never managed to land a job working with it full-time, because either the work was too niche or it didn't pay enough, or I was simply too comfortable where I was to change. And now that I finally have enough discretion over my technology choices to run a "proper" project using whatever tools and languages I want, it is not me but the AI that writes all of the code.
There's a part of me that feels a quite sad about all this. It's almost as if there actually all along existed a real final deadline on finding that "dream job". And I missed it. And while I expect this one miss to be just a small piece in the grand picture of things that we're going to lose or have already lost to the zeitgeist of agentic SWE, it feels big to me. It was my professional dream, while I still had professional dreams.
Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.
Programming and learning new things can still be fun in the era of agentic coding.
With LLMs, I get to quicky ask: what would this look like? Why do it that way? If you suspect that the LLM isn't doing it the right way, you can still investigate that yourself.
e.g. the other day, https://rhombus-lang.org/ was mentioned on HN. With LLMs, the cost for trying this out is practically much lower.
Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.
In 5-10 years, the people who have paid attention to these will be needed to bail us out of the mess that the rest of the slop-addled monke brains have created.
Step zero of using arena allocation is to build realistic benchmarks so you can measure if it's worth the trouble in the first place. Standard allocators are incredibly good these days, and even plugging in mimalloc or jemalloc will be much less work, and much less error prone.
1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind.
2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.
Zig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days.
For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.
There will never be a true successor to C since C is "high level assembly." The lack of error checking, unsafe casts and non-existent bounds checking aren't an oversight but by design! Assembly doesn't have them so neither does C! There's no reason to whine about it.
The real problem is that people are using C for the wrong reasons. C is for the development of operating systems and low-level code, not applications.
Zig is more modern but anything that does even one iota more of hand-holding or has anything that looks like a guardrail fails the test.
If you want to write applications use Pascal, Java, C# or Rust.
For various purposes I work on a language comparison project that includes C and candidate successors such as Go, Zig. One question is the language to use for an archival port of a 1980's computer algebra system written in 32-bit K&R C. While Zig is a great debugging compiler, it's not yet stable enough to be the best target language for archival purposes.
So you're in a restaurant where you don't speak the language, you can't read the menu, but you see three price points for set meals featuring the house specialty. (Say, "Crossing the Bridge" noodles in Yunnan.) Which do you choose? My tour guide, the author Fuchsia Dunlop, later agreed with me this is obvious: The middle choice.
So you're choosing between Go and C23 as candidate successors to K&R C. They both have "royal blood". One got the name. Knowing nothing more, which do you choose?
The answer is equally obvious. The one that got the name also got the warts.
One of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true.
The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it."
You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator).
That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language.
“ The language is different from Rust (who could’ve thought that, yeah), but it left a genuinely good impression. It’s straightforward, modern, and blazingly fast. I believe it has real potential to become the true successor to C. On the other hand, it’s still young, and it shows: the shape of the language itself feels unfinished in places, and I suspect it’ll pick up more of the cooler quality-of-life features and syntax sugar as it matures.
As for me, I’d like to keep contributing to the ecosystem, and I will, whenever I come across a project worth building.”
Idk I don’t write either well enough to have a hand in this but losing out all of this for more Imperative stuff seems like a step back.
“ No functional paradigm
Rust is technically an imperative language, but it draws heavily on functional concepts: zero-cost iterators, lazy evaluation, ADTs, pattern matching, monadic types, traits, closures, and so on. Having also spent time with Haskell and Erlang, I’ve become fairly inclined toward the functional style, and it shows in this library. It leans heavily on FP idioms:
Monadic error control via combinators like Queryable and related types Monadic-style data types like Data<T> with map, flat_map, reduce, and friends Pure, immutable transformations Combinators over iterators instead of loops Closures for local abstraction Declarative macros as a small embedded DSL Sum types and product types”
I would say Rust is a functional language that has been hammered into the shape of C++. It also draws heavily on ML.
I get why, and it makes it a better fit for its obvious “C++ reimagined, cleaner, and better” niche.
Modern and blazing fast, what we lost leaving behind languages like Modula-2 and Object Pascal, having newer generations to think C and C++ were the only compiled languages alternatives to scripting languages.
I miss the years of writing CLI tools, web servers and clients, in Ada (and of course, real-time complex distributed system...). Felt so simple and right and fast and robust. The code is still readable today and maintaining it is a zero effort today. Clean Java without the enterprise BS was a close second in ease of programming - boilerplate be damned.
I'm glad NVIDIA found a way to make GPUs programmable and got us out of the shaders tarpit, but did it have to be C++...
Also a good one.
You repeating this weird strawman take a million times doesn't make it true. Why don't you finally just put out some genuinely interesting projects demonstrating how everybody was doing it wrong, so people can make up their own mind and finally be convinced. There must be some true magic in those languages and platforms you mention, that should offset the pain of writing in upper case and with super long KEYWORDs everywhere, and to offset the cost of switching to a culture that has way less mindshare and way less of a software ecosystem around it.
FWIW I've actually worked for 6 months on a large old Delphi project. It was some performance work that, as almost always, mainly required getting the language crap out of the way. In the end I got the job done (100x-1000x speedup) but I wouldn't want to switch back to this ecosystem: Licensing costs, weird language warts there too. A slow moving ecosystem. Ultimately, I just need something that does what I tell it to do, reliably and fast, and that doesn't get in the way.
If you don't like, press PgDn.
People should reply on Hacker News. If you disagree with someone's opinion and you have reasons for doing so then the right thing to do is share them.
I’m more than a bit out of my depth discussing the topic, but I’m not sure than imperative-dominant languages will ever really go away or that functional-dominant languages will ever become as popular as C and C++. Ugly as they may be, imperative languages seem to be grokked by humans more readily and are more often than not “good enough” for the most part so it’s difficult to see them losing substantial momentum.
Until there is a machine that is natively functional, there is always going to an incentive to go lower level for more performance.
Even hardware (GPUs) that functional language could trivially exploit, it’s still higher performance to write low level code and manages all the memory imperatively
I don’t see the point of letting an LLM generate an article when the topic is your personal, subjective experience which only you, a human, would be able to express.
So anything that has em dashes is now considered LLM generated? What made you think this is generated?
Not OP, but I think the leading and trailing paragraphs were mostly human-written (and nice to read), but the memory leak example cases had a very different flavor of prose and code comments that smelled very Claude-y to me
After going over that section again I can see it now.
"It's young, and it shows"
"Holds up"
"not a toy, but not a sprawling project either, and ideally.."
"And that’s the trap"
ctrl F "real" -> 6 usages
ctrl F "genuine" -> 4 usages
Are these obvious signs of AI generation?
Each one makes me update my estimate slightly in favour of AI. Also, pangram agrees.
Yes.
A number of "<assertion>: <followup>" patterns too which is pretty common of at least Claude.
It's unfortunate, but to come across as genuine now I think you have to actively avoid AI-isms.
In this case it feels AI generated with human polish, or vice versa. A couple tells are "One caveat worth stating up front..." and of course, "...the shape of the language itself...".
Is that what they said? If that's not what they said, why are you putting words in their mouth in an attempt to weaken their statement into some completely ridiculous stupid strawman that is obviously not actually what they said?
That’s the first thing others point to being LLM-generated. If you see, right after the phrase you quote, there is a question as to what else OP thinks is LLM-generated. I didn’t put words into anyones mouth
"And honestly"
It kind of says so at the bottom:
The implication seems to be "light editing", but the LLM styling really comes through, so I guess that tracks.
I would have completely expected that.
I think when we're looking back on the 2020s we'll be struck by the Allocator obsession
All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.
For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.
But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
AAA games use allocators extensively, and they are more complex pieces of software with higher performance requirements than nearly anything else out there. So I'm not sure what toy problems you're talking about.
Allocators have been in wide use long before the 2020s but I agree there does seem to be a resurgent interest lately. Although I would argue it's part of a more broad trend of focusing data driven design. Which makes sense because accessing main memory is one of the slowest things your program can do.
And those games do so in a language (C++) where allocators is not a headline feature, and is barely even supported at all in the standard library.
The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
They do, but not necessarily together with generic, standard containers.
When you find yourself wanting a nonstandard allocator, you usually want it because you want it to have some interesting property. It's not necessarily trivial to fit that into the interface of something like `std::vector`, or `std::unordered_map`, etc.
Here's my take as a game developer: 99% of use cases for custom allocators are scratch allocators for doing stuff within a frame. 95% of those are much easier to serve by just amortizing allocations by storing things in an `std::vector` (or equivalent) that gets cleared every frame. You can use linear storage to back many interesting data structures, including queues, ring buffers, priority queues, binary heaps, etc., and that's more than enough for a large number of systems in a game.
The overwhelming majority of the time, more complex data structures (like hash maps etc.) have a longer lifetime than the current frame, because the whole point of using them in the first place is to amortize lookup time across frames.
Off topic, but I remember fondly the pre-LLM days when I used to love reading about programming languages. I never got a chance to professionally work with Rust, but made some cool hobby projects with it. Would have eventually tried out zig too.
Now it all feels so pointless though. Like memorizing rules to do mental arithmetic. Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.
I think (for now), it is still relevant. A language is an abstraction, and a good abstraction, like a good LLM harness, can be quite valuable.
Let’s say I’m writing some concurrent code with an LLM. I’d probably feel much safer having it write Rust, rather than C. So even in a post-LLM world, languages will continue to evolve as long as abstractions can be improved.
But do you still have enthusiasm for finding out about new language features or concepts? I'll do what it takes to get the job done, but the passion for it is totally gone.
nothing stopping you to code manually
Nothing stopping me from doing a lot of things. But is there any point to it?
Yes, as an example structured concurrency in Java (final release in Java 28 perhaps). I think that could totally change how we write concurrent code in that language.
I just upgraded a less important service to Java 27, a few days after its release (several nice features). It's cool how easy it is to upgrade nowadays.
That an agent writes most of the code doesn't mean anything to me here.
My examples are Java because that is the main language where I work.
Thanks for the perspective.
You're welcome. I now feel inspired to try to change your mind, if you don't mind.
I would argue that "concepts" actually are more important than ever. Let's take my structured concurrency example. It doesn't matter here exactly what is, but if it ends up being as important as I think it will be, I likely want to write most concurrent code that way going forward.
However, it will likely be years until agents go to it unless deliberately steered in that direction. And if I want to make agents write it, I need to review it, and if I'm going to review, I need to understand it.
I think this is why I'm not pessimistic about the profession, it still feels like what I'm doing and learning matters.
There's a couple of languages I follow their roadmap and I find exciting, including Java and C#. I don't feel there's proper justification of writing backend services in something like python or ruby anymore, for example.
I used Rust extensively pre-LLM, and I'm much happier to serialize my thoughts to Rust than any other language.
I prefer to prototype in Golang since it compiles fast and makes for quick iteration, but at the end I ask the LLM to port the Golang to Rust.
Nice Rust enums for APIs are the chef's kiss.
I absolutely will not write anything in Python or scripting languages anymore. They're too brittle and don't have great devex or deployment stories. Especially when you can just as easily build in a typesafe language with good error handling that compiles down to a single static binary.
Yep, my point tho is more sentimental than technical. Let the LLM figure out the language details and just manage the output and deployment. It's ... not fun
It still boggles my mind that golang hasnt introduced rust-style enums
After reading many comments from its original authors, it's not surprising.
I was thinking about that too recently. We have a new service that we’re trying to publish an SDK for. I don’t like the SDK that was created and kept nitpicking about how verbose certain things are and how “unergonomic” it feels (long tedious type names, annoying redundant constructs, etc) But then I was wondering if for a brand new service/SDK if anyone cares anymore and how much fuss i should be making about that.
Exactly, hard to see why any of this matters anymore.
I relate to this.
For years I used Rust as my hobby-programming language and loved it greatly. I never managed to land a job working with it full-time, because either the work was too niche or it didn't pay enough, or I was simply too comfortable where I was to change. And now that I finally have enough discretion over my technology choices to run a "proper" project using whatever tools and languages I want, it is not me but the AI that writes all of the code.
There's a part of me that feels a quite sad about all this. It's almost as if there actually all along existed a real final deadline on finding that "dream job". And I missed it. And while I expect this one miss to be just a small piece in the grand picture of things that we're going to lose or have already lost to the zeitgeist of agentic SWE, it feels big to me. It was my professional dream, while I still had professional dreams.
Programming and learning new things can still be fun in the era of agentic coding.
With LLMs, I get to quicky ask: what would this look like? Why do it that way? If you suspect that the LLM isn't doing it the right way, you can still investigate that yourself.
e.g. the other day, https://rhombus-lang.org/ was mentioned on HN. With LLMs, the cost for trying this out is practically much lower.
In 5-10 years, the people who have paid attention to these will be needed to bail us out of the mess that the rest of the slop-addled monke brains have created.
Would recommend learning how to use arena allocation. You would have patterns like:
fn run_query(alloc) {
Step zero of using arena allocation is to build realistic benchmarks so you can measure if it's worth the trouble in the first place. Standard allocators are incredibly good these days, and even plugging in mimalloc or jemalloc will be much less work, and much less error prone.
Two additional points:
1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind.
2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.
Zig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days.
For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.
There’s a few compute crates out there. Crabtime is iirc the most mature and popular
I don't think I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.
Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?
I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.
And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
Detailed in depth look at Zig Vs Rust (also ... Vs Go)
https://gist.github.com/corporatepiyush/5382d79192be9737cf3b...
There will never be a true successor to C since C is "high level assembly." The lack of error checking, unsafe casts and non-existent bounds checking aren't an oversight but by design! Assembly doesn't have them so neither does C! There's no reason to whine about it.
The real problem is that people are using C for the wrong reasons. C is for the development of operating systems and low-level code, not applications.
Zig is more modern but anything that does even one iota more of hand-holding or has anything that looks like a guardrail fails the test.
If you want to write applications use Pascal, Java, C# or Rust.
For various purposes I work on a language comparison project that includes C and candidate successors such as Go, Zig. One question is the language to use for an archival port of a 1980's computer algebra system written in 32-bit K&R C. While Zig is a great debugging compiler, it's not yet stable enough to be the best target language for archival purposes.
https://github.com/Syzygies/Compare
So you're in a restaurant where you don't speak the language, you can't read the menu, but you see three price points for set meals featuring the house specialty. (Say, "Crossing the Bridge" noodles in Yunnan.) Which do you choose? My tour guide, the author Fuchsia Dunlop, later agreed with me this is obvious: The middle choice.
So you're choosing between Go and C23 as candidate successors to K&R C. They both have "royal blood". One got the name. Knowing nothing more, which do you choose?
The answer is equally obvious. The one that got the name also got the warts.
One of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true.
The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it."
You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator).
That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language.
(Also, what do monads have to do with it?)