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.
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.
> 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.
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.
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.)
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.
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.
We use a Kotlin scripting variant for our own shell scripting needs at Hydraulic, it's pretty nice because we've joined it with a lot of internal APIs that make working with the filing system and network easy. It fits all those requirements and more (you can declare flags easily at the top level, it has built in progress tracking for slow operations etc).
The Kotlin type system is comparable to Rust without the borrow checker. It has non-null types, generics, etc.
It's not really a "product" per se but there's an old version for download and some lightweight docs here:
We've never worked out what to do with it. Ideas and feedback welcome. It's pretty nice to use, albeit you need to use IntelliJ to edit scripts if you want IDE features.
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.
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.
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.