[pizlonator]

> it seems impossible to secure c or c++

False. Fil-C secures C and C++. It’s more comprehensively safe than Rust (Fil-C has no escape hatches). And it’s compatible enough with C/C++ that you can think of it as an alternate clang target.

[NIckGeek]

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency.

Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.

[pizlonator]

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`.

Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

[NIckGeek]

> but in practice fails, because of pervasive use of `unsafe`.

Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.

I'm aware C already has a runtime, this adds to it.

[pizlonator]

> Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.

Those are the excuses I heard from C++ programmers for years.

Memory safety is about guarantees enforced by the compiler. `unsafe` isn't that.

[Rusky]

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.

[pizlonator]

> The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

It’s not the same.

The Fil-C runtime is the same runtime in every client of Fil-C. It’s a single common trusted compute base and there’s no reason for it to grow.

On the other hand Rust programmers use unsafe all over the place, not just in some core libraries.

[Rusky]

Yeah, that's what I meant by "depends on the specific programs you're writing." Confining unsafe Rust to core libraries is totally something people do.

[pizlonator]

You're equating a core runtime that doesn't grow with libraries written by anyone.

There's no world in which a Fil-C user would write unsafe code. That's not a thing you can do in Fil-C.

Rust users write unsafe code a lot and the language allows it and encourages it even.

[Ygg2]

> It's more comprehensively safe than Rust

Yeah. By adding a runtime.

> Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space)

https://github.com/pizlonator/llvm-project-deluge/tree/delug...

[pizlonator]

> Yeah. By adding a runtime.

So? That doesn't make it any less safe or useful.

In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem.

Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.

[jandrewrogers]

It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice.

Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.

[pizlonator]

> It makes it a lot less performant and there is no avoiding or mitigating that downside.

You can’t possibly know that.

> C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice.

Is that why sudo, bash, coreutils, and ssh are written in C?

Of course not.

C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI.

> Fil-C is not a replacement for C++ generally, that oversells it.

I have made no such claim.

Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier).

> It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.

It’s the opposite in my experience. For example, xzutils and simdutf have super lower overhead in Fil-C. In the case of SIMD code it’s because using SIMD amortizes Fil-C’s overheads.

[comex]

> C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI.

Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer.

> Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier).

The world of compilers is littered with corpses of projects that spent years claiming faster performance was right around the corner.

I believe you can make it faster, but how much faster? We'll see.

I think these types of compatibility layers will be a great option moving forward for legacy software. But I have a hard time seeing the case for using Fil-C for new code: all the known disadvantages of C and C++, now combined with performance closer to Java than Rust (if not worse), and high difficulty interoperating with other native code (normally C and C++'s strength!), in exchange for marginal safety improvements over Rust (minus Rust's more general safety culture).

edit: I feel bad writing such a dismissive comment, but it's hard to avoid reacting that way when I see unrealistically rosy portrayals of projects.

[pizlonator]

> Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer.

This is exactly what Fil-C does.

> all the known disadvantages of C and C++

The main disadvantage of C and C++ is unsafety and fil-C comprehensively fixes that.

> edit: I feel bad writing such a dismissive comment, but it's hard to avoid reacting that way when I see unrealistically rosy portrayals of projects.

How is my portrayal unrealistically rosy?

Even the fact that you know what the current perf costs are is the result of me being brutally honest about its perf.

I suspect something else is going on.

[dustbunny]

> a lot less performant

Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!

[pizlonator]

I mean bro isn’t totally wrong.

Fil-C’s perf sucks on some workloads. And it doesn’t suck on others.

Extreme examples to give you an idea:

- xzutils had about 1.2x overhead. So slower but totally usable.

- no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound.

- 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think.

But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).

[nzeid]

I love this shameless self-promotion. ;)

Fil-C is in the cards for my next project.

[pizlonator]

Thank you for considering it :-)

Hit me up if you have questions or issues. I’m easy to find

[90s_dev]

One of these days, a project will catch on that's vastly simpler than any memory solution today, yet solves all the same problems, and more robustly too, just like how it took humanity thousands of years to realize how to use levers to build complex machines. The solution is probably sitting right under our noses. I'm not sure it's your project (maybe it is) but I bet this will happen.

[pizlonator]

That’s a really great attitude! And I think you’re right!

I think in addition to possibly being the solution to safety for someone, Fil-C is helping to elucidate what memory safe systems programming could look like and that might lead to someone building something even better