6 ms·

I feel like Rust finally broke the idea that programmers should be in complete control and completely conscious of everything the compiler is doing. It hasn't

I feel like Rust finally broke the idea that programmers should be in complete control and completely conscious of everything the compiler is doing. It hasn't been that way in decades, compilers are freaking magic. But Rust undid a lot of that with borrowing. People became comfortable with the compiler knowing better than them. I just wish we could relax further: We should never be explicitly iterating forward over a collection unless we need this behavior for the algorithm. Things should be implicitly parallel. Etc. Give me rusty bash.

jjn2009 3y ago
Arguably memory managed languages are the same or are you speaking to some specific slice of the available programming languages?
alpaca128 3y ago
> We should never be explicitly iterating forward over a collection unless we need this behavior for the algorithm. Things should be implicitly parallel There is already a crate providing parallel iterators. You just rename the iter() call and that's it. I don't agree it should be implicit though.
- ModernMech 3y ago
  It’s called Rayon for anyone who wants to know.
oconnor663 3y ago
I think "not in control of what the compiler is doing" is overstating things a little bit. In some ways, Rust gives the programmer more control than C does. For example, Rust has standardized support for inline assembly, but inline assembly in C relies on vendor-specific extensions. But to your point, the convenient defaults are very different. Unsafe typecasts require a lot of ceremony and careful thought in Rust, and they have to follow more rules than in C. In particular, references are all effectively "restrict" in Rust, and it's really easy to screw that up when you do unsafe cast from raw pointers to safe references, which is a big incentive not to write code like that if you have a choice.
- jeremyjh 3y ago
  > but inline assembly in C relies on vendor-specific extensions. Whereas Rust is a standard with multiple implementations?
  - oconnor663 3y ago
    I should've said "stabilized" instead of "standardized" to avoid stepping on this conversational landmine. But an important practical difference is that Rust supports inline assembly on Windows. (Correct me if I'm wrong, but I think MSVC mostly does not support inline asm.)
    - trealira 3y ago
      It does support inline assembly [1]. However, it's different than the way GCC supports inline assembly. It seems nicer, TBH. [1]: https://learn.microsoft.com/en-us/cpp/assembler/inline/inline-assembler?view=msvc-170 https://learn.microsoft.com/en-us/cpp/assembler/inline/inlin...
      - oconnor663 3y ago
        From that source: > Inline assembly is not supported on the ARM and x64 processors.
        trealira 3y ago
        Oh, my bad. I should have read the source more closely. I hadn't realized only 32-bit x86 processors were supported.
        jeremyjh 3y ago
        That's hilarious. Like, the compiler team had ONE GUY that believed in and developed this feature and retired in 1999.
j-pb 3y ago
As someone who does a lot of unsafe rust, including tagged pointer foo, I strongly disagree. If anything I want more explicit control, alleviated with an even more expressive type system. Ideally rusts type system would just be a prolog variant imho.
- charcircuit 3y ago
  No thanks. Rust compile times are already too slow.
- throwaway914 3y ago
  Anyone that can reliably and off-the-cuff do all of these can have complete control back: https://en.wikipedia.org/wiki/Category:Compiler_optimizations https://en.wikipedia.org/wiki/Category:Compiler_optimization... Otherwise we should trust compilers to know better.
HKH2 3y ago
> Give me rusty bash. Bash with types (especially floats), fewer edge cases, functions with explicit parameters, simple command line flags...
- AgentME 3y ago
  You're skipping the most needed improvement of all: fixing the issue where scripts with unquoted variables will seem to work until they contain a space. Almost every single bash script of more than a dozen lines I've seen outside of large open-source projects fails if a user puts a space in a file path, because the programmer didn't understand the insanity of variable quoting rules! I don't know of any programming language with a more common major footgun.
  - HKH2 3y ago
    Shellcheck does cover that. I think the bigger problem is people programming without warnings (in any language). edit: Although I can see that if they hadn't made string splitting the default, it would have saved a lot of headaches.
