Honestly, it gets tiresome and adds nothing useful to all these posts. And since those drive-by missionaries aren’t spreading the good word of ocaml/java/go/haskell but Rust - well, then eventually you tire of the Rust community. It has a missionary/redemption problem.

The US needs military bases, it needs general market access, it wants to sell military equipment and so on and so on. The US is already being reckless with the relationship and diversification is underway, but how deep the split will be is in large part determined by how the US wants to behave going forward.

It's like a divorce, there aren't really any winners here (in terms of wealth, assets, ...). So it's a tightrope both need to walk, balancing each other's interests.

One wonders how many times that trick can be used. In fact, no need to wonder. Look around, the EU is busily spinning up arms industries, alternative payment platforms and expanding trade agreements with nearly everyone else.

Yes. The US can try. But while we haven't filed for divorce yet, we are definitely looking elsewhere.

So. Rust evangelists ? :)

But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior.

Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting.

Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.

For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.

I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.

That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.

It was/is fine :) I still got a segfault bug though hehe.

Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.

- any GC'ed language can manage memory for you if you want

- My first rust project (a gui app in GTK) managed to segfault just fine in spite of Rust (no unsafe blocks on my part, not deliberately trying to break anything).

- I think the state of computer security has moved on still, we now rely on LLMs armed with various tools to pick apart and try to break our code AND to generate our code -- it is not at all obvious to me that banging your head against the borrow checker is a worthwhile tradeoff in this new world.

I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.

Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.

If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.

That said. You asked about C, which I use for my job. Most every large C code base end up abandoning the stdlib (such as it is) and inventing their own. Since they do, we aren’t as hurt by abandoning it as you would be in e.g. Rust - the rust stdlib is useful, the C stdlib is.. not great.

Once you abandon the stdlib, a likely first stop is writing your own routines for allocating and freeing memory. There are different approaches here, from glib’s or sqlite’s alloc and free routines to people writing an allocator abstraction (basically a struct with a vtable for allocating/realloc/free) and when you build your own “stdlib” around this abstraction, you are fine.

As for why you may want arenas vs other allocation strategies, that again deals with how often you are comfortable going across the user-space/kernel boundary and how clever you can be with your allocations or how much internal fragmentation you can accept.

As with all other stuff, it depends. But arenas are often great when you can assert that a series of objects share the same lifetime (death time, rather). In these cases, your amortize the syscall cost, have nearly no additional work to manage the memory (contrast to e.g. the complexity of jemalloc) and can free a series of objects in constant time.

My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to.

Eg, ask for lots of memory, manage with arenas.

Interestingly Odin and Zig both lean into this heavily. Rust went a different route but has tried later to bolt on pluggable allocators.

Never bought into rust (have studied, have a (mostly AI-generated app in rust).

Wrote some Zig but Odin is even less overhead for me. I first loved Zigs built-in build system but having tried to wrap/use C libraries from both, I must say I prefer Odin. Wrapping some sqlite 3 API’s for my first little Odin program - just because I need so little of the API that it seems easier this way - and speaking to C from Odin is a pleasure.

That is, imho, where Rust fails the most - the second part is the C++’ish approach to memory management (RAII) - that’s not how systems programming or games (I’m told) tend to work.

To each their own. I had some fun with Rust too, but for me, Odin seems the most appealing :)

What does it contribute? I can read and discern this for myself, I can then stop reading or decide I don’t care.

Seriously, at some point all you “ai writing sleuths” should just get your own discussion thread together. It’s been months of this , we get it already.

(Not directly just at you, but anyone who feels the need to drop these comments in every thread)

But abject exploitation? Sex slave, even? I should hope we can find a little decency within ourselves..

Point being; I don’t think that is any different really from Europe. If they can manage, so can we.

:)

Wrt Linus - who knows? It is irrelevant; he is largely irrelevant. If he got ran over by a bus, the collective community (of whom quite a few are outside the US) will carry on.

I know most Americans are fed a steady diet of “evil China” and China MAY have issues. But on the AI front they are heaps better. Even if everything got closed tomorrow, we have a plethora of good models we can inspect and tweak while from the US labs we have… a single old 120b model ?

And with the way the US is treating its allies, maybe a bunch of us are quite content with a more even match rather than US hegemony.