6 ms·

If you are going to wrap everything in Rc, just use kotlin or c-sharp or python?

by mrfox321 5y ago

5e92cb50239222b 5y ago
And suffer a 100 MB runtime? If anything, Rust with refcounts for everything is much closer to Swift.
- mrfox321 5y ago
  Ah didnt realize swift has no runtime. Thanks!
  - ssokolow 5y ago
    As I remember, it uses an evolution of Objective-C's Automatic Reference Counting feature.
  - pjmlp 5y ago
    Every language has a runtime, it is what supports the basic language infrastructure, including Swift. https://github.com/apple/swift/blob/main/docs/Runtime.md https://github.com/apple/swift/blob/main/docs/Runtime.md
    - deleted 5y ago
      [deleted]
scotty79 5y ago
Because Rust feels even nicer than Python and C# (I don't have any experience with kotlin but from what I've seen it's as decent as Python at least) and even with Rc<> Rust is quite light-weight and fast. One of its selling points is zero-cost abstractions and pretty powerful abstractions at that.
CodesInChaos 5y ago
Rust has advantages over C#, even for high level programming: * Rust traits are more flexible than C# interfaces, especially when combined with generics (implementing traits for foreign types, associated types, each method can have its own constraints, conditional trait implementation, #derive) * Rust has much stronger thread safety guarantees (absence of data races, preventing access to a mutex's data without locking) * Options are cleaner than null (though at least C# supports non-nullable reference types nowadays) * Cleaner error handling through `Result`s. In C# you either have to use exceptions (discouraged for errors that are expected to happen), or use ad-hoc approaches which don't benefit from syntax sugar like the `?` operator. * Support for discriminated unions ("enums") * I like cargo better than msbuild+nuget ("it just works", feature-flags + conditional dependencies, distribution as source instead of binaries) On the other hand C# has better IDEs and you don't have to deal with the rigors of ownership and the borrow checker. In particular I struggle with LINQ style functional programming in Rust, since the lifetimes of closures and the fields they close over are difficult to reason about. I haven't used Kotlin, but expect it to be similar to C# in its strengths and weaknesses. Python is not an option for me, since I like static typing.
- hailwren 5y ago
  I haven't used C#, so I can't comment on the IDEs there. However, it's surprising to me that you can get a better experience than VScode + rust-analyzer. It feels like magic when I use it.
- quotemstr 5y ago
  I don't agree that people should avoid exceptions for expected errors. The idea that they should has twisted the error handling landscape into a pretzel and is responsible for some ugly bits of Rust design.
  - tialaramex 5y ago
    Exceptions are a mechanism for error handling that comes with control flow changes. But Rust already has perfectly nice control flow mechanisms (look at std::ops::ControlFlow for example) and perfectly nice error handling. So you can use either, or both, as necessary, you don't need this particular Frankenstein's Monster. Using Exceptions for things that aren't actually exceptional is perverse.
marcus_cemes 5y ago
Correct me if I'm wrong, but: - GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder - Rc<T> still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed - More efficient memory use, no need to keep track of allocated objects - The rest of the Rust language is a pleasure to use (imo) - Python is slow for certain applications, and not concurrent - Kotlin is kind of more niche than Rust, it's very popular in the Android community, like C# is popular on Windows Just my 2 cents, I love progamming in all languages. There are some use-cases where a high level language is absolutely the way to go. For others, Rust provides much more control with a handy escape hatch. Absolutely don't go wrapping everything in Rc<T> like a madman, only when the reduced complexity is more beneficial than dealing with references/lifetimes.
- Quekid5 5y ago
  > GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder While the last bit is true, it may actually end up having to do lots of work. Think large object graphs where the last reference to any of it goes out of scope. Also, as a matter of terminology: Rc is a form of garbage collection. It's also a pretty bad general GC strategy at that -- which is why one doesn't just slap an Rc on everything.
- throwaway894345 5y ago
  > GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder There are pauseless GCs (e.g., Azul for JVM), and Go kicked off a trend of super-low-latency GC. Also, RC deallocation is O(N) while GC is usually O(1) (ignoring pedantry about how RC is a type of GC). Further, RC can't handle cycles automatically. > Rc<T> still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed Deterministic GC exists, but admittedly isn't widespread. For most non-critical real time systems (e.g., video games) a low latency GC is probably sufficient. > More efficient memory use, no need to keep track of allocated objects I'm not sure if this is true? Presumably each RC has an int for its reference counter? I'm not sure what the bookkeeping overhead is for tracing GCs, but I'm guessing it's not O(N)? > The rest of the Rust language is a pleasure to use (imo) Agreed, but the borrow checker affects everything so this is a pretty small consolation in practice.
