> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.

That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.

▲

maxbond 4 hours ago | parent [-]

Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.

▲

joe-user 3 hours ago | parent | next [-]

I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.

CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.

In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.

So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).

* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.

	▲	josephg an hour ago \| parent \| next [-]
		> I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC) Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc). I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go. The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.
	▲	maxbond 3 hours ago \| parent \| prev [-]
		Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.

▲

zozbot234 4 hours ago | parent | prev [-]

Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.