- fbdab103 3y ago
  Now you have me curious - where do you see the need for floats in shell? You are more creative than myself, because I am struggling to come up with a situation where I would lean on this. A "path" type would be by far more useful to my work.
  - HKH2 3y ago
    I have a script which uses wmctrl to tile windows when I press a shortcut key (for when I'm using an editor and want the editor window to take up most of the screen). I guess I could avoid floats using multiplication, but I would rather keep the code as simple as possible.
- bbkane 3y ago
  Sounds like nushell: https://www.jntrnr.com/case-for-nushell/ https://www.jntrnr.com/case-for-nushell/
pornel 3y ago
That seems entirely opposite to my Rust experience. Rust is quite transparent in what it does, and is very conservative with compiler magic. The language doesn’t do heap allocations, doesn’t do reference counting, it doesn’t even have implicit numeric type conversion. It won’t implicitly copy types that did not ask to be implicitly copyable, and even that is only legal for types that can be copied with a simple shallow memcpy. Rust uses zero-cost abstractions all over the place, which means it’s predictable what code they will compile to, and that will be typically something simple. Std types have well-known basic layout, so you know that e.g. iteration over a Vec is going to be a loop incrementing a pointer, and there’s no implicit parallelism. Describing borrowing as “compiler knowing better than the programmer” is a weird way of looking at it. Borrowing is like type checking. You declare a type to be temporary, and try to use it as long-lived, you get an error. It’s the same as if you declare function to return struct Foo, but returned struct Bar instead. Yes, compiler “knows better than you”, because you just wrote a bug. Borrowing still compiles to direct pointer usage without a GC (it’s literally guaranteed to be identical to a C pointer in C ABI structs and functions), and you can override lifetimes with unsafe if you think know better than the compiler.
bjourne 3y ago
That's the approach Haskell took. Didn't work since they didn't realize that waiting for your program to respond is a pretty effing huge side effect.
- trealira 3y ago
  It has unpredictable performance because of lazy evaluation. Other high-level functional programming languages like OCaml, Standard ML, and Scheme can be compiled and achieve fairly high performance.
rustshellscript 3y ago
Here: https://github.com/rust-shell-script/rust_cmd_lib https://github.com/rust-shell-script/rust_cmd_lib

jjn2009 3y ago

Arguably memory managed languages are the same or are you speaking to some specific slice of the available programming languages?

alpaca128 3y ago

> We should never be explicitly iterating forward over a collection unless we need this behavior for the algorithm. Things should be implicitly parallel There is already a crate providing parallel iterators. You just rename the iter() call and that's it. I don't agree it should be implicit though.

ModernMech 3y ago
It’s called Rayon for anyone who wants to know.

oconnor663 3y ago

I think "not in control of what the compiler is doing" is overstating things a little bit. In some ways, Rust gives the programmer more control than C does. For example, Rust has standardized support for inline assembly, but inline assembly in C relies on vendor-specific extensions. But to your point, the convenient defaults are very different. Unsafe typecasts require a lot of ceremony and careful thought in Rust, and they have to follow more rules than in C. In particular, references are all effectively "restrict" in Rust, and it's really easy to screw that up when you do unsafe cast from raw pointers to safe references, which is a big incentive not to write code like that if you have a choice.

jeremyjh 3y ago
> but inline assembly in C relies on vendor-specific extensions. Whereas Rust is a standard with multiple implementations?
- oconnor663 3y ago
  I should've said "stabilized" instead of "standardized" to avoid stepping on this conversational landmine. But an important practical difference is that Rust supports inline assembly on Windows. (Correct me if I'm wrong, but I think MSVC mostly does not support inline asm.)
  - trealira 3y ago
    It does support inline assembly [1]. However, it's different than the way GCC supports inline assembly. It seems nicer, TBH. [1]: https://learn.microsoft.com/en-us/cpp/assembler/inline/inline-assembler?view=msvc-170 https://learn.microsoft.com/en-us/cpp/assembler/inline/inlin...
    - oconnor663 3y ago
      From that source: > Inline assembly is not supported on the ARM and x64 processors.
      - trealira 3y ago
        Oh, my bad. I should have read the source more closely. I hadn't realized only 32-bit x86 processors were supported.
        jeremyjh 3y ago
        That's hilarious. Like, the compiler team had ONE GUY that believed in and developed this feature and retired in 1999.