throwaway894345 5y ago
While I understand that with Graal and .Net you can ostensibly make native, static binaries for Kotlin or C#, I'm very skeptical that it works well in practice. In particular, I'm guessing it will feel like swimming upstream, fighting an ecosystem and build tooling which mostly assume you're running on a VM. And then there's the question of performance... And of course, with Python your code will run 100x slower than either of the above, your dependency management will suck, you won't be able to statically compile, and to top it all off everyone will give you recommendations for your ailments which take a long time to try out and inevitably will fail miserably for one glaring reason or another. By way of example: "just rewrite the slow bits in C" -> you rewrite the slow bits in C -> your code is now slower because the marshaling costs exceed the gains + your build system is dramatically more complex and you have the sheer joy of debugging segfaults and undefined behavior (yeah, I know Cython exists).
- thinkharderdev 5y ago
  With the modern JVM you actually have to work quite hard to write native code (Rust/C++/C) that outperforms an equivalent Java/Kotlin/Scala implementation. And it is quite easy to perform worse with a native implementation. Of course that is subject to various caveats: 1. Anything running on the JVM will need a 50-500ms of startup time. 2. The JVM implementation will not reach max performance until the runtime has optimized and JIT'd the relevant code paths. 3. There is memory overhead of the VM itself so your runtime will (all else equal) probably require more memory. If you do need to use Graal to generate native images though it can actually be quite nice. You can run locally (or in benchmarking environments) on the VM and get all the tooling and metrics that come along with that, but build a native binary to actually deploy. I agree that it can be kind of a pain though.
  - jandrewrogers 5y ago
    > With the modern JVM you actually have to work quite hard to write native code (Rust/C++/C) that outperforms an equivalent Java/Kotlin/Scala implementation. For what kind of code? I've never experienced comparable performance between JVM and C++ implementations, and I've had the misfortune of writing a couple parallel implementations in recent years where it was literally an "apples to apples" comparison. C++ is faster by default and isn't particularly close, even if you ignore Java's startup and warmup time. I've never seen a native implementation run slower than a JVM one in my entire career, which has included a lot of Java. This is the expected outcome and easily explainable in technical terms. Performance in modern systems is dominated by memory handling efficiency, where C++ is very strong and JVM is not.

If you are going to wrap everything in Rc, just use kotlin or c-sharp or python?

5e92cb50239222b 5y ago

And suffer a 100 MB runtime? If anything, Rust with refcounts for everything is much closer to Swift.

mrfox321 5y ago
Ah didnt realize swift has no runtime. Thanks!
- ssokolow 5y ago
  As I remember, it uses an evolution of Objective-C's Automatic Reference Counting feature.
- pjmlp 5y ago
  Every language has a runtime, it is what supports the basic language infrastructure, including Swift. https://github.com/apple/swift/blob/main/docs/Runtime.md https://github.com/apple/swift/blob/main/docs/Runtime.md
  - deleted 5y ago
    [deleted]

scotty79 5y ago

Because Rust feels even nicer than Python and C# (I don't have any experience with kotlin but from what I've seen it's as decent as Python at least) and even with Rc<> Rust is quite light-weight and fast. One of its selling points is zero-cost abstractions and pretty powerful abstractions at that.

CodesInChaos 5y ago

Rust has advantages over C#, even for high level programming: * Rust traits are more flexible than C# interfaces, especially when combined with generics (implementing traits for foreign types, associated types, each method can have its own constraints, conditional trait implementation, #derive) * Rust has much stronger thread safety guarantees (absence of data races, preventing access to a mutex's data without locking) * Options are cleaner than null (though at least C# supports non-nullable reference types nowadays) * Cleaner error handling through `Result`s. In C# you either have to use exceptions (discouraged for errors that are expected to happen), or use ad-hoc approaches which don't benefit from syntax sugar like the `?` operator. * Support for discriminated unions ("enums") * I like cargo better than msbuild+nuget ("it just works", feature-flags + conditional dependencies, distribution as source instead of binaries) On the other hand C# has better IDEs and you don't have to deal with the rigors of ownership and the borrow checker. In particular I struggle with LINQ style functional programming in Rust, since the lifetimes of closures and the fields they close over are difficult to reason about. I haven't used Kotlin, but expect it to be similar to C# in its strengths and weaknesses. Python is not an option for me, since I like static typing.

