5 ms·

I get what the article is saying. I enjoy Rust, as I enjoy dabbling in other more esoteric programming languages, like Zig. But one thing I miss from the days o

I get what the article is saying. I enjoy Rust, as I enjoy dabbling in other more esoteric programming languages, like Zig. But one thing I miss from the days of early programming is the hacker spirit, in a way. As it master, I should be able to force my machine into giving me access of private fields. I want to be able to poke holes in stuff, to break things and at times, I want the ability to do something stupid just because I want to see what would happen. I feel the same for overly strict compilers. The number one thing I hate about Zig is the compiler treating me like a child when I have unreferenced variables. Modern languages should enable what older languages couldn‘t. They shouldn‘t get in my way needlessly.

yencabulator 2y ago
unsafe is there when you need it, you can poke all the bytes and hack the planet as much as you want as soon as you acknowledge the language can't keep you safe anymore.
robot_no_421 2y ago
"As it master, I should be able to force my machine into giving me access of private fields." If you're writing the code then you can do whatever you want with it. But if I'm writing the code you're using, I want the power to express "the end user cannot use this private field". You trying to access the private fields in the library I or someone else wrote would be like trying to change a book someone wrote or a painting someone made. It's not the computer restricting you, it's the author of the code. EDIT: This response was not my finest take.
- alkonaut 2y ago
  I think the agreement is rather “if you change the private field then there are no longer any guarantees of anything”. Which is fine, I think. And obviously with or without reflection anyone can already modify the private field.
  - Quekid5 2y ago
    It's the shortest path to Hyrum's Law, certainly. > And obviously with or without reflection anyone can already modify the private field. This bit, I don't understand. Wouldn't that require unsafe? EDIT: Just to say: Abstract data types usually require upholding some invariants which all the operations on those data types must uphold at entry/exit. If anyone can do whatever, then what's left othen than just a bag of bytes?
    - alkonaut 2y ago
      Yes. I’m 100% talking about unsafe Rust now (for private fields). That is: I see reflection only as a way of making unsafe bytemucking a bit more ergonomic. Its nothing you can’t already do. It’s a well behaved object with invariants 99% of the time, then for some edge case/cheat it’s not. Much like the difference between safe and unsafe already is. Most of the time you rely on the guarantees, but occasionally you throw the guarantees out. And again: this IS already in an unsafe context by necessity. This has been the case in every language with encapsulation and reflection (C#, Java, …) since forever. And it’s a super useful thing. I can’t see why the encapsulation in (unsafe) Rust is more important? Is it because it has no runtime to provide guard rails where the JVM/CLR would still throw exceptions when I use my tampered object with broken invariants?
      - Quekid5 2y ago
        Oh, I see... I think I was thinking about reflection in an entirely different way. When I think Reflection I think mostly static and generative reflection -- so you can introspect on data structures, derive [whatever] from that, generate code, whatever... but you still cannot do [whatever] to the thing you reflected on. (Other than whatever the language says you can do as a public consumer of that API/structure) So you can, say, add serialization code, generate property test instances, whatever. What you cannot do is do anything to "invade" the thing being reflected on and change its meaning.
        alkonaut 2y ago
- cryptonector 2y ago
  But sometimes you might writing a debugger. Reflection is essentially including all the "debug symbols" that you need in order to build a debugger into your application.
unrealhoang 2y ago
No language since assembly enables new features that you could not have done in assembly. Languages are invented to enforce standard and build higher level abstraction aka disable feature.

yencabulator 2y ago

unsafe is there when you need it, you can poke all the bytes and hack the planet as much as you want as soon as you acknowledge the language can't keep you safe anymore.

robot_no_421 2y ago

"As it master, I should be able to force my machine into giving me access of private fields." If you're writing the code then you can do whatever you want with it. But if I'm writing the code you're using, I want the power to express "the end user cannot use this private field". You trying to access the private fields in the library I or someone else wrote would be like trying to change a book someone wrote or a painting someone made. It's not the computer restricting you, it's the author of the code. EDIT: This response was not my finest take.

alkonaut 2y ago
I think the agreement is rather “if you change the private field then there are no longer any guarantees of anything”. Which is fine, I think. And obviously with or without reflection anyone can already modify the private field.
- Quekid5 2y ago
  It's the shortest path to Hyrum's Law, certainly. > And obviously with or without reflection anyone can already modify the private field. This bit, I don't understand. Wouldn't that require unsafe? EDIT: Just to say: Abstract data types usually require upholding some invariants which all the operations on those data types must uphold at entry/exit. If anyone can do whatever, then what's left othen than just a bag of bytes?
  - alkonaut 2y ago
    Yes. I’m 100% talking about unsafe Rust now (for private fields). That is: I see reflection only as a way of making unsafe bytemucking a bit more ergonomic. Its nothing you can’t already do. It’s a well behaved object with invariants 99% of the time, then for some edge case/cheat it’s not. Much like the difference between safe and unsafe already is. Most of the time you rely on the guarantees, but occasionally you throw the guarantees out. And again: this IS already in an unsafe context by necessity. This has been the case in every language with encapsulation and reflection (C#, Java, …) since forever. And it’s a super useful thing. I can’t see why the encapsulation in (unsafe) Rust is more important? Is it because it has no runtime to provide guard rails where the JVM/CLR would still throw exceptions when I use my tampered object with broken invariants?
    - Quekid5 2y ago
      Oh, I see... I think I was thinking about reflection in an entirely different way. When I think Reflection I think mostly static and generative reflection -- so you can introspect on data structures, derive [whatever] from that, generate code, whatever... but you still cannot do [whatever] to the thing you reflected on. (Other than whatever the language says you can do as a public consumer of that API/structure) So you can, say, add serialization code, generate property test instances, whatever. What you cannot do is do anything to "invade" the thing being reflected on and change its meaning.
      - alkonaut 2y ago
cryptonector 2y ago
But sometimes you might writing a debugger. Reflection is essentially including all the "debug symbols" that you need in order to build a debugger into your application.

unrealhoang 2y ago

No language since assembly enables new features that you could not have done in assembly. Languages are invented to enforce standard and build higher level abstraction aka disable feature.