“ 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.

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.

Sure, except there is a bit of history here, this isn't the first exchange, and I am not bothering to reply back as we aren't going to change opinion on C vs safer languages until we leave this realm.

Thus we can keep filling HN with pointless comments or move on.

There is plenty history of you repeating the same strawmans literally thousands of times. I've just never seen _anyone_ on HN (or elsewhere for that matter) make such claims?

Here goes again, better improve your Algolia search skills if you cannot find anyone else.

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.

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

"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?

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

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.

I never used it in practice, so maybe the support isn't that good, but I was under the impression that it was possible to pass custom allocators basically everywhere in the STL. See for example the definition of a vector here:

https://en.cppreference.com/cpp/container/vector

actually large programs that are persistent is where you really care. kernels and databases often use explicit allocators because there is so much policy wrapped up in allocation.

this goes back decades, its not just a feature of the 2020s. as a systems programmer I always want this, and the idea that allocator state should be completely hidden and implicit is shortsighted.

but yes, it is a bit onerous to pass around allocator(s). the real complaint that I have is that if 'malloc' is global and a compiler primitive, then we can do things like coalesce allocations and have compiler managed lifetimes when appropriate.

explicit allocators are an important lever, its not clear to me that we could never find a way to make them possible without the minor downsides.

But a lot of real world software just isn't that simple.

Zig doesn't force or even tends to prefer one way or another. If I want unassuming heap allocations that can be reclaimed in any order, there's an allocator for that. If I want an arena to discard at the end of something like a request or a video frame, there's an allocator for that. If I want to use a fixed backing buffer for the allocations, there's an allocator for that.

The point is that the standard library doesn't assume one or the other, which seems good if the problem is that "real world software just isn't that simple" in the more general sense that there's no one-size-fits-all allocation strategy.

Allocation happens. You can leave it to the compiler, the runtime, or let the code control it.

The automatic solutions are usually pretty good and usually the right place to start. But if performance is a priority, you want options.

BTW, “per-frame arena” is part of a general pattern of a repeated interval of work doing significant allocation. This is really common in software of all kinds… servers that process requests (like web servers and database servers) and typical command line tools.

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?

Meaningfulness comes from what you care about. I wonder why you were interested in programming-language concepts before but now (apparently) stopped caring about the code. The code still remains the language that communicates the actual program logic.

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.

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.

It still boggles my mind that golang hasnt introduced rust-style enums

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.

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.

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.

I'm skeptical, most human written code was and still is garbage and survives without major rewrites.

Would recommend learning how to use arena allocation. You would have patterns like:

fn run_query(alloc) {

   arena = init_arena(alloc);

   defer arena.deinit();

}

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.

I don't know about more error prone. Benchmarks completely aside, freeing a batch of stuff you've allocated in a single place makes it easier to manage memory. I think it should be preferred wherever it's an option for that reason most of all. The "killer app" is something like an arena allocator that lives for the duration of an HTTP request.

I meant to suggest using arena allocation for everything and not even using a malloc style allocator. Just getting memory via memmap at program start and then using arenas for everything after that.

It makes it much easier to avoid lifetime mistakes in my experience.

Using arena allocation also makes me think more about how much memory I am using and how much memory I should be using etc.

It is hard to benchmark it against just using a global allocator because it is a structural change to the whole codebase.

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 comptime crates out there. Crabtime is iirc the most mature and popular

I don't know if I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.

Certainly every new Rust release tends to have either new things which were stabilized as const on day one, or things which already existed but now have stable const.

The biggest constraint today on Rust's constant evaluation compared to where you'd expect is that trait implementations can't ever be constant, this obviously means you can't call SomeTrait::function in your constant, even if you can see the implementation of SomeTrait::function and if it were not a trait it'd obviously be constant -- but it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today.

I think we can expect that to get fixed in the relatively near future, but I'd have said that last year too so what do I know.

If you have C++ experience you'd probably want a lot more. C++ is allowed to allocate inside constant evaluation, and I believe in C++ 26 it's now even allowed to persist the allocation to runtime rather than being required to always clean up during compilation, so that's a much bigger set of crazy things you can do at compile time.

it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today.

Yep, that was my annoyance.

Const allocation is possible in Rust as an unstable feature. Not sure if you can persist it to runtime, though you can persist a reference which will become a static reference. I think it being unstable is why I needed `include_bytes!`.

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.

sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.

Traditional stuff in this space are:

* floating point differences between the build machine and the target. By far the most common

* endiannes - code assumes little median runs on big endian

There’s other more subtle issues that can crop up but those are the big two.

Not saying I agree though - those can happen anyway when you run on two different machines anyway.

I get it now. Important things but not things that I use often - hopefully addressed by 1.0.

I'm not sure there is something to be addressed. Zig has just a different approach and Zig people different expectations.

In Rust we can expand what is possible at compile time without breaking existing code because we took a very careful approach only stabilizing what we are sure about. Some things will probably never be possible at compile time in Rust.

