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

Notes by djb on using Fil-C

cr.yp.to

Post reply on HN
Print view View original

101–110 of 263 posts

Re: Notes by djb on using Fil-C

#101

Post by mbrock »

petesergeant wrote: post #97
vorador wrote: post #90

Earlier quoted context omitted.

There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.

> Fil-C is new and is a viable competitor to rust I’ve no horse in the race here, but the Fil-C page talks about a 4x overhead from using it, which feels like it would make it less competitive

Currently measured worst case for some types or code.

Re: Notes by djb on using Fil-C

#102

Post by Rebelgecko »

quotemstr wrote: post #65

I can't wait for all the delicious four-way flamewars. Choose your fighter! 1) Rewrite X in Rust 2) Recompile X using Fil-C 3) Recompile X for WASM 4) Safety is for babies There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C

Obviously someone needs to rewrite Rust in Fil-C

Re: Notes by djb on using Fil-C

#103

Post by Rebelgecko »

dontlaugh wrote: post #28
jeffrallen wrote: post #8

Wish we were talking about making Fil-C required for apt, not Rust...

Fil-C is slow. There is no C or C++ memory safe compiler with acceptable performance for kernels, rendering, games, etc. For that you need Rust. The future includes Fil-C for legacy code that isn’t performance sensitive and Rust for new code that is.

I imagine Apt is usually IO constrained?

Re: Notes by djb on using Fil-C

#104

Post by quotemstr »

kragen wrote: post #99
quotemstr wrote: post #64

Earlier quoted context omitted.

It's amazing how much technical discourse revolves around impressions. "Oh, it has a GC! GC bad!" "No, this GC by smart guy, so good!" "No, GC always bad!" People aren't engaging with the technical substance. GC based systems and can be plenty good and fast. How do people think JavaScript works? And Go? It's like people just absorbed from the discursive background radiation the idea GC is slow without understanding w…

> How do people think JavaScript works? Very slowly. Java, OCaml, or LuaJIT would be better examples here!

How many of the "GC is always slow" people would recognize those systems? Besides: V8 and JSC have pretty decent JITs nowadays. IME, performance of JIT systems has more to do with the structure of programs written in JS than with VM performance itself.

Re: Notes by djb on using Fil-C

#105

Post by pjdesno »

GTP wrote: post #49
simonask wrote: post #44

Earlier quoted context omitted.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

I would say that Rust would be a better choice rarher than patching memory safety on top of C. But I think the reason for this is that most, if not all, cryptographic reference implementations are in C. So they want to use existing reference implementations without having to port them to Rust. IMO cryptographers should start using Rust for their reference implementations, but I also get that they'd rather spend their…

The original poster got pretty much all of Debian running in Fil-C, in a fairly brief amount of time.

Re-writing even a single significant library or package in Rust would take exponentially longer, so in this case Rust would not be "a better choice", but rather a non-starter.

Re: Notes by djb on using Fil-C

#106

Post by miki123211 »

simonask wrote: post #44
mbrock wrote: post #35

Earlier quoted context omitted.

Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's state of the art concurrent GC, for example. So—yes, but don't dismiss it too quickly.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

If you write your software in a language that needs GC, everybody using your software needs GC, but they're guaranteed to get memory safety.

If you write your software in an unsafe, non-GC language, nobody needs GC, but nobody gets memory safety either.

This is why many software developers chose the latter option. If there were some use cases in which GC wasn't acceptable for their software, nobody would get GC, even the people who could afford it, and would prefer the increased memory safety.

Fil-C lets the user make this tradeoff. If you can accept the GC, you compile with Fil-C, otherwise you use a traditional C compiler.

Re: Notes by djb on using Fil-C

#107

Post by pizlonator »

kragen wrote: post #57
simonask wrote: post #44

Earlier quoted context omitted.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

I think Fil-C is for people who are using software that has already been written, not for people who are trying to pick what language to write new software in. A substantial amount of software has, after all, already been written.

It's super fun to write C and C++ code in Fil-C because it's like this otherworldly crossover between Java and C/C++:

- Unlike Java, you get fantastic startup times.

- Unlike Java, you get access to actual syscall APIs.

- Unlike Java, you can leverage the ecosystem of C/C++ libraries without having to write JNI wrappers (though you do have to be able to compile those libraries with Fil-C).

- Like Java, you can just `new` or `malloc` without `delete`ing or `free`ing.

It's so fun!

Re: Notes by djb on using Fil-C

#108

Post by pizlonator »

Rebelgecko wrote: post #102
quotemstr wrote: post #65

I can't wait for all the delicious four-way flamewars. Choose your fighter! 1) Rewrite X in Rust 2) Recompile X using Fil-C 3) Recompile X for WASM 4) Safety is for babies There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C

Obviously someone needs to rewrite Rust in Fil-C

Yeah since Fil-C is just an LLVM transform we could make Rust memory safe with it

Re: Notes by djb on using Fil-C

#109

Post by pizlonator »

Rebelgecko wrote: post #103
dontlaugh wrote: post #28

Earlier quoted context omitted.

Fil-C is slow. There is no C or C++ memory safe compiler with acceptable performance for kernels, rendering, games, etc. For that you need Rust. The future includes Fil-C for legacy code that isn’t performance sensitive and Rust for new code that is.

I imagine Apt is usually IO constrained?

That's my guess, yeah

Also, Fil-C's overheads are the lowest for programs that are pushing primitive bits around.

Fil-C's overheads are the highest for programs that chase pointers.

I'm guessing the CPU bound bits of apt (if there are any) are more of the former

Re: Notes by djb on using Fil-C

#110

Post by vorador »

testdelacc1 wrote: post #94
vorador wrote: post #90

Earlier quoted context omitted.

There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.

There’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well. It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way. And Jesus Christ, give it a rest with this “Rust…

No, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing.

Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.

Post reply on HN