5 ms·

All issues dealing with undefined behavior (UB), segfaults and the like are currently closed. Actix-Web makes use of unsafe (as high-performance Rust usually do

All issues dealing with undefined behavior (UB), segfaults and the like are currently closed. Actix-Web makes use of unsafe (as high-performance Rust usually does) so there could be some UB hiding.

AgentME 7y ago
"Closed" as in ignored, or solved with actions taken? Asking legitimately, because the stuff I'd read previously didn't fill me with confidence.
- correct_horse 7y ago
  With actions taken in all of 5 issues. See all issues here https://github.com/actix/actix-web/issues?q=label%3Aunsafe+ https://github.com/actix/actix-web/issues?q=label%3Aunsafe+
adamc 7y ago
Honest question: What is the point of using Rust if you have to use unsafe constructs to get performance?
- steveklabnik 7y ago
  unsafe is an escape hatch. You don't have to use unsafe to get performance, in the general case. Often, safe code is as fast or faster than unsafe code. But sometimes, it is needed. Even then, the point of using Rust is containment: you can write a safe abstraction over that unsafe code, and minimize the hunt for what you did wrong, if you've made a mistake and caused a problem.
- kbenson 7y ago
  It might be useful to think of unsafe portions the same way you would consider calling out to a C library from some managed language. If you have one or two modules you're using that cal calling out to C libs, and your managed language is segfaulting, it's probably somewhere to do with those libraries, or how you're utilizing them (maybe a bad API or abstraction). Rust just lets you take that reasoning further in the case of unsafe, since you can see the unsafe code in the same codebase, it's basically the same language plus a couple extra features, and can be kept much smaller (at least in the case where the functionality is implemented in Rust). Unsafe isn't meant to imply "don't do this", it's meant to imply you're giving up the safety generally afforded. It's like driving a car without seatbelts and airbags down the freeway, not like driving a car at 100Mph on a windy cliff-side road. 1: Or to the same level, if using unsafe to abstract over a C lib also
- eeZah7Ux 7y ago
  Not much.
- Too 7y ago
  What are your alternatives? Managed memory language or C/C++? Rust has much more modern and ergonomic syntax, features and package management over C, so even inside unsafe blocks it's simply easier to write.
  - pjmlp 7y ago
    Managed memory languages like Swift, F#, C#, D, Nim, offer the productivity of GC, value types, unsafe if really needed and AOT compiled toolchains.
    - pkolaczk 7y ago
      "productivity of GC" is often offset by much harder management of resources other than memory due to lack of deterministic destruction. Also benchmarks show Swift and C# are still about 2x-5x slower than Rust and C++, and that only if you're very careful and you write non-idiomatic code (e.g by avoiding heap allocations). When you're not, and you use OOP abstractions heavily, 10x worse is a much more likely outcome.
      - pjmlp 7y ago
        That is only true if using a language that doesn't not offer mechanisms to have deterministic destruction, when required to do so. Winning the benchmarks game is meaningless, other than "I fell good" kind of thing. What matters is having the language features that allow to optimize the 1% of the code base, when it actually impact the acceptance criteria of project delivery. I have been replacing C++ systems with Java and .NET based solutions since 2006, it hardly matters that C++ wins in the micro-benchmarks. And if really needed, only that 1% gets packed into a C++ library with managed language bindings, turning C++ into our "unsafe" module.
        pkolaczk 7y ago
        My point is these languages you mentioned don't offer good tools to optimize that 1% and they make the other 99% an order of magnitude slower and more resource hungry to the point where it actually matters and annoys users. Also neither C# nor Java offers deterministic destruction. Try with resources is a joke, because it is limited to a lexical scope. Java and C# are not true alternatives to Rust or C++. They are inferior both on performance side and abstraction/productivity side, and severely inferior if you want both in the same fragment of code. In many applications there is also no single bottleneck and the split is not 1/99, nor even 20/80. After you optimize the most obvious bottlenecks you end up with a flat profile, where majority of time is taken by cache misses scattered across almost the whole codebase. It might not matter for some apps where performance is less critical, but in this case you probably don't want to use Java or C# when there exist languages offering much better abstractions (and surprisingly - Rust and C++ can be higher-level than Java or C#, leading to better abstractions, shorter code and higher productivity). Don't conflate EASY with PRODUCTIVE. Easy languages are not always more productive (if it was true everybody would be coding in Scratch).
- ratmice 7y ago
  Say you are having a pizza party, and you are cooking 12 pizzas, in your pizza oven, the fire alarm is going off, but you know there is no fire, and should there be a fire it is indistinguishable from the smoke pouring out of the oven. lets say it is a fancy fire alarm which turns the oven off. you could: - Convince the fire alarm about the difference between pizza smoke, and fire smoke (somehow?). - Call the fire department to come put out the fire so you can finish cooking your pizza. - Disable it until you have finished cooking the pizzas. - Have a pizzaless party. Fire alarms have little to do with performance, and even though they have false positives we tolerate them due to the impact a false negative would have.

All issues dealing with undefined behavior (UB), segfaults and the like are currently closed. Actix-Web makes use of unsafe (as high-performance Rust usually does) so there could be some UB hiding.

AgentME 7y ago

"Closed" as in ignored, or solved with actions taken? Asking legitimately, because the stuff I'd read previously didn't fill me with confidence.

correct_horse 7y ago
With actions taken in all of 5 issues. See all issues here https://github.com/actix/actix-web/issues?q=label%3Aunsafe+ https://github.com/actix/actix-web/issues?q=label%3Aunsafe+

adamc 7y ago

Honest question: What is the point of using Rust if you have to use unsafe constructs to get performance?

steveklabnik 7y ago
unsafe is an escape hatch. You don't have to use unsafe to get performance, in the general case. Often, safe code is as fast or faster than unsafe code. But sometimes, it is needed. Even then, the point of using Rust is containment: you can write a safe abstraction over that unsafe code, and minimize the hunt for what you did wrong, if you've made a mistake and caused a problem.
kbenson 7y ago
It might be useful to think of unsafe portions the same way you would consider calling out to a C library from some managed language. If you have one or two modules you're using that cal calling out to C libs, and your managed language is segfaulting, it's probably somewhere to do with those libraries, or how you're utilizing them (maybe a bad API or abstraction). Rust just lets you take that reasoning further in the case of unsafe, since you can see the unsafe code in the same codebase, it's basically the same language plus a couple extra features, and can be kept much smaller (at least in the case where the functionality is implemented in Rust). Unsafe isn't meant to imply "don't do this", it's meant to imply you're giving up the safety generally afforded. It's like driving a car without seatbelts and airbags down the freeway, not like driving a car at 100Mph on a windy cliff-side road. 1: Or to the same level, if using unsafe to abstract over a C lib also
eeZah7Ux 7y ago
Not much.
Too 7y ago
What are your alternatives? Managed memory language or C/C++? Rust has much more modern and ergonomic syntax, features and package management over C, so even inside unsafe blocks it's simply easier to write.
- pjmlp 7y ago
  Managed memory languages like Swift, F#, C#, D, Nim, offer the productivity of GC, value types, unsafe if really needed and AOT compiled toolchains.
  - pkolaczk 7y ago
    "productivity of GC" is often offset by much harder management of resources other than memory due to lack of deterministic destruction. Also benchmarks show Swift and C# are still about 2x-5x slower than Rust and C++, and that only if you're very careful and you write non-idiomatic code (e.g by avoiding heap allocations). When you're not, and you use OOP abstractions heavily, 10x worse is a much more likely outcome.
    - pjmlp 7y ago
      That is only true if using a language that doesn't not offer mechanisms to have deterministic destruction, when required to do so. Winning the benchmarks game is meaningless, other than "I fell good" kind of thing. What matters is having the language features that allow to optimize the 1% of the code base, when it actually impact the acceptance criteria of project delivery. I have been replacing C++ systems with Java and .NET based solutions since 2006, it hardly matters that C++ wins in the micro-benchmarks. And if really needed, only that 1% gets packed into a C++ library with managed language bindings, turning C++ into our "unsafe" module.
      - pkolaczk 7y ago
        My point is these languages you mentioned don't offer good tools to optimize that 1% and they make the other 99% an order of magnitude slower and more resource hungry to the point where it actually matters and annoys users. Also neither C# nor Java offers deterministic destruction. Try with resources is a joke, because it is limited to a lexical scope. Java and C# are not true alternatives to Rust or C++. They are inferior both on performance side and abstraction/productivity side, and severely inferior if you want both in the same fragment of code. In many applications there is also no single bottleneck and the split is not 1/99, nor even 20/80. After you optimize the most obvious bottlenecks you end up with a flat profile, where majority of time is taken by cache misses scattered across almost the whole codebase. It might not matter for some apps where performance is less critical, but in this case you probably don't want to use Java or C# when there exist languages offering much better abstractions (and surprisingly - Rust and C++ can be higher-level than Java or C#, leading to better abstractions, shorter code and higher productivity). Don't conflate EASY with PRODUCTIVE. Easy languages are not always more productive (if it was true everybody would be coding in Scratch).
ratmice 7y ago
Say you are having a pizza party, and you are cooking 12 pizzas, in your pizza oven, the fire alarm is going off, but you know there is no fire, and should there be a fire it is indistinguishable from the smoke pouring out of the oven. lets say it is a fancy fire alarm which turns the oven off. you could: - Convince the fire alarm about the difference between pizza smoke, and fire smoke (somehow?). - Call the fire department to come put out the fire so you can finish cooking your pizza. - Disable it until you have finished cooking the pizzas. - Have a pizzaless party. Fire alarms have little to do with performance, and even though they have false positives we tolerate them due to the impact a false negative would have.