Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fil-C: Garbage In, Memory Safety Out [video]

youtube.com

Post reply on HN
Print view View original

151–160 of 190 posts

Re: Fil-C: Garbage In, Memory Safety Out [video]

#151

Post by im3w1l »

kibwen wrote: post #148
im3w1l wrote: post #144

Earlier quoted context omitted.

It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.

Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates i…

A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#152

Post by kibwen »

pjmlp wrote: post #126
wasmperson wrote: post #71

Earlier quoted context omitted.

The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits: https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...

Just like on Go's case, panic/recover are exceptions with bad ergonomics.

This is a vacuous statement on par with characterizing setjmp/longjmp in C as "exceptions with bad ergonomics".

Re: Fil-C: Garbage In, Memory Safety Out [video]

#153

Post by kibwen »

wasmperson wrote: post #71
jagadaga wrote: post #32

Earlier quoted context omitted.

>I've long faulted Rust's use of Result over exceptions Why?

The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits: https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...

No, Rust does not have exceptions. Rust has unwinding, if you choose to compile your program with support for it, which you are free not to, and is trivially achieved by a single flag.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#154

Post by nu11ptr »

pizlonator wrote: post #107
wild_pointer wrote: post #101

Earlier quoted context omitted.

Let's not shy away then. What details do you disagree on? P.S. Also fan of your work. Competition is always good.

Rereading your post, I think I just disagree on two things: I don’t think Rust users can be trivialized into the “two kinds” that you list, and if one of the kinds is “app developer” then I bet you there are apps where Fil-C’s value proposition is exactly right, except just the fact that Fil-C is so new and immature. Say you want to ship a native UI. Using GTK from fil-C is fantastic. And I specifically disagree with…

> When I write new code in Fil-C, I just lean into the GC all the way, which makes programming in C and C++ so much nicer. I don’t ref count, I don’t use smart pointers, I don’t free and I don’t delete. It makes these languages so much nicer!

Sure, GC's are nice which is why so many langs have them, but that removes the deterministic allocation performance which most C/C++ programmers want (and many times need). Why not just use something like Go then? You have a much richer stdlib available out of the box.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#155

Post by Jach »

baranul wrote: post #96
josephg wrote: post #92

Earlier quoted context omitted.

> But what is being overlooked, is the massive numerical dominance of C programmers I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time. I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)

> I haven’t seen C topping programming language popularity charts C is still highly ranked on many charts. C (as of July 2026) is ranked #2 on the TIOBE index. PYPL has C and C++ weirdly merged, the annoying C/C++, and that comes in as #3. The IEEE and Redmonk have C firmly in the top 10, using different methodologies. We also have to consider how many years back that C's run in the top 10 goes. We have to also use c…

A job market specific survey: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... They combine C and C++ together and it slides in at number 6. But together they only account for 5% of the job market. Totaling all such non-managed languages together is roughly 10% and that figure hasn't changed in decades. I'd bet that figure matches up with what consultancy firms that take on a wide variety of projects see. Needless to say, "massive numerical dominance" in relation to C is something that needs many qualifications to become true. Certainly there's a lot of C code out there, and C jobs, and in some niche domains it's very dominant. But there's just such a vast amount more of JavaScript, Java, and Python across more domains.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#156

Post by rcxdude »

josephg wrote: post #149
rcxdude wrote: post #100

Earlier quoted context omitted.

to be fair, most programmers are at least a little bit polyglot, and if you know python and C and you're trying to solve an interview problem, python is gonna be the easier option 99% of the time, even if you're not that great at python compared to C.

> python is gonna be the easier option 99% of the time If python/go/C# is easier to write, why choose C? Fil-C removes C’s performance and interoperability advantages.

Python is easier to write for interview questions. It generally doesn't scale well (in terms of size of team and codebase).

TBH C# is probably a good default for a lot of projects, from a safety and performance standpoint (rust's big performance win over GC/JIT languages is more in the memory consumption than throughput, counterintuitively). Fil-C probably still has a pretty good edge on python's performance, though.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#157

Post by pjmlp »

kibwen wrote: post #152
pjmlp wrote: post #126

Earlier quoted context omitted.

Just like on Go's case, panic/recover are exceptions with bad ergonomics.

This is a vacuous statement on par with characterizing setjmp/longjmp in C as "exceptions with bad ergonomics".

Which they kind of are, and were used as implementation mechanism for C++ exceptions in the early days on UNIX compilers.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#158

Post by kibwen »

im3w1l wrote: post #151
kibwen wrote: post #148

Earlier quoted context omitted.

Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates i…

A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.

No, that's not how this works. The bug being utilized by cve-rs has such roundabout requirements that it's unlikely that anyone has ever triggered it without trying (to be clear, the Rust devs plan to fix it regardless). Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...

Re: Fil-C: Garbage In, Memory Safety Out [video]

#159

Post by pjmlp »

LoganDark wrote: post #11
raggi wrote: post #6

Earlier quoted context omitted.

This presentation wasn’t too bad in terms of us vs theming, but in general throughout the lifetime of the project there’s been a strong us vs them rhetoric. I think it’s working as a marketing tactic to some extent but there are better, albeit harder ways to market the thing.

Rust generally invites us vs them everywhere because it's just so ambitious and attractive (to some). Fil-C probably receives questions all the time about why they don't just do X or Y that Rust does. Maybe they end up supporting their position against that type of pressure and it looks like they're opposing Rust when all they're doing is justifying themselves.

Because by making Cyclone's ideas mainstream, which AT&T started alongside Cornell University, the C and C++ devs that so far felt safe from all those RC/GC languages, now had an actually problem as companies started paying attention and embracing the language's ideas, even extending the type system of existing RC/GC languages.

Thus anyone that identifies themselves with the programming language they work with, gets dragged into a us vs them discussion.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#160

Post by _flux »

MrBuddyCasino wrote: post #138
AlotOfReading wrote: post #50

Earlier quoted context omitted.

Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too. That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.

> That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Yes. This is why unchecked exceptions are annoying. Checked exceptions are a „failed experiment“ anyway. A result type (or even Go‘s err) with forced error handling meaningfully increases the robustness of a program in my experience.

My view is that Java's checked exceptions failed in big part because Java didn't have type variables back then; after all, polymorphic Result types are not that much different from checked exceptions.

I haven't written any Java since it has gained those, so I suspect there might be other aspects making it awkward. And it still would lack exhaustiveness checking that e.g. Rust has.

Post reply on HN