19 ms·
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) Safet
by quotemstr 1y ago
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
- Klonoar 1y agoFil-C has come up on HN plenty of times before. If it was going to make much of a dent in the discussions, it would have by now.
- quotemstr 1y agoIt's strange how ideas seem to explode at random into the discourse despite being known for a long time. It's as if some critical mass stumbles on a thing and it becomes "the current thing" everyone talks about until the next current thing.
- jitl 1y agoodd fallacy. things grow in popularity / awareness over time
- ddalex 1y agoI'm on camp 2.
- dev_l1x_be 1y agoWe have a saying that jam is made of fruit that gave up the fight becoming a brandy.
- Rebelgecko 1y agoObviously someone needs to rewrite Rust in Fil-C
- pizlonator 1y agoYeah since Fil-C is just an LLVM transform we could make Rust memory safe with it
- int_19h 1y agoIt's not an either-or (well, except for this last item). It seems sensible to not write new software in plain C. Rust is certainly a valid choice for a safer language, but in many cases overkill wrt how painful the rewrite is vs benefits gained from avoiding a higher-level memory-safe one like OCaml. At the same time, "let's just rewrite everything!" is also madness. We have many battle-tested libraries written in C already. Something like Fil-C is badly needed to keep them working while improving safety. And as for wasm, it's sort of orthogonal - whether you're writing in C or in Rust, the software may be bug-free, but sandboxing it may still be desirable e.g. as a matter of trust (or lack thereof). Also, cross-platform binaries would be nice to have in general.
- vacuity 1y ago> the software may be bug-free, but sandboxing it may still be desirable e.g. as a matter of trust (or lack thereof) Wouldn't the only cause of mistrust be bugs, or am I missing something? If the program is malicious, sandboxing isn't the pertinent action.
- int_19h 1y agoIf any program can potentially be malicious (which is the effectively the case today with any downloaded software), then sandboxing is exactly the pertinent action - provided that the sandbox is tight enough.
- vacuity 1y agoI should have elaborated. If a program is known to be malicious, or should be treated as malicious, then it should probably be terminated. Given a potentially malicious program and no easy way to determine (lack of) malice, sandboxing is a reasonable measure.