4 ms·

> right now at the top of the benchmarks, common high performance Rust code is mostly “unsafe” memory-wise I only see a single "unsafe" in the Rust implementa

by dmm 6y ago

> right now at the top of the benchmarks, common high performance Rust code is mostly “unsafe” memory-wise I only see a single "unsafe" in the Rust implementation[0]? And that's only in the "raw" Actix instance, not the pg. Or are you talking about Actix framework being mostly unsafe? > only the Go benchmark is written like “standard Go” such that most people writing a service in Go will write Maybe it's just me but the Actix apis seem pretty ordinary. [0] https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Rust/actix/src/main_raw.rs#L119 https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

lstamour 6y ago
> about Actix framework being mostly unsafe Yep, that's what I meant. To me, until Rust unsafe implementations hit 1.0 as web frameworks, not just Tokio, I can't consider them as stable or bug-free as more mature web servers. It's arbitrary, yes, but it's also an important distinction. 1.0 generally means "you can rely on this to not change, and to have a useful set of functionality" and bug fixes equivalent to an LTS release. This is especially true if functionality is common enough that it makes its way into a standard library or conventional best practices. Generally, it has to hit "1.0" before it does so, though, in any stable manner...
- covidthrow 6y ago
  The Actix unsafe code has long since been resolved. There are very few instances of it, and each are small, specific, easy to reason about, and wholly internal. I'd guess the risk is about on par with—or safer than—VM runtime languages written in C/++. Far as 1.0 in Rust, the predominant culture is to treat "0.X.x" releases roughly equivalent to a "1.x" semantic. I have run into very few issues of API breaking changes in "0.X.x" libraries, and even those are basically handed to you thanks to Rust's robust compile-time checks. Of course your mileage may vary, but I've had a way worse time with even well-established breaks in Ruby, Python, and Go libraries. I understand your risk aversion; I am similar. But I've found Rust to be an absolute delight for stability. The shaky ground of the first few years has largely given way to impressive robustness over the last few. I strongly urge you to consider Rust if it matches your needs. You may be quite pleased!
  - lstamour 6y ago
    The 0.x stability is news to me. I would suggest the community would get wider adoption by moving to 1.0 for components that others can build on, such as web servers. To me, that Tokio hit 1.0 is a significant milestone, one that encourages its use for new projects. I personally look forward to the first web server widely adopted that hits 1.0 and relies on an async implementation that’s also 1.0… I agree that Rust is very attractive, but it’s hard for me to argue for Rust against Go’s stability if you can live with Go’s more limited syntax. If Rust could promise the same stability as you’d have writing a JSON API or HTML-templates website in Go, I’d start picking Rust for new projects. My perspective, to be clear, is that the heisenbugs likely still exist in Rust servers but have been mostly ironed out in Go ones. I’m reminded of Hyrum’s Law - https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ - under the assumption that as libraries hit 1.0, their behaviour can be more reasonably relied upon than pre-1.0…

by dmm 6y ago

lstamour 6y ago

> about Actix framework being mostly unsafe Yep, that's what I meant. To me, until Rust unsafe implementations hit 1.0 as web frameworks, not just Tokio, I can't consider them as stable or bug-free as more mature web servers. It's arbitrary, yes, but it's also an important distinction. 1.0 generally means "you can rely on this to not change, and to have a useful set of functionality" and bug fixes equivalent to an LTS release. This is especially true if functionality is common enough that it makes its way into a standard library or conventional best practices. Generally, it has to hit "1.0" before it does so, though, in any stable manner...

covidthrow 6y ago
The Actix unsafe code has long since been resolved. There are very few instances of it, and each are small, specific, easy to reason about, and wholly internal. I'd guess the risk is about on par with—or safer than—VM runtime languages written in C/++. Far as 1.0 in Rust, the predominant culture is to treat "0.X.x" releases roughly equivalent to a "1.x" semantic. I have run into very few issues of API breaking changes in "0.X.x" libraries, and even those are basically handed to you thanks to Rust's robust compile-time checks. Of course your mileage may vary, but I've had a way worse time with even well-established breaks in Ruby, Python, and Go libraries. I understand your risk aversion; I am similar. But I've found Rust to be an absolute delight for stability. The shaky ground of the first few years has largely given way to impressive robustness over the last few. I strongly urge you to consider Rust if it matches your needs. You may be quite pleased!
- lstamour 6y ago
  The 0.x stability is news to me. I would suggest the community would get wider adoption by moving to 1.0 for components that others can build on, such as web servers. To me, that Tokio hit 1.0 is a significant milestone, one that encourages its use for new projects. I personally look forward to the first web server widely adopted that hits 1.0 and relies on an async implementation that’s also 1.0… I agree that Rust is very attractive, but it’s hard for me to argue for Rust against Go’s stability if you can live with Go’s more limited syntax. If Rust could promise the same stability as you’d have writing a JSON API or HTML-templates website in Go, I’d start picking Rust for new projects. My perspective, to be clear, is that the heisenbugs likely still exist in Rust servers but have been mostly ironed out in Go ones. I’m reminded of Hyrum’s Law - https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ - under the assumption that as libraries hit 1.0, their behaviour can be more reasonably relied upon than pre-1.0…