j-pb 3y ago

As someone who does a lot of unsafe rust, including tagged pointer foo, I strongly disagree. If anything I want more explicit control, alleviated with an even more expressive type system. Ideally rusts type system would just be a prolog variant imho.

charcircuit 3y ago
No thanks. Rust compile times are already too slow.
throwaway914 3y ago
Anyone that can reliably and off-the-cuff do all of these can have complete control back: https://en.wikipedia.org/wiki/Category:Compiler_optimizations https://en.wikipedia.org/wiki/Category:Compiler_optimization... Otherwise we should trust compilers to know better.

HKH2 3y ago

> Give me rusty bash. Bash with types (especially floats), fewer edge cases, functions with explicit parameters, simple command line flags...

AgentME 3y ago
You're skipping the most needed improvement of all: fixing the issue where scripts with unquoted variables will seem to work until they contain a space. Almost every single bash script of more than a dozen lines I've seen outside of large open-source projects fails if a user puts a space in a file path, because the programmer didn't understand the insanity of variable quoting rules! I don't know of any programming language with a more common major footgun.
- HKH2 3y ago
  Shellcheck does cover that. I think the bigger problem is people programming without warnings (in any language). edit: Although I can see that if they hadn't made string splitting the default, it would have saved a lot of headaches.
fbdab103 3y ago
Now you have me curious - where do you see the need for floats in shell? You are more creative than myself, because I am struggling to come up with a situation where I would lean on this. A "path" type would be by far more useful to my work.
- HKH2 3y ago
  I have a script which uses wmctrl to tile windows when I press a shortcut key (for when I'm using an editor and want the editor window to take up most of the screen). I guess I could avoid floats using multiplication, but I would rather keep the code as simple as possible.
bbkane 3y ago
Sounds like nushell: https://www.jntrnr.com/case-for-nushell/ https://www.jntrnr.com/case-for-nushell/

pornel 3y ago

That seems entirely opposite to my Rust experience. Rust is quite transparent in what it does, and is very conservative with compiler magic. The language doesn’t do heap allocations, doesn’t do reference counting, it doesn’t even have implicit numeric type conversion. It won’t implicitly copy types that did not ask to be implicitly copyable, and even that is only legal for types that can be copied with a simple shallow memcpy. Rust uses zero-cost abstractions all over the place, which means it’s predictable what code they will compile to, and that will be typically something simple. Std types have well-known basic layout, so you know that e.g. iteration over a Vec is going to be a loop incrementing a pointer, and there’s no implicit parallelism. Describing borrowing as “compiler knowing better than the programmer” is a weird way of looking at it. Borrowing is like type checking. You declare a type to be temporary, and try to use it as long-lived, you get an error. It’s the same as if you declare function to return struct Foo, but returned struct Bar instead. Yes, compiler “knows better than you”, because you just wrote a bug. Borrowing still compiles to direct pointer usage without a GC (it’s literally guaranteed to be identical to a C pointer in C ABI structs and functions), and you can override lifetimes with unsafe if you think know better than the compiler.

bjourne 3y ago

That's the approach Haskell took. Didn't work since they didn't realize that waiting for your program to respond is a pretty effing huge side effect.

trealira 3y ago
It has unpredictable performance because of lazy evaluation. Other high-level functional programming languages like OCaml, Standard ML, and Scheme can be compiled and achieve fairly high performance.

rustshellscript 3y ago

Here: https://github.com/rust-shell-script/rust_cmd_lib https://github.com/rust-shell-script/rust_cmd_lib