this post was submitted on 26 Feb 2024
263 points (96.5% liked)
Programming
17408 readers
65 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.
Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that's much easier on the programmer.
And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.
A better approach is the one Apple uses with Swift (and before that, Objective-C... though that wasn't memory safe).
In swift the compiler writes virtually all of your memory management code for you, and you can write a bit of code (or annotate things) for rare edge cases where you need memory management to do something other than the default behaviour.
There's no garbage collection, but 99.999% of your code looks exactly like a garbage collected language. And there's no performance penalty either... in fact it tends to be faster because compiler engineers are better at memory management than run of the mill coders.
To be fair, Swift uses reference counting instead of garbage collection which has different tradeoffs than GC but does incur a performance penalty.
I wish more languages used ref counting. Yes, you have to be careful of circular refs, but the tradeoff is simplicity, speed, lack of needing threads in the runtime, and predictability. Rust gives you special data structures for ref counting for a reason.
Ref counting is just a very basic GC. I'd be surprised if a ref counted language performed better than a GC one. Sure, the program won't temporarily halt in order to run the GC, but every copy/destroy operation will be slower.
When Apple introduced the iPhone they required automatic reference counting to be used in Objective-C rather than tracing garbage collection (the language supported both) due to performance reasons (iPhones were significantly slower than Macs). At least Apple seems to think that reference counting is faster than tracing garbage collectors. The compiler can do a lot to remove unnecessary releases and retains. Additionally each retain is just incrementing an integer, and each release is just decrementing an integer and comparing the integer to 0, so the overhead is pretty small.
If the compiler optimizes away some RC then I see how it can be faster.