Zig is much more powerful but that also means they cannot take stuff away without breaking existing code and making comptime more restricted. So it is unlikely Zig will ever become like Rust in that regard, but that is ok - just different approaches.

I think the Rust approach is incorrect - if the runtime behavior can change based on the machine that the code gets run on, why is it so important the build time behavior has such a restrictive definition? Especially considering build.rs can be used to bypass that definition anyway. It feels like a weird cut to make that I can’t figure out the understanding for. It feels like it inherited the const philosophy of c++11 without reexamining if it’s actually a good idea.

Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a lot of energy and thought went into the issue of producing identical output (and what identical precisely means ) even when compilation is on a different processor than where the target runs.

As far as I know this is not a concern for Zig comptime.

There will never be a true successor to C since C is "high level assembly." The lack of pointer 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#, Swift or Go.

Except Rust is actively being used in kernel space and low level embedded systems as well.

It's useful, but systems programming languages shouldn't be used to create applications in the first place.

We're trying to solve a problem that shouldn't be solved. We're continuing and even confirming the usage of systems programming languages for application development.

I don’t think this delineation is that clear, unless by “application” you mean the app tier of a 3 tier app.

Postgres and Nginx make sense in system programming languages; they’re extremely performance sensitive and that granular level of control offers them features. Interpreters are sort of the same, they interact with the OS a ton, it makes sense to work in the same language as the OS.

I do generally agree for the app tier of a web app. I wouldn’t build a CMS in Rust, but I also wouldn’t build a reverse proxy in Python.

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?)

Maybe I'm not that deep into programming, but I don't understand the hype about Zig?

I programmed in rust a bit and can't say I'm an expert, but in my view rust mostly-solved the memory management problem at compile time and without a GC, and it works very well. The biggest con and cost I've always seen repeated so far is that "it's slow to compile", and I get that, if you're past 250 crates the final --release link tends to become noticeable, but there were improvements to incremental compilation.

On the other hand - looking at the syntax from this post - Zig feels a blend of javascript, python and golang syntax that still requires memory management. So a nicer-written C that inherits all the issues from C? From the post: no functional programming, data mutation, memory leak, double-free, memory corruption.

Personally I'd rather trade a couple minutes of final link every time when this is the other option.

yeah to me zig exists as a counter-reaction to rust. which means avoiding both the good and bad things rust does. and rust does a lot of things right, so...

Rust is for devs who think "if only c++ had a few more features, it would be perfect". Zig is for devs who think "if only C had fewer features, it would be perfect"

ironically rust has fewer features than c++ and zig has more than c

Zig is aiming to be lower level than Rust. As the project homepage prominently advertises, it has no hidden memory allocation or control flow. It also gives more control over how memory is allocated, which is potentially useful in applications with particularly tight performance requirements.

Kelley first created Zig when hr was working on a digital audio workstation and found most existing languages to be awkward for working with particularly hard real time requirements, but still wanted something more modern than C. Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it. Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing.

it has no hidden memory allocation or control flow

Rust had like 3 allocating types total. If you aren't working with extremely deeply nested 3rd party types it's trivial to identify when allocations happen. Hell you could throw a lint rule together in like 5 minutes to warn on it if you're really worried. Besides Drop (excluding async) is there even any hidden control flow?

Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.

Rust has almost exactly the same semantics for controlling allocations and deallocations, it just prevents you from screwing it up and not freeing something or using the allocation after freeing it. You still have to pass around your reference in your call stack until you no longer need it.

Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing.

It's really not substantially different. You allocate ahead of time or don't allocate at all. The only real difference is you might want to use an Option instead of an uninitialized pointer because it's semantically more correct and harder to screw up.

But here I feel like we’re at risk of heading down the same old doom spiral that plagues any conversation about programming languages when people try to treat it as a competition: getting pedantic about what’s technically possible in a language. It’s much more interesting to talk about how a language wants to be used.

So, in the case of Zig, every function that wants to be able to allocate or deallocate heap memory needs an explicit reference to an allocator. That means that you can tell whether a function might allocate memory from its signature. It also means that changing a function so that it can allocate is explicitly a breaking change.

That’s a really interesting design decision. And the reasons why someone would or would not want something like that baked directly into the language are so much more interesting than bickering about how technically with proper discipline you can have that kind of control in any non-GC language.

Rust had like 3 allocating types total.

Seriously? Categories of types maybe, but literal types it's more than that.

Even closures allocate if they need to capture their environment.

Zig is aiming to be lower level than Rust.

Zig and Rust are equivalently "low level". Zig isn't any closer to the hardware than Rust is.

but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.

Rust gives you all this, too.

Zig's primary (possibly only) advantage over Rust is that it has much faster compilation times.

I don't understand the hype about Zig?

