Sure all of those are escape hatches that work against any memory safety tech.

Point is, Fil-C goes further than any other memory safety tech in terms of what it guards

quotemstr 10 minutes ago | parent | next [-]

Strip away all the irrelevant distinctions, and your whole argument becomes that the unsafely of "unsafe" is that only you, Pizlo, can be trusted to write unsafe code.

I am not being uncharitable. I am not exaggerating. Every system has safe and unsafe parts. Fil-C is no exception. You're the sole author of its unsafe parts. By touting this arrangement as a security advantage, you're placing yourself ahead of every other systems programmer out there who might have a legitimate reason to write unsafe code. Doing so is unfathomably arrogant.

▲

josephg 2 hours ago | parent | prev | next [-]

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

▲

pizlonator an hour ago | parent [-]

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does.

So Fil-C is safer than those

	▲	josephg 41 minutes ago \| parent \| next [-]
		The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs. > Fil-C is safer than those Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work. But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.
	▲	ncruces 38 minutes ago \| parent \| prev \| next [-]
		Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.
	▲	Splizard 38 minutes ago \| parent \| prev [-]
		Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.

▲

modeless 2 hours ago | parent | prev [-]

Fully agreed. At some point you have to draw a line and say that the rest is the responsibility of the kernel and hardware and user, and I think Fil-C drew that line in the right place.