3 ms·

Thanks for the answer! I also would love to see more experiences presented about Julia in the wild. D and Nim are both on my list too and I will definitely cons

Thanks for the answer! I also would love to see more experiences presented about Julia in the wild. D and Nim are both on my list too and I will definitely consider them in a more objective comparison. Rust does "feel" like a lot of overhead in order to avoid the GC. Can you comment on / know how I can check whether the GC in Julia is going to cause an issue for me?

oconnor663 8y ago
> Rust does "feel" like a lot of overhead in order to avoid the GC. Might be worth adding, Rust's ownership model isn't just to avoid GC. It ends up solving several problems at once: - Thread safety. This one is huge. The Rust compiler knows when you're giving multiple threads racy access to the same object, and it prevents that at compile time. The trait system (Send and Sync) is a big part of this, but the ownership model is crucial too. Many languages that use GC to avoid dangling pointers, like Java and Go, can still invoke undefined behavior if you write a data race. - Destructors. Sure, Rust has destructors because it doesn't have GC, but they're also a feature in their own right. Rust supports C++ style RAII without needing a defer/with/using statement; an API can add cleanup without "bubbling up" through all of its callers. It also means you don't have to worry about weird scenarios where finalization happens in an order you don't expect (see e.g. https://golang.org/pkg/runtime/#SetFinalizer https://golang.org/pkg/runtime/#SetFinalizer, https://docs.python.org/3.6/reference/datamodel.html#object.__del__ https://docs.python.org/3.6/reference/datamodel.html#object....). Destructors are great, and the ownership model makes them safe. - Less need for defensive copies and immutable collections. Big Python and Java programs often rely on these to avoid bugs where one part of a program mutates something that another part wasn't expecting, especially across threads. Rust's ownership model means that functions are explicit about when they have permission to write to some object, and when they might be stashing a reference for later. If you write a function that takes `&mut HashMap`, you have a guarantee that no one else will write to (or read from!) that map until you're done, and the compiler will make sure your callers uphold that guarantee.

oconnor663 8y ago

> Rust does "feel" like a lot of overhead in order to avoid the GC. Might be worth adding, Rust's ownership model isn't just to avoid GC. It ends up solving several problems at once: - Thread safety. This one is huge. The Rust compiler knows when you're giving multiple threads racy access to the same object, and it prevents that at compile time. The trait system (Send and Sync) is a big part of this, but the ownership model is crucial too. Many languages that use GC to avoid dangling pointers, like Java and Go, can still invoke undefined behavior if you write a data race. - Destructors. Sure, Rust has destructors because it doesn't have GC, but they're also a feature in their own right. Rust supports C++ style RAII without needing a defer/with/using statement; an API can add cleanup without "bubbling up" through all of its callers. It also means you don't have to worry about weird scenarios where finalization happens in an order you don't expect (see e.g. https://golang.org/pkg/runtime/#SetFinalizer https://golang.org/pkg/runtime/#SetFinalizer, https://docs.python.org/3.6/reference/datamodel.html#object.__del__ https://docs.python.org/3.6/reference/datamodel.html#object....). Destructors are great, and the ownership model makes them safe. - Less need for defensive copies and immutable collections. Big Python and Java programs often rely on these to avoid bugs where one part of a program mutates something that another part wasn't expecting, especially across threads. Rust's ownership model means that functions are explicit about when they have permission to write to some object, and when they might be stashing a reference for later. If you write a function that takes `&mut HashMap`, you have a guarantee that no one else will write to (or read from!) that map until you're done, and the compiler will make sure your callers uphold that guarantee.