As a long-time low-level programmer, and as someone working on a popular mainstream language, I find Zig fascinating, and I also think it addresses a long-standing problem in low-level programming. I'll get to the problem later, but the fascinating part is its use of partial evaluation (comptime) as a single coherent mechanism that replaces a myriad of other partial-evaluation mechanisms (macros, templates/generics, constexprs). That one mechanism is the core of the language, like macros are in lisps, and that design - whether you like it or not - is revolutionary. It's never been done before (other languages have partial evaluation mechanisms that are almost as general, but they're offered in addition to, not as a replacement of, other features).

rust mostly-solved the memory management problem at compile time and without a GC

"Mostly" does a lot of work here because 1., if you look at the implementation of very efficient, possibly specialised data structures - the very thing you reach for a low-level language for - they typically require unsafe, and 2., it still suffers from the problem C++ has had for decades, which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower (huge runtimes like TCMalloc help, but not enough, because they can't move pointers). This problem, of programs that start out fast, but after five or ten years of evolution need to spend a lot of effort to remain fast, is one of the things moving collectors were designed to solve, but they require moving pointers, which doesn't work in low-level languages that are not meant to have an FFI layer between them and the hardware.

To compete with the performance of moving GCs, which allocate through bumping a pointer, like on the stack, and free memory in bulk, low-level languages need to rely on arenas (which work based on a similar principle), and Zig is the first language that makes arenas almost user-friendly and hopefully sufficiently composable to withstand program evolution. Of course, time will tell how well this works in practice.

the very thing you reach for a low-level language for - they typically require unsafe

There's a formal proof asserting that if you keep up the safety invariants within an unsafe region then that will not infect other code, even in the presence of arbitrary other correctly-written unsafe blocks.

This means you can build abstractions on top of these low-level primitives to keep it contained, so consumer code never has to even think about or know there's unsafe blocks in it. The type system lets you build very powerful abstractions so these go a long way.

There's a lot of woo-woo scare quoting around how much you actually have to use unsafe code in Rust. It's fairly uncommon to actually have to reach for them in practice. Most of my usage ends up being things like converting a &[u8] to a &str when I know it's already valid UTF-8 so I want to skip the linear-time validity check. Very rarely do I have to build data structures with complicated pointer juggling, because there's often a library that already does what I need!

which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower

What are you talking about? I've never encountered this and I've been using Rust for 10 years.

That's always been true in all the safe languages with unsafe escape hatches, except here these "primitives" are the main reason to reach for a low-level language in the first place - because they presumably require the control that low-level languages offer. Combining them in the same language might appeal to some and not to others who think that the high-level, safe parts are unnecessarily complicated because it needs to integrate with the low-level parts, and the low-level parts are unnecessarily complicated because they need to integrate with the safe parts. Anyway, some like this and some don't, but my point is that it's not "mostly solved".

What are you talking about? I've never encountered this and I've been using Rust for 10 years.

Okay, but I've been doing low-level programming professionally for 25 years, and have encountered this over and over in large programs (over 500KLOC) as they evolve.

That's just not an accurate description of how you write Rust in practice. There's no separate "high level" and "low level" parts/forms of the language any more than the software development process already is all about building abstractions. You should be doing this in Zig, too.

It's just that sometimes some of the abstractions you need to build go outside what the ownership and borrowing system can model. And when you don't need to do that (which is 99% of the time) you also get all the benefits of the ownership/borrow system for free.

> which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower

I think the idea is that a small program can organize its allocations and data structures to minimize number of calls to malloc, e.g. with preallocated workspace structs, or slab allocation, and similar approaches. But as a program gets bigger, there's a pressure to have looser coupling, to have subsystems with simple convenient APIs which leads to them doing on-demand malloc calls internally, rather than having consumers pre-allocate their needed workspace. Because that kind of workspace management results in more complex APIs and more burden on the consumer.

That said, I don't really believe it either, at least for the kind of codebase where it would matter (scientific computing, in-memory DB server, etc). A codebase that places an emphasis on minimizing heap operations in hot codepaths can do so by consistently using workspaces and allocation-avoiding APIs. I don't think it's so difficult really, but it does take a conscious design decision to do so. But writing something like a web browser in this way could be annoying due to most data having wildly variable sizes, and zig's arena concept would be very handy -- but rust has crates like bumpalo for that purpose.

My personal mantra: "Think in FORTRAN, code in Rust/Julia/C++". But I'm mostly working on HPC-style code where I don't have to do with wildly varying input or output sizes.

If you're writing ultra low latency code you basically want everything allocated from an arena, with different arenas for different kinds of objects. Zig comes with this built in, while Rust makes it extremely unergonomic to do safely (due to the lifetime system).

I'm honestly baffled why people are writing Zig or Rust and avoiding V. V (and now Bend) seems like the future to me.

One caveat worth stating up front

It would be nice if people would note that their posts are AI generated, and put that in the title here to make it easier to ignore

I'm not exactly sure what you mean, that seems like a pretty phrase to me, is it considered an LLMism now? Kinda feels like the same thing with the em-dashes; I can't use em anymore because people will then assume I'm an LLM, even though just a few years ago it was a perfectly normal thing to do.

It's entirely possible I'm just getting worse and worse at picking out LLM writing these days too, who knows.