4 ms·

This post is definitely inside baseball, so it’s incredibly esoteric to those that understand it, but it’s worth mentioning: Rust is accomplishing things at com

This post is definitely inside baseball, so it’s incredibly esoteric to those that understand it, but it’s worth mentioning: Rust is accomplishing things at compile-time that most languages with similar features have to do at runtime with runtimes (in this case, all of the higher-kindedness that GAT represents without extensive heap allocation and runtime-level bookkeeping under the hood). The LendingIterator is conceptually providing mutable access to a sub-slice of a larger struct, and doing it without heap allocation (NB besides the initial box storage shown in the example). Even in the case of dyn, which is a feat. Also it is safely returning pointers for the above-referenced mutable access across function calls; it’s impressive the way good perl golf is impressive, because you appreciate what is happening underneath. Putting all of that aside, what you said about FPGAs is probably valid.

lalaithion 4y ago
Also, you can totally write (with a bit of unsafe) a LendingIterator with runtime checks instead of this compile time check, with the cost of 1 byte per item (and of course the possibility of a runtime panic). So this is really only relevant for library authors and those who want to wring the last bit of performance out of their program.
PaulHoule 4y ago
I still find Rust a disappointment. I thought Cyclone was a good idea but it hurts so much to watch people to struggle doing what should be very simple things in Rust. People are re-writing the Software Tools by Kernighan and Plauger. C took over the world because books like that made it look easy. I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting. That is, we have systems of memory allocation and resource management that almost work in C++, Java and other languages. Rustifarians would claim they've removed the almost (if the program compiles) but there are programs that will never get written, features that will be added, bugs that will never get fixed because of the extra complexity. So the "almost" doesn't really go away. I like the idea of a flexible compiler that supports a lot of metaprogramming, has a theorem prover to prove that application-specific constraints hold, and writes code that meshes with a bespoke runtime. (e.g. imagine a C++ designed to support what people really do with C++) Unfortunately it kills the whole idea of importing libraries, so it is still an "almost". The C implementation for Arduino drives me absolutely up the wall. AVR8 has as many registers as the old IBM 360 (a lot!), the programs I write can run entirely with statically allocated memory, I almost want to cry writing AVR8 or ARM assembler and still having to hook into C libraries with calling conventions and futzing around with the stack that are providing features the application doesn't really need... And there is that Rube Goldberg CMAKE build system that could have only been inspired by autotools. That's how "almost" is the enemy of the good.
- pjmlp 4y ago
  What I dislike is how some in the community hijacked the idea that unsafe code blocks are for possible memory corruption code, as introduced in Algol languages since the late 1950's, and now everything that consider might be error prone is an "unsafe" API.
- zozbot234 4y ago
  > I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting. These properties are the baseline you're going to need if you want to guarantee harder ones. The whole field of high-assurance software is pretty much in agreement about this, memory safety is a key enabler of proper semantics more generally.
  - PaulHoule 4y ago
    Except that a particular program could have its own answers to the memory problem. Some problems that are intractable in general are straightfoward in specific cases. That's kinda what the selling point of C++ is supposed to be.

lalaithion 4y ago

Also, you can totally write (with a bit of unsafe) a LendingIterator with runtime checks instead of this compile time check, with the cost of 1 byte per item (and of course the possibility of a runtime panic). So this is really only relevant for library authors and those who want to wring the last bit of performance out of their program.

PaulHoule 4y ago

I still find Rust a disappointment. I thought Cyclone was a good idea but it hurts so much to watch people to struggle doing what should be very simple things in Rust. People are re-writing the Software Tools by Kernighan and Plauger. C took over the world because books like that made it look easy. I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting. That is, we have systems of memory allocation and resource management that almost work in C++, Java and other languages. Rustifarians would claim they've removed the almost (if the program compiles) but there are programs that will never get written, features that will be added, bugs that will never get fixed because of the extra complexity. So the "almost" doesn't really go away. I like the idea of a flexible compiler that supports a lot of metaprogramming, has a theorem prover to prove that application-specific constraints hold, and writes code that meshes with a bespoke runtime. (e.g. imagine a C++ designed to support what people really do with C++) Unfortunately it kills the whole idea of importing libraries, so it is still an "almost". The C implementation for Arduino drives me absolutely up the wall. AVR8 has as many registers as the old IBM 360 (a lot!), the programs I write can run entirely with statically allocated memory, I almost want to cry writing AVR8 or ARM assembler and still having to hook into C libraries with calling conventions and futzing around with the stack that are providing features the application doesn't really need... And there is that Rube Goldberg CMAKE build system that could have only been inspired by autotools. That's how "almost" is the enemy of the good.

pjmlp 4y ago
What I dislike is how some in the community hijacked the idea that unsafe code blocks are for possible memory corruption code, as introduced in Algol languages since the late 1950's, and now everything that consider might be error prone is an "unsafe" API.
zozbot234 4y ago
> I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting. These properties are the baseline you're going to need if you want to guarantee harder ones. The whole field of high-assurance software is pretty much in agreement about this, memory safety is a key enabler of proper semantics more generally.
- PaulHoule 4y ago
  Except that a particular program could have its own answers to the memory problem. Some problems that are intractable in general are straightfoward in specific cases. That's kinda what the selling point of C++ is supposed to be.