Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.
Introduce a memory safe compilation mode inspired by Fil-C
21–30 of 49 posts
Re: Introduce a memory safe compilation mode inspired by Fil-C
#22Zig main dev proposes to introduce a Fil-C like compilation mode to make zig safe: it's only natural to mention how that's different from Rust, right? What about all the other languages, Andrew? I'm tired to see zig head people trying to diss Rust whenever they can. It's annoying for people that enjoy both languages and it's really a hint of how toxic the zig community is.
They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.
I think it has a lot more to do with the Bun situation.
Re: Introduce a memory safe compilation mode inspired by Fil-C
#23Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.
The idea of this is that you can import libraries from C/C++ and wrap them on the filC compilation mode, I could see some fuzzing usage on this too but I do agree it's not quite where I would like to see project effort going.
Re: Introduce a memory safe compilation mode inspired by Fil-C
#24Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.
If you see a substantive comment you think might be deleted, screenshot it. But I do see debate in there.
directly from the thread:
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
Re: Introduce a memory safe compilation mode inspired by Fil-C
#25Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.
The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.
Apparently I'm not. Directly from andrewk himself:
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
Re: Introduce a memory safe compilation mode inspired by Fil-C
#26Without explicitly entering the language holy wars. I think there’s an interesting trade-off here.
Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead.
Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from bounds checking.
Maybe zig could find a way to elide enough of the capability overhead that careful programming could get a Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. This would be great for compile times and places where open source is not tenable.
Regardless, I’m very happy to see another independent school of thought approach memory safety. I’ll forgive Mr. Kelly any gruffness, these topics can be quite annoying to discuss in public.
Re: Introduce a memory safe compilation mode inspired by Fil-C
#27Earlier quoted context omitted.
The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.
Apparently I'm not. Directly from andrewk himself: If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say This itself is hostility towards anyone who isn't a zig expert pretty much.
This is the Zig repository. It is totally appropriate to expect people to be Zig experts when working on Zig itself. People should understand the repository they are talking about. If you're not even invested enough to write a project in Zig, of course your opinion is nothing but noise.
Re: Introduce a memory safe compilation mode inspired by Fil-C
#28[deleted]
Re: Introduce a memory safe compilation mode inspired by Fil-C
#29It’s kinda funny how butthurt they are about Rust, especially considering that most Rust users probably don’t think about Zig at all. I’m not sure what they gain by being so antagonistic about it…
Re: Introduce a memory safe compilation mode inspired by Fil-C
#30Without explicitly entering the language holy wars. I think there’s an interesting trade-off here. Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead. Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from…
You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.
> Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries.
One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.