[pizlonator]

I’m biased since I’m the Fil.

It was materially useful in this project.

- Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise.

- C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich and the lambdas/templates and class system is so mature).

But I’m biased in multiple ways

- I made Fil-C++

- I’ve been programming in C++ for like 35ish years now

[thesz]

If I may (and correctly understand what is going inside Fil-C), it would be not so hard to add support for software transactional memory by adding some library calls.

This will greatly reduce coordination bugs in parallel programs and may even speed things up.

[pizlonator]

It would be hard for the same reason it’s always been hard:

- STM interacts badly with any interesting effects (like IO)

- STM interacts badly with locks (C and C++ use locks implicitly, because they’re in libc and libc++)

- STM performs badly

- STM is harder to use than locks

[HarHarVeryFunny]

Are you using malloc + GC in preference to smart pointers, and if so why? I thought Fil-C was just C not C++?

It doesn't seem like that is necessarily a performance win, especially since you could always use a smart pointer's raw pointer (preferably const) in a performance critical path.

[pizlonator]

Fil-C is C and C++

Smart pointers give you reference counting at best. Language implementations tend to have a lot of reference cycles, so you need actual GC (or a very sophisticated kind of manual memory management)

[vlovich123]

I’m curious. Given the overheads of Fil-C++, does it actually make sense to use it for greenfield projects? I like that Fil-C fills a gap in securing old legacy codebases, I’m just not sure I understand it for greenfield projects like this other than you happen to know C++ really well.

[pizlonator]

It made sense because I was able to move very quickly, and once perf became a problem I could move to Yolo-C++ without a full rewrite.

> happen to know C++ really well

That’s my bias yeah. But C++ is good for more than just perf. If you need access to low level APIs, or libraries that happen to be exposed as C/C++ API, or you need good support for dynamic linking and separate compilation - then C++ (or C) are a great choice

[vlovich123]

Hmmm… I did about 20+ years of C++ coding and since I’ve been doing Rust I haven’t seen any of these issues. It has trivial integrations with c/c++ libraries (often with wrappers already written), often better native libraries to substitute those c++ deps wholesale, and separate compilation out of the box. It has dynamic linking if you really need it via the C ABI or even rlib although I’ll grants the latter is not as mature.

The syntax and ownership rules can take some getting used to but after doing it I start to wonder how I ever enjoyed the masochism of the rule of 5 magic incantation that no one else ever followed and writing the class definition twice. + the language gaining complexity constantly without ever paying back tech debt or solving real problems.