One divide when it comes to using Fil-C is C as an application (git) vs C as a library from another language (libgit2).

Suppose we assume that many C applications aren’t performance sensitive and can easily take a 2-4x performance hit without noticing. Browsers and OS internals being obvious exceptions. The ideal candidates are like the ones djb writes, and he’s already a convert to Fil-C. sudo, sshd, curl - all seem like promising candidates.

But as far as I can tell, Fil-C doesn’t work for C libraries that can be called from elsewhere. Even if it could be made to work, the reason other languages like Python or Node use C libraries is for speed. If they were ok with it being 2-4x slower, they would just write ordinary Python or Javascript.

C (and C++) are fundamentally important because of their use in performance sensitive contexts like operating systems, browsers and libraries. If we’re restricting Fil-C to pure C/C++ applications that aren’t performance sensitive, that might still be very important and useful, but it’s a small slice of the large C/C++ pie.

Also, it’s a great tool for an existing C application, certainly. A performance hit in exchange for security is a reasonable trade off while making a battle hardened application work. But for a new application, would someone choose Fil-C over other performant GC languages like Go or Java or C#? I’d be keen to hear why.

Still, I want to stress - this is a great project and it’ll generate a lot of value.

▲

zozbot234 3 days ago | parent | next [-]

Why can't it work? You need to assume that the C library is only ever passed well-behaved pointers and callbacks in order to avoid invoking UB that it can't know about - but other than that it's just a matter of marshaling from the usual C ABI to the Fil-C ABI, which should be doable.

▲

testdelacc1 3 days ago | parent [-]

I’m assuming the calling program is a GC language like Python or Node (the most popular run times by far), but the same holds with other popular languages like Ruby. Why would a GC language call out to slow code, that runs its own separate GC. Now you have two GCs running, neither of which knows about the other. I’m not declaring it’s impossible, I’m asking why someone would want to do this.

An example: GitHub’s entire business revolves around calling libgit2 (C) from Ruby. Are they more likely to slow down libgit2 and make it substantially more complex by running 2 GCs side by side, or are they going to risk accept any potential unsafety in regular C? It’s 100% the latter, I’ll bet on that.

▲

zozbot234 3 days ago | parent | next [-]

> ...Now you have two GCs running, neither of which knows about the other. ...

For a strictly time-limited interaction (like what's involved in a FFI call) it's not that bad. Everything that GC2 might directly access is temporarily promoted to a root for GC1, and vice versa.

▲

gf000 2 days ago | parent | prev | next [-]

A native library is an obvious memory safety hole so I don't see why would it be that controversial to want to fill it even if it introduces another GC (but working on an independent heap, so the slowdown is not necessarily multiplicative)

▲

actionfromafar 3 days ago | parent | prev [-]

The former could still be cheaper than stop using libgit altogether.

▲

testdelacc1 3 days ago | parent [-]

No one is asking them to stop using libgit2 though. They’re going to continue using it. If they find a serious bug, they’ll fix it and continue using it.

The cost of all the additional hardware is just not worth it. If it was a choice between higher hardware costs, higher request latency, greater operational complexity of a new technology and rewriting libgit2 in a different language without all those tradeoffs, GitHub definitely chooses the latter.

But it’s never going to reach that point because they’ll continue using libgit2 compiled by clang forever.

	▲	actionfromafar 2 days ago \| parent [-]
		That's very interesting to learn.

▲

pizlonator 2 days ago | parent | prev [-]

> If they were ok with it being 2-4x slower, they would just write ordinary Python or Javascript.

Python and JavaScript are much more than 4x slower than C/C++ for workloads that are git-like (significant amount of compute, not just I/O bound)

> C (and C++) are fundamentally important because of their use in performance sensitive contexts like operating systems, browsers and libraries

That's a fun thing to say but it isn't really true. C/C++ are fundamentally important for lots of reasons. In many cases, folks choose C and C++ because that's the only way to get access to the APIs you need to get the job done.

	▲	testdelacc1 15 hours ago \| parent [-]
		Yeah I suppose that’s the real question - what is the size of the target market of Fil-C? I believe it’s a small % because many C applications are performance sensitive. You say performance is only one consideration among many so the % of C applications that would benefit from your compiler are much higher. You’re the guy actually building this, so you would have talked to potential customers more than me. You’re more likely to be correct, but I would be interested to know what these applications are. Also, do you hope people pick Fil-C for a new code base over other performant GC languages like Go, Java and C#? These have less than a 2x overhead for CPU bound tasks.