I haven't followed swift too closely, but ref counting is not a good fit for typical server applications. Sure, value types and such take off a lot of load from the GC (yes, ref counting is a GC), but still, tracing GCs have much better performance on server workloads. (Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive).
> but still, tracing GCs have much better performance on server workloads
Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases.
> Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive
Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.
In my opinion they need to invest a lot more time and money into it for that.
The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).
Swift is my hope for the next big server language. Great type system, great error handling.
I haven't followed swift too closely, but ref counting is not a good fit for typical server applications. Sure, value types and such take off a lot of load from the GC (yes, ref counting is a GC), but still, tracing GCs have much better performance on server workloads. (Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive).
> but still, tracing GCs have much better performance on server workloads
Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases.
> Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive
Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.
1 reply →
Tracing GC and their pauses on server workload is another tradeoff. They all have a tradeoff. You make a fair point.
1 reply →
In my opinion they need to invest a lot more time and money into it for that. The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).