> The performance drop and specially the GC of Fil-C do limit the usage however. I read there are some ideas for Fil-C without GC; I would love to hear more about that!

I love how people assume that the GC is the reason for Fil-C being slower than C and that somehow, if it didn't have a GC, it wouldn't be slower.

Fil-C is slower than C because of InvisiCaps. https://fil-c.org/invisicaps

The GC is is crazy fast and fully concurrent/parallel. https://fil-c.org/fugc

Removing the GC is likely to make Fil-C slower, not faster.

▲

thomasmg 2 days ago | parent [-]

Well I didn't mean GC is the reason for Fil-C being slower. I mean the performance drop of Fil-C (as described in the article) limits the usage, and the GC (independently) limits the usage.

I understand raw speed (of the main thread) of Fil-C can be faster with tracing GC than Fil-C without. But I think there's a limit on how fast and memory efficient Fil-C can get, given it necessarily has to do a lot of things at runtime, versus compile time. Energy usage, and memory usage or a programming language that uses a tracing GC is higher than one without. At least, if memory management logic can be done at compile time.

For Fil-C, a lot of the memory management logic, and checks, necessarily needs to happen at runtime. Unless if the code is annotated somehow, but then it wouldn't be pure C any longer.

	▲	dfawcus 2 days ago \| parent [-]
		I wonder if some of the Apple provided Clang annotations for bounds checking can be combined with Fil-C? That then may allow for some of the uses to be statically optimised away, i.e. by annotating pointers upon which arithmetic is not allowed. The Fil-C capability mechanisms for trapping double-free, and use-after free would probably have to be retained, but maybe it could optimise some uses?