hailwren 5y ago
I haven't used C#, so I can't comment on the IDEs there. However, it's surprising to me that you can get a better experience than VScode + rust-analyzer. It feels like magic when I use it.
quotemstr 5y ago
I don't agree that people should avoid exceptions for expected errors. The idea that they should has twisted the error handling landscape into a pretzel and is responsible for some ugly bits of Rust design.
- tialaramex 5y ago
  Exceptions are a mechanism for error handling that comes with control flow changes. But Rust already has perfectly nice control flow mechanisms (look at std::ops::ControlFlow for example) and perfectly nice error handling. So you can use either, or both, as necessary, you don't need this particular Frankenstein's Monster. Using Exceptions for things that aren't actually exceptional is perverse.

marcus_cemes 5y ago

Correct me if I'm wrong, but: - GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder - Rc<T> still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed - More efficient memory use, no need to keep track of allocated objects - The rest of the Rust language is a pleasure to use (imo) - Python is slow for certain applications, and not concurrent - Kotlin is kind of more niche than Rust, it's very popular in the Android community, like C# is popular on Windows Just my 2 cents, I love progamming in all languages. There are some use-cases where a high level language is absolutely the way to go. For others, Rust provides much more control with a handy escape hatch. Absolutely don't go wrapping everything in Rc<T> like a madman, only when the reduced complexity is more beneficial than dealing with references/lifetimes.

Quekid5 5y ago
> GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder While the last bit is true, it may actually end up having to do lots of work. Think large object graphs where the last reference to any of it goes out of scope. Also, as a matter of terminology: Rc is a form of garbage collection. It's also a pretty bad general GC strategy at that -- which is why one doesn't just slap an Rc on everything.
throwaway894345 5y ago
> GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder There are pauseless GCs (e.g., Azul for JVM), and Go kicked off a trend of super-low-latency GC. Also, RC deallocation is O(N) while GC is usually O(1) (ignoring pedantry about how RC is a type of GC). Further, RC can't handle cycles automatically. > Rc<T> still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed Deterministic GC exists, but admittedly isn't widespread. For most non-critical real time systems (e.g., video games) a low latency GC is probably sufficient. > More efficient memory use, no need to keep track of allocated objects I'm not sure if this is true? Presumably each RC has an int for its reference counter? I'm not sure what the bookkeeping overhead is for tracing GCs, but I'm guessing it's not O(N)? > The rest of the Rust language is a pleasure to use (imo) Agreed, but the borrow checker affects everything so this is a pretty small consolation in practice.

throwaway894345 5y ago

While I understand that with Graal and .Net you can ostensibly make native, static binaries for Kotlin or C#, I'm very skeptical that it works well in practice. In particular, I'm guessing it will feel like swimming upstream, fighting an ecosystem and build tooling which mostly assume you're running on a VM. And then there's the question of performance... And of course, with Python your code will run 100x slower than either of the above, your dependency management will suck, you won't be able to statically compile, and to top it all off everyone will give you recommendations for your ailments which take a long time to try out and inevitably will fail miserably for one glaring reason or another. By way of example: "just rewrite the slow bits in C" -> you rewrite the slow bits in C -> your code is now slower because the marshaling costs exceed the gains + your build system is dramatically more complex and you have the sheer joy of debugging segfaults and undefined behavior (yeah, I know Cython exists).

thinkharderdev 5y ago
With the modern JVM you actually have to work quite hard to write native code (Rust/C++/C) that outperforms an equivalent Java/Kotlin/Scala implementation. And it is quite easy to perform worse with a native implementation. Of course that is subject to various caveats: 1. Anything running on the JVM will need a 50-500ms of startup time. 2. The JVM implementation will not reach max performance until the runtime has optimized and JIT'd the relevant code paths. 3. There is memory overhead of the VM itself so your runtime will (all else equal) probably require more memory. If you do need to use Graal to generate native images though it can actually be quite nice. You can run locally (or in benchmarking environments) on the VM and get all the tooling and metrics that come along with that, but build a native binary to actually deploy. I agree that it can be kind of a pain though.
- jandrewrogers 5y ago
  > With the modern JVM you actually have to work quite hard to write native code (Rust/C++/C) that outperforms an equivalent Java/Kotlin/Scala implementation. For what kind of code? I've never experienced comparable performance between JVM and C++ implementations, and I've had the misfortune of writing a couple parallel implementations in recent years where it was literally an "apples to apples" comparison. C++ is faster by default and isn't particularly close, even if you ignore Java's startup and warmup time. I've never seen a native implementation run slower than a JVM one in my entire career, which has included a lot of Java. This is the expected outcome and easily explainable in technical terms. Performance in modern systems is dominated by memory handling efficiency, where C++ is very strong and JVM is not.