High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
1–10 of 122 posts
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#2Based on your description, I think a good library for data structures that are intended to be used immutably would help with some pain points. Something with copy on write support or something like that. It's a powerful style, used it in haskell and it prevents a large class of bugs, almost down to just business logic bugs, which is what you want.
I like the style you're describing, thanks for sharing.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#3C# has indeed finally gained sum types this year… in preview. We’ll see if anything makes it into C#15 but they’re closer than they’ve ever been.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#4Java have less of a DevEx score than C# is crazy work.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#5C# has indeed finally gained sum types this year… in preview. We’ll see if anything makes it into C#15 but they’re closer than they’ve ever been.
Type unions only at first, but there's more being planned.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#6I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain.
Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways.
The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#7Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#8I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain. Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways. The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with…
Pretty sure by devx they mean something like syntax ergonomics. Because otherwise rust's devx first class (cargo, clippy, crates.io) so kind of a nonstandard definition.
I think it's fair to say Java's "syntax ergonomics" are a little below the rest / somewhat manual like rust or C++ by default.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#9F# but not Scala? In TFA F# is only lacking in community and ecosystem. Scala is comparable in popularity to Go or Rust and has access to the entire Java ecosystem and JVM runtime. That should give it the five stars the author is looking for but its not considered.
I think a lot of devs are missing out by not considering Scala 3. I use it with the Zio effect system which brings composable concurrency and transactional memory amongst other features. I don't think there is anything comparable in any of the languages listed in TFA.
Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain
#10I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain. Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways. The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with…
> I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box
As usual, this depends heavily on what you do. I had written a program where Arc reference counting was 25 % of the runtime. All from a single instance as well. I refactored to use borrows and annotated relevant structs with lifetimes. This also enabled additional optimisation where I could also avoid some copies, and in total I saved around 36% of the total runtime compared to before.
The reason Arc was so expensive here is likely that the reference count was contended, so the cacheline was bouncing back and forth between the cores that ran the threads in the threadpool working on the task.
In conclusion, neither extreme is correct. Often Arc is fine, sometimes it really isn't. And the only way to know is to profile. Always profile, humans are terrible at predicting performance.
(And to quite a few people, coming up with ways to avoid Arc/clone/Box, etc can be fun, so there is that too. If you don't enjoy that, then don't participate in that hobby.)