12 ms·

Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions

by Xeamek 2y ago

Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times

eterevsky 2y ago
Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)
- Xeamek 2y ago
  Again, restrictions that are forced you for a price of safety are one thing. But what I'm complaining about are restrictions that don't have to be there to get borrowchecker working, but rather are there because designers arbitrary decided "it's better this way".
  - komali2 2y ago
    As someone just starting to finally learn Rust, I'm curious what some examples of this might be.
    - flohofwoe 2y ago
      All AFAIK, since I only dabble occasionally in Rust: The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.
      - pdimitar 2y ago
        > The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.
      - eterevsky 2y ago
        They made a lot of progress with borrow checker granularity between 1.0 and now. It's much more granular now than before.
      - Measter 2y ago
        > There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. I don't think it's so much "can not" as it is "will not". Allowing the function signature to be determined by the body can lead to accidentally breaking callers by changing the body. That, at least, is consistent with other parts of the signature: the input/output types and how the lifetimes of input/output references are related.
- flohofwoe 2y ago
  There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes). It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).
  - pdimitar 2y ago
    That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.
    - flohofwoe 2y ago
      IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).
      - SpaceNugget 2y ago
        I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData<P, B>(pins: P, bus: B, data: u8) -> B; in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>
        flohofwoe 2y ago
        Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).
self_awareness 2y ago
Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.
- flohofwoe 2y ago
  Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.
  - self_awareness 2y ago
    Single source of truth of opinions can be challenged and changed if one's arguments are good enough. The benefit is that it's easier to see the advantages and disadvantages for those opinions, because they're all in the same place. This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other. Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.
pdimitar 2y ago
C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while. > And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.
- Xeamek 2y ago
  There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'. Again, the former are fine, it's the latter I have a problem with.
  - pdimitar 2y ago
    In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?
    - Xeamek 2y ago
      Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.
scotty79 2y ago
Rust is just a different language. It's not C-like or Java-like plus checks or anything like that. It's a value oriented language. Variables mean something completely different than in any other common language. Everything is about the values and where they are kept at the moment.
hdjksndhsi 2y ago
So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)
- Xeamek 2y ago
  Except Rust's unsafe is even worse then any other 'unsafe' languages. And while you can technically prototype in a other language, speed of iteration is always a bottleneck. The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding. But that's a verry rare case scenario
  - pdimitar 2y ago
    I don't disagree btw. As a contractor I have found myself very often in a situation where Rust's slower iteration simply didn't work for me so I got back to Elixir and also relearned and started getting proficient in Golang. Rust's slower iteration only disappears when you become a pro as you said and that's my main problem with it. I simply can't invest as much time and effort for free.

by Xeamek 2y ago

eterevsky 2y ago

Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)

Xeamek 2y ago
Again, restrictions that are forced you for a price of safety are one thing. But what I'm complaining about are restrictions that don't have to be there to get borrowchecker working, but rather are there because designers arbitrary decided "it's better this way".
- komali2 2y ago
  As someone just starting to finally learn Rust, I'm curious what some examples of this might be.
  - flohofwoe 2y ago
    All AFAIK, since I only dabble occasionally in Rust: The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.
    - pdimitar 2y ago
      > The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.
    - eterevsky 2y ago
      They made a lot of progress with borrow checker granularity between 1.0 and now. It's much more granular now than before.
    - Measter 2y ago
      > There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. I don't think it's so much "can not" as it is "will not". Allowing the function signature to be determined by the body can lead to accidentally breaking callers by changing the body. That, at least, is consistent with other parts of the signature: the input/output types and how the lifetimes of input/output references are related.
flohofwoe 2y ago
There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes). It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).
- pdimitar 2y ago
  That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.
  - flohofwoe 2y ago
    IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).
    - SpaceNugget 2y ago
      I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData<P, B>(pins: P, bus: B, data: u8) -> B; in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>
      - flohofwoe 2y ago
        Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).

self_awareness 2y ago

Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.

flohofwoe 2y ago
Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.
- self_awareness 2y ago
  Single source of truth of opinions can be challenged and changed if one's arguments are good enough. The benefit is that it's easier to see the advantages and disadvantages for those opinions, because they're all in the same place. This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other. Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.

pdimitar 2y ago

C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while. > And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.

Xeamek 2y ago
There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'. Again, the former are fine, it's the latter I have a problem with.
- pdimitar 2y ago
  In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?
  - Xeamek 2y ago
    Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.

scotty79 2y ago

Rust is just a different language. It's not C-like or Java-like plus checks or anything like that. It's a value oriented language. Variables mean something completely different than in any other common language. Everything is about the values and where they are kept at the moment.

hdjksndhsi 2y ago

So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)

Xeamek 2y ago
Except Rust's unsafe is even worse then any other 'unsafe' languages. And while you can technically prototype in a other language, speed of iteration is always a bottleneck. The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding. But that's a verry rare case scenario
- pdimitar 2y ago
  I don't disagree btw. As a contractor I have found myself very often in a situation where Rust's slower iteration simply didn't work for me so I got back to Elixir and also relearned and started getting proficient in Golang. Rust's slower iteration only disappears when you become a pro as you said and that's my main problem with it. I simply can't invest as much time and effort for free.